--xo44VMWPx7vlQ2+2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 19, 2006 at 07:42:30PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
>=20
> > Well there are issues. One is that unionfs doesn't use them right; you=
=20
> > just get the inode number from the underlying file, be it the upper or=
=20
> > lower. :-( So two files can return the same inode number.
>=20
> IIUC, the device number returned will be that of the union mount itself,
> and not of any of the underlying mounts -- which is something we already
> cope with. (via documentation :)

True, but that wasn't my concern. :-)

If you did understand my concern, please ignore this repetition.

The problem is that inode numbers are (at best) only unique within either=
=20
the upper or lower layer file system.

Say we made a live CD that used a tmpfs or some such to let you "write" on=
=20
the CD. We mount the CD as root, the tmpfs somewhere, then unionfs over=20
root.

Say /sbin/ifconfig is (lower_devt, 1000) [i.e. inode 1000 on the CD]. This=
=20
will end up as (uinfs_devt, 1000) in the hash trees. Which is mostly-ok.

Now say the user starts mucking around, and ends up downloading a program=
=20
that ends up as (upper_devt, 1000) [i.e. inode 1000 in whatever the upper=
=20
file system is]. It also will end up as (unionfs_devt, 1000).

We now have two indistinguishable files. :-(

The "easy" fix is to teach unionfs how to generate file handles.

Actually, generating and comparing-with-in-core-unionfs-vnode are easy=20
operations. VFS_FHTOVP() when the VP isn't in core anymore is more=20
questionable.

The problem is that unionfs doesn't keep centralized state, so it's hard=20
to know if upper vnode A really is the upper file for lower vnode B=20
without having done a directory lookup. So while we can store the upper=20
and lower file handles in our supplied file handle, we still have a=20
question.

Take care,

Bill

--xo44VMWPx7vlQ2+2
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFElz6UWz+3JHUci9cRAqzJAJ48jI3YWf1cCrD4V1742JVnNN1KIACfWUxm
51sXiH0AQyKKu+JoYK9BNvg=
=Od+5
-----END PGP SIGNATURE-----

--xo44VMWPx7vlQ2+2--