Help with Non-Unique Inodes

Help with Non-Unique Inodes

[Paul Serice]

I think I've finished changing the inode scheme in the isofs code to
better support DVDs.  Pursuant to a comment in fs/inode.c, I switched
from iget() to iget5_locked() because a 32-bit inode number was unable
to uniquely identify all the possible inodes.

I want to make sure I understand what is expected of the ino_t value
returned to the user before I post the patch:

1) Does the ino_t returned to the user have to be unique? I ask
    because the inodes on the isofs are sparse, and a unique number
    could probably be generated for the benefit of the user.  I'm
    currently returning the same hash value I pass to iget5_locked().

2) In order to avoid recursion loops, I believe the "ls" and "find"
    commands assume inodes are unique for a particular device, and they
    refuse to recurse down different directories on the same device
    with the same inode number.  If the ino_t returned to the user does
    not have to be unique, how do I guarantee that these basic
    utilities are capable of fully recursing the file system?

Re: Help with Non-Unique Inodes

[Denis Vlasenko]

On Friday 28 May 2004 17:34, Paul Serice wrote:
> I think I've finished changing the inode scheme in the isofs code to
> better support DVDs.  Pursuant to a comment in fs/inode.c, I switched
> from iget() to iget5_locked() because a 32-bit inode number was unable
> to uniquely identify all the possible inodes.
>
> I want to make sure I understand what is expected of the ino_t value
> returned to the user before I post the patch:
>
> 1) Does the ino_t returned to the user have to be unique? I ask
>     because the inodes on the isofs are sparse, and a unique number
>     could probably be generated for the benefit of the user.  I'm
>     currently returning the same hash value I pass to iget5_locked().
>
> 2) In order to avoid recursion loops, I believe the "ls" and "find"
>     commands assume inodes are unique for a particular device, and they
>     refuse to recurse down different directories on the same device
>     with the same inode number.  If the ino_t returned to the user does
>     not have to be unique, how do I guarantee that these basic
>     utilities are capable of fully recursing the file system?

inaodes are 32bit and shall be unique.

I wonder, thugh, how Linux will manage to achieve that on
exabyte-sized drives and filesystems five years from now...
--
vda