From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: 64-bit inode number issues Date: Wed, 04 Oct 2006 15:18:21 +0100 Message-ID: <13246.1159971501@warthog.cambridge.redhat.com> References: <20060928164529.GA3497@infradead.org> Cc: dhowells@redhat.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:14995 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S1750888AbWJEN2l (ORCPT ); Thu, 5 Oct 2006 09:28:41 -0400 In-Reply-To: <20060928164529.GA3497@infradead.org> To: Christoph Hellwig , aviro@redhat.com Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Christoph Hellwig wrote: > 01-ino64.diff: > ACK > > 02-ino64-nfs.diff: > 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 problem doesn't just apply to NFS. It applies to any filesystem that can generate 64-bit inode numbers - which includes Ext3, I believe - so not applying the NFS patch doesn't really solve your problem (Al Viro asked me for examples of that, btw) and leaves my problem unsolved. I think any solution has to apply at the VFS level or higher. I'm not sure Al agrees though. I think we have to do one of the following: (1) Turn on inode number compression (which tries to hide the problem). (2) Give an error to stat and getdents if the inode number can't be represented by 32-bits. And I think we're going to do this, that we need to do this on a per-superblock basis or on a per-system basis, and I think it should be _off_ by default. It might also be possible to do it on a per-process level, but I suspect that'd be too much effort. David