Help with Non-Unique Inodes
From: Paul Serice
Date: Fri May 28 2004 - 09:35:32 EST
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/