Correct.
> > I think I found a passable solution though. Use the lower half of the
> > 64-bit unique ID of the _first_ file entry for a file.
Note that any file has only one File Entry, no need to specify
"first."
> > The UDF spec recommends the unique ID be less than 2^32 for Macintosh
> > compatibility, but it doesn't insist on it. [This limits the number of
> > files on all media, and the number of file revisions on write-once media.]
> > So we'll have to scream if the upper half of the ID is ever > 0.
As pointed out later, this is only a small part of the problem.
> > It is possible to access a file by this inode number, but it would be
> > slow to open as the file system must be searched.
> Does the UDF volume include an index to translate from ID number to
> block number, or could you build this dynamically?
This could be built dynamically, and even stored in a non-standard
but legal manner on the media (if it is writable). This is what
Netware does. Macintosh requires that these values be valid across
mounts; it might be useful for Linux to also keep the inode numbers
consistent.
> Using a stable ID number for your inodes would allow the filesystem
> to be exported, which would be a desirable feature if it's at all
> possible. The lookup problem could be covered up by a dynamic
> index, or perhaps some other clever schemes. (For example, a well
> laid out UDF volume might have a predictable pattern of IDs allowing
> you to estimate the block position before having gone there.)
Only mastered media might be well laid out. Media written and
updated has a near zero chance of predictable ID locations.
In UDF 2.0, there is a "Unique ID Table" which maps unique IDs to
inode locations. However, the Unique ID that is referenced is for
the FID (the name), and not the File Entry (inode). For singly
linked files, these values are likely to be the same. If hard links
exist, at least one is guaranteed to be different.
A 10G hard disk drive has 20 million sectors, requiring 25 bits. A
DVD has less than 2.5 million sectors, requiring 22 bits. This
leaves 7 bits for a partition reference number. If each disc had a
line drawn at mount time, the 16 bit partition reference number and
32 bit logical block number can be mapped to a single 32 bit inode
number.
As the scheme for ext2fs will break due to media size at about the
same time this one will, we can then convert to 64 bit inode numbers,
or use the same mapping scheme used by the other FS.
-- Rob PGP Key fingerprint = D6 18 8A 07 E3 CB 09 01 D7 AE 0D 28 EF AA CC 49 Send email for my public key