>
> Richard Gooch writes...
> > You are describing lofs, the loopback filesystem. There are
> > apparentely 2 ways to implement this:
> >
> > 1) the sledgehammer approach, which doesn't affect the VFS
> >
> > 2) the clean approach which requires VFS changes.
> >
> > (1) could possibly go in before 2.2 is released, provided that someone
> > has the time to code it up quickly and test it and have tested widely
> > before Linus releases 2.2. Volunteers step forwards now.
> >
> > (2) this is definately a 2.3 job. By the time 2.3 is released, I
> > should (hopefully) have more time available and I could then implement
> > this. Alternatively, hpa (author of autofs) or someone else may beat
> > me to it. Hopefully anyone who starts working on it will first send an
> > annoucement to linux-kernel so we don't end up with multiple efforts.
>
> I have a mostly-working 2.1 lofs.
Where?
> It is a stepping stone to a bunch of other stuff I want to do.
;-) Guess that we'ld better sync our activities in that area.
> You have to indirect the whole tree, no just the top-level directory,
> otherwise 'pwd' goes bozo - e.g. loopback a read-only version of
> /usr into a chrooted environment.
No objections here.
>
> And, yes, I agree that VFS changes would help (a *lot*). I've
> written a bunch of vfs_* functions, to actually provide a consistent
> (well, more consistent) and usable VFS API, capturing many of the
> things that must happen before and after each of the VFS "methods"
> are invoked.
Umm... I'm not sure that I understood you right, but most of the
stuff surrounding methods belongs to VFS. Putting sticky bit enforcement
into filesystems is crazy, for one. I'ld rather prefer to see
a) light-weight inodes (separate foo_inode_info)
b) symmetric interface for layers.
c) resolving races in VFS and atomic lookups (I will do it as soon
as I'll finish with FAT)
e) fs-independent permission checks done in VFS. If fs can map its
attributes on the generic ones it would bloody better do it.
f) localization of methods' calls. Right now they are scattered
over VFS + there is a bunch of calls in knfsd. Not good.
h) mechanism for filesystems without natural inode numbers. What
I'm doing right now to FAT looks so: consider every ->lookup() as creation
of inode (get_empty_inode(),...,inode_insert_cache()), keep location of
directory entry in fs-specific part of inode (instead of i_ino), make
readdir() do d_lookup() to check for already assigned numbers (as ncpfs
does). It asks for generic mechanism doing the same thing. That way we
don't change d_inode under the living dentry and avoid a lot of locking
lossage.
I'm afraid that we'll have to start from cleaning namei.c and
bloody cleaning up existing filesystems. Otherwise we'll get a majestic
pile of broken code at hands. Not my idea of fun ;-/
Don't forget - part of inode methods is fixed by a slew of
third-party device drivers. Would you like to fix them (or contact all
their authors)? It would be great if we could get in touch with folks
writing separate filesystems (hint, hint). Some of fixes WILL break their
code (see rmdir ones). At least we'ld better have a list of URLs for
existing third-party filesystems.
> Is this what you had in mind, Richard?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/