From: Lexington Luthor
Date: Sun Jul 16 2006 - 13:31:41 EST
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.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/