On Thu 22-05-14 23:58:37, J. R. Okajima wrote: > > 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"? Oh, yes, that one is definitely good. Feel free to add my: Reviewed-by: Jan Kara <jack@xxxxxxx> to that patch. Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
