Re: reiser4 plugins

[Neil Brown <neilb@cse.unsw.edu.au>]

On Monday July 11, ninja@slaphack.com wrote:
> Stefan Smietanowski wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> > 
> > 
> >>Ok, still haven't heard much discussion of metafs vs file-as-directory,
> >>but it seems like it'd be easier in metafs.
> > 
> > 
> > Why not implement it inside the directory containg the file ?
> > 
> > Ie the metadata for /home/stesmi/foo is in /home/stesmi/.meta/foo
> > 
> > This should be suit both camps I'd think?
> 
> You still need to figure out the parent of "foo", which isn't 
> necessarily easy, especially considering that even if we store a link to 
> the parent, it will be inside the metadata.  Then you have a 
> chicken-and-egg situation.
> 
> Both camps seem to want to allow easy access to the metadata of a file, 
> whether we're given that file as an inode or as a pathname.  That's why 
> I suggested /meta/vfs and /meta/inode -- sometimes I want to look up a 
> file by name, and sometimes by inode, but either way, I should be able 
> to get its metadata.

Well, it's not really 'as an inode or as a pathname'.  It is 'as an
open file descriptor or as a path name' which is an important
difference.

Maybe it is worth repeating Al Viro's suggestion at this point.  I
don't have a reference but the idea was basically that if you open
"/foo" and get filedescriptor N, then
   /proc/self/fds/N-meta
is a directory which contains all the meta stuff for "/foo".
Then it is trivial to get the 'meta' stuff given a filedescriptor and
if you have a pathname, you can always get yourself a filedescriptor.

Then to allow
    cat /home/friend/foo/.meta.../perms
you write a little .so which redefines open, stat, and a few others to
scan for ".meta..." in the pathname and to the necessary magic, and
    export LD_PRELOAD=/that/.so

Finally you write a killer app which fundamentally relies on this
functionality, get everyone addicted to it, and *then* (and only then)
start trying to get this functionality into the kernel.

i.e. prototype new semantics in userspace.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/