Re: autofs vs. Sun automount -- new fs proposal

Richard Gooch (rgooch@atnf.csiro.au)
Wed, 16 Dec 1998 17:56:14 +1100


Peter Miller writes:
>
> 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.

Wonderful!

> It is a stepping stone to a bunch of other stuff I want to do.
>
> 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.

Can you explain this a bit more? Do you mean that the whole mounted
lofs has to be indirected, or the entire filespace does?

> 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. Is this what you had in mind, Richard?

No, I haven't thought about it to that level. So far I've just been
having random thoughts and musing on the list.
Are you really just implementing "after" methods? I consider the
existing VFS methods as "before" methods (i.e. you can overload
existing methods by replacing with your own methods and then your
methods call the old ones).

If you are implementing proper before and after methods, is this going
to be done in a stackable way? So you would have a call to insert a
method at the top (and bottom!) of a stack? That would allow lots of
generality. Unfortunately, I think it would eat up RAM.

Regards,

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/