[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20060731181120.GA9667@merlin.emma.line.org>
Date: Mon, 31 Jul 2006 20:11:20 +0200
From: Matthias Andree <matthias.andree@....de>
To: Rudy Zijlstra <rudy@...ons.demon.nl>,
Adrian Ulrich <reiser4@...nkenlights.ch>,
Matthias Andree <matthias.andree@....de>,
vonbrand@....utfsm.cl, ipso@...ppymail.ca, reiser@...esys.com,
lkml@...productions.com, jeff@...zik.org, tytso@....edu,
linux-kernel@...r.kernel.org, reiserfs-list@...esys.com
Subject: Re: the " 'official' point of view" expressed by kernelnewbies.org regarding reiser4 inclusion
Jan-Benedict Glaw schrieb am 2006-07-31:
> On Mon, 2006-07-31 18:44:33 +0200, Rudy Zijlstra <rudy@...ons.demon.nl> wrote:
> > On Mon, 31 Jul 2006, Jan-Benedict Glaw wrote:
> > > On Mon, 2006-07-31 17:59:58 +0200, Adrian Ulrich
> > > <reiser4@...nkenlights.ch> 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.
Massive hardware problems don't count. ext2/ext3 doesn't look much better in
such cases. I had a machine with RAM gone bad (no ECC - I wonder what
idiot ordered a machine without ECC for a server, but anyways) and it
fucked up every 64th bit - only in a certain region. Guess what happened
to the fs when it went into e2fsck after a reboot. Boom. Same with a
dead DPTA that lost every 16th block or so, the rescue in the first case
was swapping the RAM and "amrecover" and in the second swapping the
drive and "dsmc restore". OTOH, kernel panics on bad blocks are a no-no
of course.
> * 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...)
Don't use write caches then. (Though I've seen NUL-filled blocks in new
files or appended to files after in 2001 or 2002.)
> * 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.
SUSE removed JFS support from their installation tool for "technical
reasons" they didn't specify in the release notes. Whatever.
> ext3 always worked well for me, so why should I abandon it?
Plus, it and its tools are maintained.
--
Matthias Andree
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists