From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: [RFC 3/3] uniqueness of inode number, configfs, debugfs, procfs, ramfs and tmpfs Date: Thu, 22 May 2014 23:58:37 +0900 Message-ID: <6504.1400770717@jrobl> References: <1400698140-25853-1-git-send-email-hooanon05g@gmail.com> <1400698140-25853-4-git-send-email-hooanon05g@gmail.com> <30078.1400720591@jrobl> <20140522115314.GC7999@quack.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 To: Jan Kara Return-path: Received: from mail04-md.ns.itscom.net ([175.177.155.114]:46683 "EHLO mail04-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751257AbaEVO6k (ORCPT ); Thu, 22 May 2014 10:58:40 -0400 In-Reply-To: <20140522115314.GC7999@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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