From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. R. Okajima" Subject: Re: [PATCH] vfs: get_next_ino(), never inum=0 Date: Sat, 10 May 2014 12:18:22 +0900 Message-ID: <494.1399691902@jrobl> References: <1398786301-11484-1-git-send-email-hooanon05g@gmail.com> <18587.1398793322@jrobl> <20140429175342.GA26109@lst.de> <7467.1398830934@jrobl> <926648FC-E353-4739-9E15-EAA0D34A7203@dilger.ca> Cc: Christoph Hellwig , dchinner@redhat.com, viro@zeniv.linux.org.uk, linux-fsdevel@vger.kernel.org To: Andreas Dilger Return-path: Received: from mail05-md.ns.itscom.net ([175.177.155.115]:60650 "EHLO mail05-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbaEJDSZ (ORCPT ); Fri, 9 May 2014 23:18:25 -0400 In-Reply-To: <926648FC-E353-4739-9E15-EAA0D34A7203@dilger.ca> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Andreas Dilger: > The simplest solution is to just change get_next_ino() to return an > unsigned long to match i_ino, instead of an int. That avoids any > overhead in the most common cases (i.e. 64-bit systems where I highly > doubt there will ever be a counter wrap). > > We've also been discussing changing i_ino to be u64 so that this works > properly on 32-bit systems accessing 64-bit filesystems, but I don't > know where that stands today. I agree that such wrap-around won't happen easily although it will happen technically. At the same time, I am not sure chaging u64 is safe to 32bit systems. If nothing wrong happens, I agree get_next_ino() returns u64. Otherwise, "if (unlikely(!inum)) inum++" is necessary. > For 32-bit systems it would be possible to use get_next_ino() for the > common case of inode numbers < 2^32, and only fall back to doing a > lookup for an already-used inode in tmpfs if the counter wraps to 1. How can tmpfs detect the wrap-around? By storing the last largest inum locally? > That would avoid overhead for 99% of users since they are unlikely > to create more than 2^32 inodes in tmpfs over the lifetime of their > system. Even in the check-if-inum-in-use case after the 2^32 wrap, > it is very unlikely that many inodes would still be in use so the > hash lookup should go relatively quickly. I agree that so many inodes won't live so long. By the way, The reason I took the bitmap approach is to keep the inum small numbers. That is my local requiment and I know it won't be necessary for generic use. J. R. Okajima