From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [PATCH] make last_inode counter in new_inode 32-bit on kernels that offer x86 compatability Date: Mon, 6 Nov 2006 15:01:40 -0700 Message-ID: <20061106220140.GD6012@schatzie.adilger.int> References: <1162836725.6952.28.camel@dantu.rdu.redhat.com> <20061106182222.GO27140@parisc-linux.org> <1162838843.12129.8.camel@dantu.rdu.redhat.com> <20061106202313.GA691@wohnheim.fh-wedel.de> <454FA032.1070008@redhat.com> <20061106211134.GB691@wohnheim.fh-wedel.de> <454FAAF8.8080707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: =?utf-8?Q?J=F6rn?= Engel , Jeff Layton , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Return-path: To: Eric Sandeen Content-Disposition: inline In-Reply-To: <454FAAF8.8080707@redhat.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Nov 06, 2006 15:36 -0600, Eric Sandeen wrote: > OTOH if one filesystem (say, pipes) can wrap the numbers very quickly, > while other spaces are otherwise more immune, then having it global puts > everything using it at a bit more risk. One option is having a per-sb counter (to avoid wraps on not-heavily-used filesystems), and also a per-sb flag that indicates if the counter has wrapped. If that happens, it would be possible to do a lookup in the inode hash for a conflicting inode number, and skip those. It is more overhead, but only hit in the case where there is danger (i.e. post wrap). There should also be a flag indicating if the caller is actually using the inum supplied by new_inode or not, to avoid the overhead if it just replaces i_ino with its own value. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc.