On Tue, Nov 14, 2006 at 03:22:08PM -0500, Jeff Layton wrote: > 1) on filesystems w/o permanent inode numbers, i_ino values can be > larger than 32 bits, which can cause problems for some 32 bit userspace > programs on a 64 bit kernel. > > 2) many filesystems call new_inode and assume that the i_ino values they > are given are unique. They are not guaranteed to be so, since the static > counter can wrap. > > 3) after allocating a new inode, some filesystems call iunique to try to > get a unique i_ino value, but they don't actually add their inodes to > the hashtable, and so they're still not guaranteed to be unique. I agree with these problems, but I liked your earlier approach to fixing them. I don't particularly like the idr approach because, as you say, it will reuse numbers rapidly. Why is it these filesystems don't add their inodes to the hashtable? Might that not be a more profitable approach to fixing this problem? - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
