On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra <rudy@xxxxxxxxxxxxxxx> wrote:On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
> On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
> <reiser4@xxxxxxxxxxxxxxxx> 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 preparation work wasn't done.
Of course you are right. Preparation work was not fully done. And using
ext1 would also have been possible. I suspect you are still using ext1,
cause with proper preparation it is perfectly usable.
Oh, and before people start laughing at me, here are some personal or
friend's experiences with different filesystems:
* 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 going for read-write.) After
rebooting the HDD on a sane PeeCee, it refused to boot. Starting
off some rescue system showed an _empty_ root filesystem.
* A friend's XFS data partition (portable USB/FireWire HDD) once
crashed due to being hot-unplugged off the USB. The in-kernel XFS
driver refused to mount that thing again, and the tools also
refused to fix any errors. (Don't ask, no details at my hands...)
* JFS just always worked for me. Though I've never ever had a broken
HDD where it (or it's tools) could have shown how well-done they
were, so from a crash-recovery point of view, it's untested.
* Being a regular ext3 user, I had lots of broken HDDs containing
ext3 filesystems. For every single case, it has been easy fixing
the filesystem after cloning. Just _once_, fsck wasn't able to fix
something, so I did it manually with some disk editor. This worked
well because the on-disk data structures are actually as simple as
they are.