Subject: Re: metahook(9)
To: Elad Efrat <elad@NetBSD.org>
From: Bill Studenmund <firstname.lastname@example.org>
Date: 06/19/2006 17:17:24
Content-Type: text/plain; charset=us-ascii
On Mon, Jun 19, 2006 at 07:42:30PM +0200, Elad Efrat wrote:
> Bill Studenmund wrote:
> > Well there are issues. One is that unionfs doesn't use them right; you=
> > just get the inode number from the underlying file, be it the upper or=
> > lower. :-( So two files can return the same inode number.
> 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=
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=
the CD. We mount the CD as root, the tmpfs somewhere, then unionfs over=20
Say /sbin/ifconfig is (lower_devt, 1000) [i.e. inode 1000 on the CD]. This=
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=
that ends up as (upper_devt, 1000) [i.e. inode 1000 in whatever the upper=
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
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----