Subject: Re: large inode numbers
To: None <tech-kern@NetBSD.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 12/16/2003 22:01:34
> Nit: there are union mounts, and there is unionfs. They are different.
True. Are they different in this respect?
> 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
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.
/~\ The ASCII der Mouse
\ / Ribbon Campaign
X Against HTML firstname.lastname@example.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B