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

Alexander Viro (viro@math.psu.edu)
Tue, 15 Dec 1998 16:56:47 -0500 (EST)


On 15 Dec 1998, Stefan Monnier wrote:

> >>>>> "Richard" == Richard Gooch <rgooch@atnf.csiro.au> writes:
> > 1) the sledgehammer approach, which doesn't affect the VFS
> > 2) the clean approach which requires VFS changes.
>
> Having no idea what this option 2 would look like (though the little bit
> of understanding I have leads me to believe that option 2 deserves the
> mention `efficient' rather than `clean' (changing the VFS in order to provide
> another filesystem hardly sounds `clean' to me)), I have a question:

No. VFS misses a generic mechanism for stacked filesystems. lofs is not
the only consumer for that - actually umsdos and hfs are trying to do the
same. It's a VFS issue and it's done in several kernels (*BSD, for
one^Wthree). General idea behind it being that each layer can decide
whether to serve operation, decline it or pass to underlying one(s). There
is a support for lightweight layers (e.g. UID translation). There is
unionfs. BTW, Richard's devfs would also fit nice into this beast.

> With option 1, I'm pretty sure it's not hard to provide varying mount options,
> of which `ro' would be the most useful (I like to use for the same reason that
> I like to make some of my files read-only (it doesn't prevent me from modifying
> them, but it forces me to take extra steps to do it)). How about option 2 ?
> I understand that providing read-only LoFS mounts is low priority enough
> that if it's not trivial it won't be done, hence my question.
And problem with implementing that being?

-
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/