Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Edward Shishkin wrote:
Hans Reiser wrote:
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via
On Wed 2006-08-09 02:37:45, Hans Reiser wrote:
Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Yes, you can get clever. But your
Pavel Machek wrote:
On Wed 2006-08-09 02:37:45, Hans Reiser wrote:
Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Yes, you
Yes, it looks like a business of node plugin, but AFAIK, you
objected against such checks:
Did I really? Well, I think that allowing users to choose whether to
checksum or not is a reasonable thing to allow them. I personally would
skip the checksum on my computer, but others
It could be
Jan Engelhardt wrote:
Yes, it looks like a business of node plugin, but AFAIK, you
objected against such checks:
Did I really? Well, I think that allowing users to choose whether to
checksum or not is a reasonable thing to allow them. I personally would
skip the checksum on my computer, but
Hans Reiser wrote:
Pavel Machek wrote:
Yes, I'm afraid redundancy/checksums kill write speed,
they kill write speed to cache, but not to disk our compression
plugin is faster than the uncompressed plugin.
Regarding cache, do we do any sort of consistency checking for RAM, or
do
Matthias Andree wrote:
[stripping Cc: list]
On Thu, 03 Aug 2006, Edward Shishkin wrote:
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If checksum is wrong, then run
fsck - it will remove the whole disk cluster, that represent 64K of
data.
Well,
Hi!
Most users not only cannot patch a kernel, they don't know what a patch
is. It most certainly does.
obviously you can provide complete kernels, including precompiled ones.
Most distros have a yum or apt or similar tool to suck down packages,
it's trivial for users to add a
[stripping Cc: list]
On Thu, 03 Aug 2006, Edward Shishkin wrote:
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If checksum is wrong, then run
fsck - it will remove the whole disk cluster, that represent 64K of
data.
Well, that's quite a
On Jul 31, 3:41pm, Theodore Tso wrote:
} Subject: Re: the 'official' point of view expressed by kernelnewbies.or
On Mon, Jul 31, 2006 at 06:54:06PM +0200, Matthias Andree wrote:
This looks rather like an education issue rather than a technical limit.
We aren't talking about the same
With the latest e2fsprogs and 2.6 kernels, the online resizing
support has been merged in, and as long as the filesystem was
created with space reserved for growing the filesystem (which is now
the default, or if the filesystem has the off-line prepration step
ext2prepare run on it), you can
Hi!
Using guilt as an argument in a technical discussion is a flashing red
sign that says I have no technical rebuttal
Wow, that is really nervy. Let's recap this all:
* reiser4 has a 2x performance advantage over the next fastest FS
(ext3), and when compression ships in a month that
[EMAIL PROTECTED] wrote:
It seems that finding all the bits and pieces to do ext3 on-line
expansion has been a study in obfuscation. Somewhat surprising since
this feature is a must for enterprise class storage management.
Not really. Having people who can dig through the obfuscation is
Hans Reiser wrote:
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via translation of key
offsets with
On Tue 01-08-06 11:57:10, David Masover wrote:
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great
if reiser4.x would be very robust against any kind of
hardware failures.
Can't have both.
Why not? I mean, other
Pavel Machek wrote:
On Tue 01-08-06 11:57:10, David Masover wrote:
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great
if reiser4.x would be very robust against any kind of
hardware failures.
Can't have both.
Why not? I
Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes [EMAIL PROTECTED] wrote:
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED]
Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA
On 4-Aug-06, at 3:25 AM, Russell Leighton wrote:
If the software (filesystem like ZFS or database like Berkeley DB)
finds a mismatch for a checksum on a block read, then what?
Is there a recovery mechanism, or do you just be happy you know
there is a problem (and go to backup)?
ZFS
That was exactly the summary I was looking for.
I would enourage folks to read the referenced link Toby sent:
http://blogs.sun.com/roller/page/bonwick?entry=zfs_end_to_end_data
...also the linked RAID-Z summary from this article was very
interesting, since something like this is needed
Hans Reiser wrote:
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If
On 8/4/06, Edward Shishkin [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind of forward error correction would that
Russell Leighton wrote:
Is there a recovery mechanism, or do you just be happy you know there is
a problem (and go to backup)?
You probably go to backup anyway. The recovery mechanism just means you
get to choose the downtime to restore from backup (if there is
downtime), versus being
Horst H. von Brand wrote:
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
What fancy (beside cryptocompress) does reiser4 do now?
it is supposed to provide an ability to easy modify filesystem behaviour
in various aspects without
Edward Shishkin wrote:
How about we switch to ecc, which would help with bit rot not sector
loss?
Interesting aspect.
Yes, we can implement ECC as a special crypto transform that inflates
data. As I mentioned earlier, it is possible via translation of key
offsets with scale factor 1.
Antonio Vargas wrote:
On 8/4/06, Edward Shishkin [EMAIL PROTECTED] wrote:
Hans Reiser wrote:
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind
On Tue, 01 Aug 2006, David Masover wrote:
RAID deals with the case where a device fails. RAID 1 with 2 disks can
in theory detect an internal inconsistency but cannot fix it.
Still, if it does that, that should be enough. The scary part wasn't
that there's an internal inconsistency, but
On Tue, 01 Aug 2006, Ric Wheeler wrote:
Mirroring a corrupt file system to a remote data center will mirror your
corruption.
Rolling back to a snapshot typically only happens when you notice a
corruption which can go undetected for quite a while, so even that will
benefit from having
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every 64k
What kind of forward error correction would that be, and how much and
what failure patterns can it correct? URL suffices.
--
Matthias Andree
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every 64k
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If checksum is wrong, then run
fsck - it will remove the
On Thu, Aug 03, 2006 at 04:03:07PM +0200, Matthias Andree wrote:
On Tue, 01 Aug 2006, Ric Wheeler wrote:
Mirroring a corrupt file system to a remote data center will mirror your
corruption.
Which makes me wonder if backup systems shouldn't help with this. If
they are reading the
Edward Shishkin wrote:
Matthias Andree wrote:
On Tue, 01 Aug 2006, Hans Reiser wrote:
You will want to try our compression plugin, it has an ecc for every
64k
What kind of forward error correction would that be,
Actually we use checksums, not ECC. If checksum is wrong, then run
On 8/3/06, Matthias Andree [EMAIL PROTECTED] wrote:
Berkeley DB can, since version 4.1 (IIRC), write checksums (newer
versions document this as SHA1) on its database pages, to detect
corruptions and writes that were supposed to be atomic but failed
(because you cannot write 4K or 16K atomically
If the software (filesystem like ZFS or database like Berkeley DB)
finds a mismatch for a checksum on a block read, then what?
Is there a recovery mechanism, or do you just be happy you know there is
a problem (and go to backup)?
Thx
Matthias Andree wrote:
Berkeley DB can, since
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
On Tue, 2006-08-01 at 17:32 +0200, Åukasz Mierzwa wrote:
Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds [EMAIL PROTECTED]
napisaÅ:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER,
Dnia Wed, 02 Aug 2006 20:45:07 +0200, Horst H. von Brand
[EMAIL PROTECTED] napisał:
Vladimir V. Saveliev [EMAIL PROTECTED] wrote:
On Tue, 2006-08-01 at 17:32 +0200, �ukasz Mierzwa wrote:
Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds
[EMAIL PROTECTED]
napisał:
In other words,
On 1-Aug-06, at 4:15 AM, Jeffrey V. Merkey wrote:
...I was and have remained loyal to Linux through it all.
Except for that little fling with SCO, eh?
Off topic, but no more so than your self-aggrandising.
--T
A filesystem with a fixed number of inodes (= not readjustable while
mounted) is ehr.. somewhat unuseable for a lot of people with
big and *flexible* storage needs (Talking about NetApp/EMC owners)
Which is untrue at least for Solaris, which allows resizing a life file
system. FreeBSD and
So ZFS isn't state-of-the-art?
Of course it's state-of-the-art (on Solaris ;-) )
WAFL is for high-turnover filesystems on RAID-5 (and assumes flash memory
staging areas).
s/RAID-5/RAID-4/
Not your run-of-the-mill desktop...
The WAFL-Thing was just a joke ;-)
Regards,
Adrian
suspect, particularly with 7200/min (s)ATA crap.
Quoting myself (again):
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Yeah, the test ran on a single SATA-Harddisk (quick'n'dirty).
I'm so sorry but i don't have access to a $$$ Raid-System at home.
Anyway: The test
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote:
Wil Reichert wrote:
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it, but purely
Adrian Ulrich schrieb am 2006-08-01:
suspect, particularly with 7200/min (s)ATA crap.
Quoting myself (again):
A quick'n'dirty ZFS-vs-UFS-vs-Reiser3-vs-Reiser4-vs-Ext3 'benchmark'
Yeah, the test ran on a single SATA-Harddisk (quick'n'dirty).
I'm so sorry but i don't have access to a
Matthias Andree wrote:
Have you ever seen VxFS or WAFL in action?
No I haven't. As long as they are commercial, it's not likely that I
will.
WAFL was well done. It has several innovations that I admire,
including quota trees, non-support of fragments for performance reasons,
and the
Matthias Andree wrote:
No, it is valid to run the test on commodity hardware, but if you (or
the benchmark rather) is claiming transactions, I tend to think
ACID, and I highly doubt any 200 GB SATA drive manages 3000
synchronous writes per second without causing either serious
fragmentation or
On Mon, Jul 31, 2006 at 05:59:58PM +0200, Adrian Ulrich wrote:
Hello Matthias,
This looks rather like an education issue rather than a technical limit.
We aren't talking about the same issue: I was asking to do it
on-the-fly. Umounting the filesystem, running e2fsck and resize2fs
is
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
Esp. in long sequential reads.
Jan Engelhardt
--
On Mon, Jul 31, 2006 at 06:05:01PM +0200, Łukasz Mierzwa wrote:
I gues that extens are much harder to reuse then normal inodes so when You
have something as big as portage tree filled with nano files wich are
being modified all the time then You just can't keep performance all the
time.
Jan Engelhardt schrieb am 2006-08-01:
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
18 GB SCSI disks are 1999 gear, so who cares?
Seagate didn't sell 200 GB
I didn't mean to say your particular drive were crap, but 200GB SATA
drives are low end, like it or not --
And you think an 18 GB SCSI disk just does it better because it's SCSI?
18 GB SCSI disks are 1999 gear, so who cares?
Seagate didn't sell 200 GB SATA drives at that time.
Esp. in long
Bernd Schubert [EMAIL PROTECTED] wrote:
On Monday 31 July 2006 21:29, Jan-Benedict Glaw wrote:
The point is that it's quite hard to really fuck up ext{2,3} with only
some KB being written while it seems (due to the
fragile^Wsophisticated on-disk data structures) that it's just easy to
While filesystem speed is nice, it also would be great if reiser4.x would
be
very robust against any kind of hardware failures.
Can't have both.
..and some people simply don't care about this:
If you are running a 'big' Storage-System with battery protected
WriteCache, Mirroring
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its becoming an issue more and more that the
Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds [EMAIL PROTECTED]
napisał:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER, not as some plugin architecture of its own. We
already have exactly the plugin interface we need, and it literally
Alan Cox wrote:
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its becoming an issue more and
Horst H. von Brand wrote:
Bernd Schubert [EMAIL PROTECTED] wrote:
While filesystem speed is nice, it also would be great if reiser4.x would be
very robust against any kind of hardware failures.
Can't have both.
Why not? I mean, other than TANSTAAFL, is there a technical reason for
them
Hello
On Tue, 2006-08-01 at 17:32 +0200, Łukasz Mierzwa wrote:
Dnia Fri, 28 Jul 2006 18:33:56 +0200, Linus Torvalds [EMAIL PROTECTED]
napisał:
In other words, if a filesystem wants to do something fancy, it needs to
do so WITH THE VFS LAYER, not as some plugin architecture of its own.
Christian Trefzer wrote:
On Mon, Jul 31, 2006 at 10:57:35AM -0500, David Masover wrote:
Wil Reichert wrote:
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it,
Ar Maw, 2006-08-01 am 11:44 -0500, ysgrifennodd David Masover:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Yes.
RAID deals with the case where a device fails. RAID 1 with 2 disks can
in theory detect an
On 8/1/06, David Masover [EMAIL PROTECTED] wrote:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Unless the disk ECC catches it raid won't know anything is wrong.
This is why ZFS offers block checksums... it
Alan Cox wrote:
Ar Maw, 2006-08-01 am 11:44 -0500, ysgrifennodd David Masover:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Yes.
RAID deals with the case where a device fails. RAID 1 with 2 disks can
in
Gregory Maxwell wrote:
On 8/1/06, David Masover [EMAIL PROTECTED] wrote:
Yikes. Undetected.
Wait, what? Disks, at least, would be protected by RAID. Are you
telling me RAID won't detect such an error?
Unless the disk ECC catches it raid won't know anything is wrong.
This is why ZFS
You do it turns out. Its becoming an issue more and more that the sheer
amount of storage means that the undetected error rate from disks,
hosts, memory, cables and everything else is rising.
IMHO the possibility to hit such a random-so-far-undetected-corruption
is very low with one of the
This is why ZFS offers block checksums... it can then try all the
permutations of raid regens to find a solution which gives the right
checksum.
Isn't there a way to do this at the block layer? Something in
device-mapper?
Remember: Suns new Filesystem + Suns new Volume Manager = ZFS
Alan Cox wrote:
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its becoming an issue more and
Alan, I have seen only anecdotal evidence against reiserfsck, and I have
seen formal tests from Vitaly (which it seems a user has replicated)
where our fsck did better than ext3s. Note that these tests are of the
latest fsck from us: I am sure everyone understands that it takes time
for an fsck
Ric Wheeler wrote:
Alan Cox wrote:
You do it turns out. Its becoming an issue more and more that the sheer
amount of storage means that the undetected error rate from disks,
hosts, memory, cables and everything else is rising.
I agree with Alan
You will want to try our compression
Gregory Maxwell wrote:
This is why ZFS offers block checksums... it can then try all the
permutations of raid regens to find a solution which gives the right
checksum.
ZFS performance is pretty bad in the only benchmark I have seen of it.
Does anyone have serious benchmarks of it? I suspect
Ric Wheeler wrote:
Alan Cox wrote:
Ar Maw, 2006-08-01 am 16:52 +0200, ysgrifennodd Adrian Ulrich:
WriteCache, Mirroring between 2 Datacenters, snapshotting.. etc..
you don't need your filesystem beeing super-robust against bad sectors
and such stuff because:
You do it turns out. Its
Hans Reiser writes:
Nikita Danilov wrote:
[...]
As you see, ext2 code already has multiple file plugins, with
persistent plugin id (stored in i_mode field of on-disk struct
ext2_inode).
Nikita.
So the job is already done. Good. Reiser4 can be included then.:)
Indeed,
Hans Reiser [EMAIL PROTECTED] wrote:
David Masover wrote:
If indeed it can be changed easily at all. I think the burden is on
you to prove that you can change it to be more generic, rather than
saying Well, we could do it later, if people want us to...
None of the filesystems other than
Adrian Ulrich schrieb am 2006-07-31:
And EXT3 imposes practical limits that ReiserFS doesn't as well. The big
one being a fixed number of inodes that can't be adjusted on the fly,
Right. Plan ahead.
Ok: Assume that i've read the mke2fs manpage and added more inodes to
my
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Wil
On 7/30/06, Christian Trefzer [EMAIL PROTECTED] wrote:
On Sun, Jul 30, 2006 at 11:39:42PM +0200, Christian Trefzer wrote:
In order to avoid having to pull the
Wil Reichert wrote:
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Try to post replies at the bottom, or below the context.
Yes, it does affect it a lot. I have no idea how much, and I've never
benchmarked it,
Hello Matthias,
This looks rather like an education issue rather than a technical limit.
We aren't talking about the same issue: I was asking to do it
on-the-fly. Umounting the filesystem, running e2fsck and resize2fs
is something different ;-)
Which is untrue at least for Solaris, which
Dnia Mon, 31 Jul 2006 17:57:35 +0200, David Masover [EMAIL PROTECTED]
napisał:
Wil Reichert wrote:
=)
That was sorta the plan.
Any idea how the fragmentation resulting from re-syncing the tree
affects performance over time?
Try to post replies at the bottom, or below the context.
Yes,
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
to the new LUN. At about 70% the filesystem ran out of inodes; Not a
So
Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
to the new LUN. At about 70% the filesystem ran out of
On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
to the new LUN. At about 70%
On Mon, 2006-07-31 at 18:22 +0200, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format = many small files (1-3kb))
to the new LUN.
(resending complete message to the list).
Adrian Ulrich schrieb am 2006-07-31:
Hello Matthias,
This looks rather like an education issue rather than a technical limit.
We aren't talking about the same issue: I was asking to do it
on-the-fly. Umounting the filesystem, running e2fsck and
Matthias Andree wrote:
Adrian Ulrich schrieb am 2006-07-31:
Why are a lot of Solaris-people using (buying) VxFS? Maybe because UFS
also has such silly limitations? (..and performs awkward with trillions
of files..?..)
Well, such silly limitations... looks like they are mostly hot air
spewn
On Mon, 2006-07-31 11:47:00 -0500, Dan Oglesby [EMAIL PROTECTED] wrote:
On Mon, 2006-07-31 at 18:22 +0200, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate
On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
[EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes
On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
[EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes
Jan-Benedict Glaw schrieb am 2006-07-31:
Uh? Where did you face a problem there?
With maildir, you shouldn't face any problems IMO. Even users with
zillions of mails should work properly with the dir_index stuff:
tune2fs -O dir_index /dev/hdXX
or alternatively (to start that for
On Mon, 2006-07-31 at 19:16 +0200, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 11:47:00 -0500, Dan Oglesby [EMAIL PROTECTED] wrote:
On Mon, 2006-07-31 at 18:22 +0200, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich [EMAIL PROTECTED]
wrote:
A colleague of
On Mon, 2006-07-31 at 19:32 +0200, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
[EMAIL PROTECTED] wrote:
A colleague of mine happened
Well - easy to fix, newfs again with proper inode density (perhaps 1 per
2 kB) and redo the migration.
Ehr: Such a migration (on a very busy system) takes *some* time (weeks).
Re-Doing (migrate users back / recreate the FS / start again) the whole
thing isn't really an option..
Of course
Jan-Benedict Glaw schrieb am 2006-07-31:
On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra [EMAIL PROTECTED] wrote:
On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
[EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb
On Mon, 2006-07-31 11:44:25 -0500, David Masover [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
[EMAIL PROTECTED] wrote:
A colleague of mine happened to create a ~300gb filesystem and started
to migrate Mailboxes (Maildir-style format
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw schrieb am 2006-07-31:
* reiser3: A HDD containing a reiser3 filesystem was tried to be
booted on a machine that fucked up DMA writes. Fortunately, it
crashed really soon (right after
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw schrieb am 2006-07-31:
* reiser3: A HDD containing a reiser3 filesystem was tried to be
booted on a machine that fucked up DMA writes.
Adrian Ulrich [EMAIL PROTECTED] wrote:
[...]
ZFS uses 'dnodes'. The dnodes are allocated on demand from your
available space so running out of [di]nodes is impossible.
Great to see that Sun ships a state-of-the-art Filesystem with
Solaris... I think linux should do the same...
This would
Ar Llu, 2006-07-31 am 12:17 -0700, ysgrifennodd Clay Barnes:
Of course, if ext3 were proven to be more robust against failures, I bet
the reiser team would be very interested in all the forensic data you
can offer, since, from what I've seen, they are always trying to make
reiser as good as
On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes [EMAIL PROTECTED] wrote:
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED]
wrote:
Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA writes]
Massive hardware
On 20:42 Mon 31 Jul , Alan Cox wrote:
Ar Llu, 2006-07-31 am 12:17 -0700, ysgrifennodd Clay Barnes:
Of course, if ext3 were proven to be more robust against failures, I bet
the reiser team would be very interested in all the forensic data you
can offer, since, from what I've seen, they
On Mon, Jul 31, 2006 at 06:54:06PM +0200, Matthias Andree wrote:
This looks rather like an education issue rather than a technical limit.
We aren't talking about the same issue: I was asking to do it
on-the-fly. Umounting the filesystem, running e2fsck and resize2fs
is something
Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 12:17:12 -0700, Clay Barnes [EMAIL PROTECTED] wrote:
On 20:43 Mon 31 Jul , Jan-Benedict Glaw wrote:
On Mon, 2006-07-31 20:11:20 +0200, Matthias Andree [EMAIL PROTECTED] wrote:
Jan-Benedict Glaw schrieb am 2006-07-31:
[Crippled DMA writes]
Adrian Ulrich schrieb am 2006-07-31:
Ehr: Such a migration (on a very busy system) takes *some* time (weeks).
Re-Doing (migrate users back / recreate the FS / start again) the whole
thing isn't really an option..
All the more important to think about FS requirements *before*
newfs-ing if a
On 31-Jul-06, at 11:18 PM, Horst H. von Brand wrote:
Adrian Ulrich [EMAIL PROTECTED] wrote:
[...]
ZFS uses 'dnodes'. The dnodes are allocated on demand from your
available space so running out of [di]nodes is impossible.
Great to see that Sun ships a state-of-the-art Filesystem with
1 - 100 of 213 matches
Mail list logo
