Subject: Re: large inode numbers
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Bill Studenmund <email@example.com>
Date: 12/17/2003 10:18:31
Content-Type: text/plain; charset=us-ascii
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.
> 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.
> 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.
> > 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.
> ...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).
> > 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.
> 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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)
-----END PGP SIGNATURE-----