Re: reiserFS?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux