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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/