Andreas Dilger: > The simplest solution is to just change get_next_ino() to return an > unsigned long to match i_ino, instead of an int. That avoids any > overhead in the most common cases (i.e. 64-bit systems where I highly > doubt there will ever be a counter wrap). > > We've also been discussing changing i_ino to be u64 so that this works > properly on 32-bit systems accessing 64-bit filesystems, but I don't > know where that stands today. I agree that such wrap-around won't happen easily although it will happen technically. At the same time, I am not sure chaging u64 is safe to 32bit systems. If nothing wrong happens, I agree get_next_ino() returns u64. Otherwise, "if (unlikely(!inum)) inum++" is necessary. > For 32-bit systems it would be possible to use get_next_ino() for the > common case of inode numbers < 2^32, and only fall back to doing a > lookup for an already-used inode in tmpfs if the counter wraps to 1. How can tmpfs detect the wrap-around? By storing the last largest inum locally? > That would avoid overhead for 99% of users since they are unlikely > to create more than 2^32 inodes in tmpfs over the lifetime of their > system. Even in the check-if-inum-in-use case after the 2^32 wrap, > it is very unlikely that many inodes would still be in use so the > hash lookup should go relatively quickly. I agree that so many inodes won't live so long. By the way, The reason I took the bitmap approach is to keep the inum small numbers. That is my local requiment and I know it won't be necessary for generic use. J. R. Okajima -- 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
