Jan Kara: > Hum, have you observed any real problems with non-unique inode numbers > even for tmpfs? Because e.g. the NFS case you mentioned isn't IMHO right - > tmpfs sets i_generation to current time so even if inode counter wraps, > i_generation will be different and so they will be different inodes for > NFS. And the backup case isn't very convincing either - who would be > backing up tmpfs filesystem ;)? For NFS, maybe you are right. I forgot about i_generation. It won't be a problem as you wrote probably. For backup case for tmpfs, which I have not confirmed the actual case either, there several cases. - some people doesn't want to write flash medias (SSD) frequently. they store the changes on tmpfs and then move the files from tmpfs to SSD later. - this is one use-case of a stackable filesystem. By the way, I personally don't know how effective it is to make SSD to live longer. I have read a report saying "the life of flash medias are much longer than we expect" and the reporter said "we tried writing to flash medias for a long time over and over again, but could not meet the end of life." But also I have read several reports saying "I met a end of lifetime of my ssd. All writes are gone, but I can read the old contents." The uniqueness of inums may not be important, but the inum should not be zero. Do you agree about the first patch "never inum=0"? 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
