On Tue, 29 Jun 1999, Konrad Schroder wrote:

> Is there any reason why the various layered filesystems shouldn't be
> allowed to mount in-place?  The only current problem seems to be that
> lookup() holds the lock on the underlying directory when traversing a
> mount point, which it doesn't need to AFAICT ... for reference, the
> enclosed patches seem to work for me, for my very limited testing, so I
> can
> 	mount -t null /tmp /tmp
> 
> and it does what I expect.
> 
> (With this patch as written, one can even "mount -t null /mnt/foo /mnt"
> and hide a bunch of files.  This may or may not be desirable; but if not,
> shouldn't the check be made in nullfs_mount(9), rather than in
> mount_null(8)?)

I've thought about this, and I think it's better to do in-place mounting a
bit different.

Rather than let nullfs have both paths be the same, either pass in a flag
(or better yet have a seperate fs) which makes the mount ignore the second
path, and just knows that it's root node is the null_node on top of its
mount point.

This distinction makes no difference in this example, but some fs layers
will want to by design interpose themself between the users and the
underlying data. i.e. that's the only way they'll work.

Our data migration layer will behave that way, and I was thinking that the
keyed executables discussion we were having would be trivial with a
mount-in-place layered fs. Just have the VOP_ACCESS routine check the file
and return an error if it's unhappy. :-)

I guess another part of it for me is that I don't think nullfs is the
most trivial fs, a mounts-in-place one would be. After all, nullfs exports
one part of the tree somewhere else. :-)

Take care,

Bill