From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [PATCH 0/3] ensure unique i_ino in filesystems without permanent inode numbers (introduction) Date: Tue, 26 Dec 2006 14:16:11 -0500 Message-ID: <459174FB.3050107@redhat.com> References: <457891E7.10902@redhat.com> <45829D94.1090304@redhat.com> <20061215140057.GF30508@lazybastard.org> <4582B8AF.9060707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:40192 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932761AbWLZTQT (ORCPT ); Tue, 26 Dec 2006 14:16:19 -0500 To: =?UTF-8?B?SsO2cm4gRW5nZWw=?= , Christoph Hellwig In-Reply-To: <4582B8AF.9060707@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Jeff Layton wrote: > > > > I'm still unsure whether idr has a sufficient advantage over simp= ly > > hashing the inodes. Hch has suggested that keeping the hashtable > > smaller is good for performance. But idr adds new complexity, wh= ich > > should be avoided on its own right. So is the performance benefi= t big > > enough to add more complexity? Is it even measurable? > > > > J=C3=B6rn > > > > > A very good question. Certainly, just hashing them would be a heck o= f a > lot simpler. That was my first inclination when I looked at this, bu= t as > you said, HCH NAK'ed that idea stating that it would bloat out the > hashtable. I tend to think that it's probably not that significant, = but > that might very much depend on workload. > > I'm OK with either approach, though I'd like to have some sort of bu= yin > from Christoph on hashing the inodes before I start working on patch= es to > do that. > > Christoph, care to comment? > > -- Jeff > > I'm still in limbo on this patchset and could use some guidance. It's n= ot clear to me that IDR is really a big enough win over just hashing the i= nodes. It seems like the inode hash is pretty well optimized for fast lookups = such that even if we get some extra hash collisions it shouldn't be too awfu= l. Perhaps the best thing to do is to start with a patch that just hashes = the inodes and then fall back to using IDR (or some other scheme) if it tur= ns out that it impacts performance too much? Anyone have an opinion on what approach they think would be best here? -- Jeff - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html