Re: [RFC 3/3] uniqueness of inode number, configfs, debugfs, procfs, ramfs and tmpfs

["J. R. Okajima" <hooanon05g@gmail.com>]

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