From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [RFC 2/3] vfs: get_next_ino(), support for the uniqueness Date: Thu, 22 May 2014 17:12:53 +0200 Message-ID: <20140522151253.GH7999@quack.suse.cz> References: <1400698140-25853-1-git-send-email-hooanon05g@gmail.com> <1400698140-25853-3-git-send-email-hooanon05g@gmail.com> <20140522115657.GD7999@quack.suse.cz> <7078.1400771001@jrobl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Jan Kara , 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: "J. R. Okajima" Return-path: Received: from cantor2.suse.de ([195.135.220.15]:43296 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751263AbaEVPMz (ORCPT ); Thu, 22 May 2014 11:12:55 -0400 Content-Disposition: inline In-Reply-To: <7078.1400771001@jrobl> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri 23-05-14 00:03:21, J. R. Okajima wrote: > > Jan Kara: > > I don't think scanning the whole superblock list is really a viable > > alternative. That is going to contend a lot on inode_sb_list_lock and burn > > a lot of CPU when there is even moderate number of inodes in tmpfs. If we > > ever have to really use unique inode numbers for tmpfs (but I'm not > > convinced - see my other email), we should probably hash those inodes and > > use iunique()... > > Actually I tried > static int test_inode_iunique(struct super_block *sb, unsigned long ino) > which is defined fs/inode.c. > But tmpfs doesn't add inode into hash list when creating the inode. Yes, that's why I wrote that if we find that uniqueness of inode numbers in tmpfs is needed, then we should probably just make tmpfs add inodes to hash list and use iunique(). That would seem like a better solution to me. Honza -- Jan Kara SUSE Labs, CR