--1LKvkjL3sHcu1TtY
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Jun 06, 2006 at 07:21:40PM -0400, Chapman Flack wrote:
> theo borm wrote:
> >mount_union over under
> >mount_union over under
> >ls under
> >
> >I know that there doesn't seem to be much point in doing mount_union
> >twice (I did so by mistake), however I guess a kernel panic is a bit har=
sh
>=20
> There may not be much point in mount_unioning /the exact same arguments/
> twice, but the trouble is this kind of thing happens even when you are
> doing things that would be quite useful. It seems that the current FS
> layering implementation is really fragile about layering subtrees that
> could have other mounts, and the current answer seems to be "don't do
> that" - which unfortunately rules out many things this functionality
> could be good for.
>=20
> Apparently there hasn't for some time been the right combination of
> annoyance with the current limitations among people with sufficient
> filesystem clue to get the situation changed. I am low on the FS clue
> curve myself (so far) but not on annoyance, and I would really love to
> see "make the layer FSs genuinely useful" become a project, and
> contribute to it what I could as well.

Uhm, the fact that there aren't loops in the file system is more than a=20
"File system limitation." Unix directories have always been a DAG, and a=20
lot of stuff (userland tools, for instance) could break if they weren't.

While I agree it'd be best to not panic, and I think that you should be=20
able to mount a unionfs layer over another one, things are going to need=20
to stay DAGs for a while.

One thing which will lessen the difficulties is if we change create,=20
remove, and rename processing to only look up the parent directories and=20
let the file system look up the last components in its operation. That=20
would change how we handle locking, and we could do directory lookups with=
=20
unlocked vnodes for the most part.

Take care,

Bill

--1LKvkjL3sHcu1TtY
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFEhjtmWz+3JHUci9cRAsGUAJ9O/xi0BdkEnK5hYpY4W9DlHSTxvACeOH+u
P3PYAYOyvAFW2l32hwzQnhs=
=kv+l
-----END PGP SIGNATURE-----

--1LKvkjL3sHcu1TtY--