From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jeff Layton Subject: Re: [RFC][PATCH] ensure i_ino uniqueness in filesystems without permanent inode numbers (via pointer conversion) Date: Fri, 17 Nov 2006 11:31:05 -0500 Message-ID: <1163781065.4565.7.camel@dantu.rdu.redhat.com> References: <1163770980.13410.39.camel@dantu.rdu.redhat.com> <20061117135037.GB18567@parisc-linux.org> <1163773304.13410.48.camel@dantu.rdu.redhat.com> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:17644 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S933714AbWKQQbI (ORCPT ); Fri, 17 Nov 2006 11:31:08 -0500 To: Matthew Wilcox In-Reply-To: <1163773304.13410.48.camel@dantu.rdu.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, 2006-11-17 at 09:21 -0500, Jeff Layton wrote: > Because the lower 8-9 bits of the inode pointer aren't significant > (presuming an inode struct size of ~400-800 bytes). If we take those out > of the picture then we extend the range of addresses that we can > uniquely squish into a 32 bit value. > > Of course, all of this depends on the idea that the slab allocator grabs > pages that are somewhat close together in the kernel's address space. > I'm trying to figure out whether that is the case or not... It sounds like we can't count on that though. A NUMA system will apparently map pages *anywhere* within the entire 64-bit address range. If that's the case, we can't count on the addresses being close enough together to make this work. Bummer, I really liked this scheme :-). I suppose I'll have to look at other options... -- Jeff