Date:	Sun, 16 Jul 2006 18:26:03 +0100
From:	Lexington Luthor <Lexington.Luthor@...il.com>
To:	linux-kernel@...r.kernel.org
Subject:  Re: reiserFS?

Theodore Tso wrote:
> If the disk is known to be bad, yes, and the number of bad blocks is
> growing.  On the other hand, disks can and will have a few bad blocks,
> or bad writes that don't mean the disk is going bad, and a modern
> filesystem should be robust enough that a single failed sector doesn't
> cause the filesystem to go completely kaput.

I never trust a single hard drive with data that cannot be instantly 
re-generated anyway (eg squid caches). The fact that some people have 
hardware errors should not require every single fs to accommodate random 
bad-sectors. Feel free to use ext3 or other fs which handles this 
situation (and other situations) better, but reiserfs works fine on good 
hardware. It has been my root filesystem on many systems with no 
problems whatsoever, even with cheap SATA drives.

> In fact, one of the scary trends with hard drives is that size is
> continuing to grow expoentially, access times linearly (more or less),
> and error rates (errors per kilobytes per unit time) are remaining
> more or less constant.
> 
> The fact that reiserfs uses a single B-tree to store all of its data
> means that very entertaining things can happen if you lose a sector
> containing a high-level node in the tree.  It's even more entertaining
> if you have image files (like initrd files) in reiserfs format stored
> in reiserfs, and you run the recovery program on the filesystem.....
> 
> Yes, I know that reiserfs4 is alleged to fix this problem, but as far
> as I know it is still using a single unitary tree, with all of the
> pitfalls that this entails.
> 
> Now, that being said, that by itself is not a reason not to decide not
> to include reseirfs4 into the mainline sources.  (I might privately
> get amused when system administrators use reiserfs and then report
> massive data loss, but that's my own failure of chairty; I'm working
> on it.)  For the technical reasons why resierfs4 hasn't been
> integrated, please see the mailing list archives.
> 

I read the archives, and most of the problems pointed out during the 
review were fixed relatively quickly, followed by a flame war due to 
some suggesting that reiser4 should not be able to affect VFS semantics, 
and other such matters (which IMO should be outside of the scope of a 
code review). There has been no follow-up review as far as I can tell. 
The discussion quickly degenerated into a personality argument against 
Mr Reiser, with several developers taking a strong position against 
reiser4 (the exact reasons for which are not specified).

I don't quite know where reiser4 stands at the moment, given that it is 
in -mm and has been for a very long time. I also looked at the patch 
again, and it is indeed quite well isolated from the rest of the kernel 
so I don't understand why it is not being merged as an EXPERIMENTAL option.

Regardless, it is available in -mm for anyone to use, and last I 
checked, works incredibly well leaving other filesystems miles behind in 
terms of speed. I haven't tested it enough to comment on the 
reliability, but if it is as reliable as reiserfs, it is sufficient for 
me and many others who use RAID and a UPS.

Regards,
LL

-
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