On Wed, Apr 30, 2014 at 02:42:02AM +0900, J. R. Okajima wrote: > > > There is another unpleasant effect when get_next_ino() wraps > > around. When there is a file whose inum=100 on tmpfs, a new file may get > > inum=100. I am not sure what will happen when the duplicated inums exist > > on tmpfs. ... > > Undeterministic behaviour when exporting via NFS? If you care about really unique inode numbers you shouldn't use get_next_ino but something like an idr allocator. The default i_ino assigned in new_inode() from which get_next_ino was factored out was mostly intended for small synthetic filesystems with few enough inodes that it wouldn't wrap around. And yes, file handle based lookups are screwed by duplicated inode numbers, as are tools trying to do file level de-duplication, mostly in the backup or achival space. -- 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
