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?

-
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/