From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via idr) Date: Wed, 15 Nov 2006 10:27:20 -0700 Message-ID: <20061115172719.GK19143@parisc-linux.org> References: <1163535728.15846.21.camel@dantu.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:33479 "EHLO mail.parisc-linux.org") by vger.kernel.org with ESMTP id S1030746AbWKOR1V (ORCPT ); Wed, 15 Nov 2006 12:27:21 -0500 To: Jeff Layton Content-Disposition: inline In-Reply-To: <1163535728.15846.21.camel@dantu.rdu.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Tue, Nov 14, 2006 at 03:22:08PM -0500, Jeff Layton wrote: > 1) on filesystems w/o permanent inode numbers, i_ino values can be > larger than 32 bits, which can cause problems for some 32 bit userspace > programs on a 64 bit kernel. > > 2) many filesystems call new_inode and assume that the i_ino values they > are given are unique. They are not guaranteed to be so, since the static > counter can wrap. > > 3) after allocating a new inode, some filesystems call iunique to try to > get a unique i_ino value, but they don't actually add their inodes to > the hashtable, and so they're still not guaranteed to be unique. I agree with these problems, but I liked your earlier approach to fixing them. I don't particularly like the idr approach because, as you say, it will reuse numbers rapidly. Why is it these filesystems don't add their inodes to the hashtable? Might that not be a more profitable approach to fixing this problem?