Help with Non-Unique Inodes

[Paul Serice <paul@serice.net>]

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?