From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Howells Subject: Re: 64-bit inode number issues Date: Mon, 09 Oct 2006 12:32:14 +0100 Message-ID: <9285.1160393534@redhat.com> References: <20061009090124.GJ19345@melbourne.sgi.com> <20060928164529.GA3497@infradead.org> <13246.1159971501@warthog.cambridge.redhat.com> <20061007210131.GA17717@infradead.org> Cc: Christoph Hellwig , aviro@redhat.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:20924 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S932444AbWJILc2 (ORCPT ); Mon, 9 Oct 2006 07:32:28 -0400 In-Reply-To: <20061009090124.GJ19345@melbourne.sgi.com> To: David Chinner Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org David Chinner wrote: > > o turn it off by default in -mm and see what goes boom > > Will we even see the conditions for the NFS client to go boom in the > environments -mm kernels are typically run? i.e. does someone have a > test case that reliably triggers problems? I don't know about that, but we (Red Hat) have had customers logging the problem in our Bugzilla against NFS. Coming up with a reliable test case is a little tricky, as it involves setting up a server to generate fileids > 0xffffffff, and manipulating inode numbers directly generally isn't allowed... Maybe it can be done with a ramfs hack. David