From mboxrd@z Thu Jan  1 00:00:00 1970
From: "J. R. Okajima" <hooanon05g@gmail.com>
Subject: Re: [RFC 2/3] vfs: get_next_ino(), support for the uniqueness
Date: Fri, 23 May 2014 00:03:21 +0900
Message-ID: <7078.1400771001@jrobl>
References: <1400698140-25853-1-git-send-email-hooanon05g@gmail.com> <1400698140-25853-3-git-send-email-hooanon05g@gmail.com> <20140522115657.GD7999@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 <jack@suse.cz>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail01-md.ns.itscom.net ([175.177.155.111]:60998 "EHLO
	mail01-md.ns.itscom.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1751339AbaEVPDx (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Thu, 22 May 2014 11:03:53 -0400
In-Reply-To: <20140522115657.GD7999@quack.suse.cz>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>


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.


J. R. Okajima