From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: fscache review comments, part 1 Date: Mon, 2 Oct 2006 10:39:00 -0700 Message-ID: <20061002103900.5b239d9f.akpm@osdl.org> References: <20060928164529.GA3497@infradead.org> <20489.1159796454@warthog.cambridge.redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , linux-fsdevel@vger.kernel.org, Trond Myklebust Return-path: Received: from smtp.osdl.org ([65.172.181.4]:21464 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S965166AbWJBRj1 (ORCPT ); Mon, 2 Oct 2006 13:39:27 -0400 To: David Howells In-Reply-To: <20489.1159796454@warthog.cambridge.redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Mon, 02 Oct 2006 14:40:54 +0100 David Howells wrote: > Christoph Hellwig wrote: > > > Unfortunately there's a lot of broken userspace that can't deal > > with 64bit inode numbers, so you need to make the lod behaviour > > a mount option at least, probably even the default. Given that > > we're going to run into problems like that it might make sense > > to make the option VFS-level instead of just in nfs. (Note: > > XFS already has an option like that) > > This really needs fixing quite urgently. We've seen it break ld.so/libdl (and > other things, but dynamic loading is one of the major pains as it's not > entirely obvious). > Speaking of which.. I've been having struggling a bit with vfs-make-filldir_t-and-struct-kstat-deal-in-64-bit-inode-numbers.patch nfs-represent-64-bit-fileids-as-64-bit-inode-numbers-on-32-bit-systems.patch I don't have a good understanding of what the implications are for userspace. What are the risks and what are the advantages and what the level of urgency is behind those patches. Help?