--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 04, 2006 at 10:26:44PM +0200, Rodolphe De Saint Leger wrote:
> Hi,
>=20
> I'm trying to add a mount flag to layer mount to make them able to
> lookup through mount points.
>=20
> Apparently, it seems to work, but is it ok to do a such thing ?

I dislike it.

There really needs to be no more than one file system under a layered=20
file system (modulo how unionfs merges two file systems into one).

The biggest issues I see are: 1) file handles will no longer work, so you
can't do a number of things you can do now (like nfs export). The problem
is that if you have multiple mount points under a null layer, you have to
map the VFS_FHTOVP() call to the right under layer. Even if you somehow
remembered the underlying file system, NFS gets messy. NFS is supposed to
be stateless, so if the server reboots, you can get calls to underlying=20
file systems the layer doesn't know exist.

2) Getting inode numbers right will be a pain. Many tools assume that if=20
the "dev_t" and inode number returned in the stat of two file names are=20
the same, then the two pathnames are hardlinked to the same file.=20
Currently, all layered file systems other than unionfs avoid problems here=
=20
as they pass the inode number up from the underlying fs unmodified.

With what you propose, we would have to add some sort of check and/or=20
mapping to get this right.

Given all of that work, I don't see how what you describe is worth it.


One thing I have thought of doing, though, is adding a feature where by
when we find a mounted-on vnode in the underlying file system and no
coresponding layer vnode, we automatically fix up a new layer. To do this,
we would look up the mounted vnode (i.e. what you did now), create a vnode
in our layer for it, then automatically create a mounted layered file
system, just like ours, on top of the layered vnode. The new layer would=20
use the mounted vnode as the root of its underlying file system.

Beside automatic magic, the one other concern I have with this is that the=
=20
path names for the "mounted from" path for the auto layer could be a pain=
=20
to fill in.

Take care,

Bill

--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFEWna3Wz+3JHUci9cRAg0fAKCHQxyF7xajYWsxNnGtQE0Ez29p9QCglpbY
zLm5MnkLSKR8zYNVv0dUXso=
=nsqO
-----END PGP SIGNATURE-----

--NDin8bjvE/0mNLFQ--