On Mon, 2005-05-30 at 01:19 -0700, Hans Reiser wrote: > [EMAIL PROTECTED] wrote: > > >On Fri, 27 May 2005 23:56:35 CDT, David Masover said: > > > > > > > >>Hans, comment please? Is this approaching v5 / v6 / Future Vision? It > >>does seem more than a little "clunky" when applied to v4... > >> > >> > Well, if you read our whitepaper, we consider relational algebra to be a > functional subset of what we will implement (which implies we think > relational algebra should be possible in the filesystem naming.) > > > > >I'm not Hans, but I *will* ask "How much of this is *rationally* doable > >without some help from the VFS?". > > > Think of VFS as a standards committee. That means that 5-15 years after > we implement it, they will copy it, break it, and then demand that we > conform to their breakage. > > Anytimes someone says it should go into VFS, what they really mean is, > nobody should get ahead of them because it will increase their workload.;-) > > VFS is a baseline. Once you support VFS, and your performance is good, > you can start to innovate. Next year we finally start to seriously > innovate, after 10 years of groundwork. The storage layer was never the > interesting part of our plans, not to me.....
Why innovate in the filesystem though, when it would work just as well or better in the VFS layer? Files as directories and meta-files would work for all filesystems. Ext3 with extended attributes could support the same file structures as Reiser4. Reiser4 would then be the most efficient implementation of the general case. From the last LKML discussion, it didn't look to me as if the kernel maintainers are going to accept Reiser4's stranger features into the mainline kernel, so if you're going to be implementing and maintaining them separately anyway, why not do it in the implementation of all namespaces, in the VFS code? -- Jonathan Briggs <[EMAIL PROTECTED]> eSoft, Inc.
signature.asc
Description: This is a digitally signed message part
