From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin LaHaise Subject: Re: 64-bit inode number issues Date: Thu, 12 Oct 2006 14:32:32 -0400 Message-ID: <20061012183232.GG4141@kvack.org> References: <20060928164529.GA3497@infradead.org> <13246.1159971501@warthog.cambridge.redhat.com> <20061007210131.GA17717@infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Howells , aviro@redhat.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from kanga.kvack.org ([66.96.29.28]:47016 "EHLO kanga.kvack.org") by vger.kernel.org with ESMTP id S1750967AbWJLSch (ORCPT ); Thu, 12 Oct 2006 14:32:37 -0400 To: Christoph Hellwig Content-Disposition: inline In-Reply-To: <20061007210131.GA17717@infradead.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Sat, Oct 07, 2006 at 10:01:32PM +0100, Christoph Hellwig wrote: > Al commented he doesn't like that. He also think we should give the > 64bit inode numbers a try, so I'd say: > > o add an inode32 option for nfs that mirrors the XFS option > o turn it off by default in -mm and see what goes boom Unfortunately, that technique will not find any problems -- the people running systems with 64 bit inode numbers do not overlap with those running the -mm tree. The only real way to get any exercising of the relevant code paths would be to fake 64 bit inode numbers in a commonly used filesystem like ext3. The biggest difficultly with LFS has been that the API breakage is relatively silent; old applications work fine unless they encounter a large file, resulting in many lax applications. -ben -- "Time is of no importance, Mr. President, only life is important." Don't Email: .