--ey/N+yb7u/X9mFhi
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 16, 2003 at 10:01:34PM -0500, der Mouse wrote:
> > Nit: there are union mounts, and there is unionfs.  They are different.
>=20
> True.  Are they different in this respect?

Yes. The union mount flag causes lookup to look in an under-mounted file=20
system if it can't find a name in the root of a file system. Its main=20
reason for being is so you can mount fdescfs over /dev and still see the=20
device nodes in /dev.

> > unionfs does not guarantee unique inode numbers, as it can't.
>=20
> Or rather, it's not willing to go to the trouble to do so.  It could in
> principle maintain a mapping table, and to avoid occasional breaking of
> the sorts of code already named here, it really should.
>=20
> > Files either exist in the upper or the lower file system (as seen
> > through unionfs), so to have unique inode numbers, the two file
> > systems would have to be coordinated.
>=20
> ...or unionfs would have to map inumbers as they pass through it, which
> is what it really ought to be doing (not that I can't understand why it
> doesn't, of course).
>=20
> > More damaging to the concept of unique inode numbers is the fact that
> > the inode number of a file can change.  If it is only on the lower
> > file system, then it is written, it will be moved up to the upper
> > file system.  The two versions of the file can have different inode
> > numbers, so stat(2) calls at different times will give different
> > answers.
>=20
> Now _that_ could confuse code: fstat()ting the same fd gives different
> inumbers at different times!  Above, I'd suggested that perhaps unionfs
> should shift all inumbers over one bit, with a 0 low bit being one
> layer and a 1 low bit being the other - but that doesn't address this
> problem; I don't really see any choice except a mapping table.

Remember we started this thread talking about going to 64-bit inode=20
numbers. Let's just use the most significant bit as you describe above.

Take care,

Bill

--ey/N+yb7u/X9mFhi
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQE/4J33Wz+3JHUci9cRAnSOAJ9bK1FpPUwCY/ImgDulIhJmBiFaJwCbB2Af
gO1kj+RFLk6RJ4vimUIUjGg=
=ne0r
-----END PGP SIGNATURE-----

--ey/N+yb7u/X9mFhi--