哈哈，Linux Kernel邮件列表上关于reiserFS4的问题又打起来了。

slgx

选了几篇回答比较中肯的发上来。


On Sun, Jul 16, 2006 at 06:28:31PM +0200, Christian Trefzer wrote:
> > I don't quite understand. You are supposed to dd_rescue the whole block
> > device to a working drive and use fsck on the copy.  Whatever is lost in
> > the process must of course be restored from a recent backup. But, as a
> > friend of mine put it recently, people don't need backup, they only need
> > restore ; )

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.

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.

                                                - Ted




Joshua Hudson wrote:
>> (aside from the VFS integration debate)
> Anybody know what's in Reiser4 that VFS doesn't like (link please)?

Reiser4 plug-ins have (had?) the ability to alter the semantics of things, like making files into directories inside which you could see meta-files like file/uid and file/size which contained meta-data and such accessible as normal files to all the unix tools (which is a very good idea IMO). You could get things like chmod by just 'echo root >file/owner' or something, very nice.

This was frowned upon by kernel developers who felt that it belonged in the kernel VFS (if at all), rather than in reiser4 directly.

Regards,
LL



Jan Engelhardt wrote:
> Yes, it changes the semantics. Suddenly you can "cd linux-2.6.17.tar.bz2". But what will stat() return? S_IFDIR? S_IFREG? S_IFANY? A .tar parser in kernelspace is almost never the right thing. And then a cpio parser, because that's what initramfs'es are made of. Not to forget .zip, because that's omnipresent. Oh of course we'd also need bzip2 and gzip decoder. BASE64 and UU anyone?

Is there any particular reason that the parsers need to be in kernel-space. The reiser4 plugins seem like an ideal counterpart to FUSE. Imagine being able to automatically FUSE-mount a tar file as a filesystem when you cd into it. stat() need not return S_IFDIR since everything is a directory anyway (only normal directories need S_IFDIR, just like currently). When you cd into a tar file, a FUSE-fs kicks in and provides access to the tar file as a normal filesystem inside it - from userspace.

> I wish you a lot of fun with users in LDAP or other exotic storage methods.
> By making Everything possible through echo, you are violating the unix philosophy that one tool should do one thing (though echo does just that). And in this case, echo would be chown, chmod, tar, bzip2 all at once. This sounds familiar, I think I have seen this with explorer.exe (and its uncountable DLLs), which lets you change everything within the same window.

And why can meta-data not be accessed as files? To me, a lowly userspace developer, it seems even more inline with the UNIX way of things. bzip2 can be in userspace while still providing data to kernel space via a FUSE-like interface.

Regards,
LL






附上一个FAQ：
http://wiki.kernelnewbies.org/WhyReiser4IsNotIn

hendric

我也看到了，我觉得这个……还是由他们争论去吧。