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

From: "J. R. Okajima" <hooanon05g@gmail.com>
To: Jan Kara <jack@suse.cz>
Cc: linux-fsdevel@vger.kernel.org, adilger@dilger.ca, hch@lst.de,
	dchinner@redhat.com, viro@zeniv.linux.org.uk, jlbec@evilplan.org,
	gregkh@linuxfoundation.org, hughd@google.com
Subject: Re: [RFC 3/3] uniqueness of inode number, configfs, debugfs, procfs, ramfs and tmpfs
Date: Thu, 22 May 2014 23:58:37 +0900	[thread overview]
Message-ID: <6504.1400770717@jrobl> (raw)
In-Reply-To: <20140522115314.GC7999@quack.suse.cz>

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