[Top] [All Lists]

Re: rfc: kill ino64 mount option

To: markgw@xxxxxxx
Subject: Re: rfc: kill ino64 mount option
From: Eric Sandeen <sandeen@xxxxxxxxxxx>
Date: Fri, 27 Jun 2008 23:31:39 -0500
Cc: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <486589E7.9010705@xxxxxxx>
References: <20080627153928.GA31384@xxxxxx> <20080628000914.GE29319@disturbed> <486589E7.9010705@xxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Macintosh/20080421)
Mark Goodwin wrote:
> Dave Chinner wrote:
>> On Fri, Jun 27, 2008 at 05:39:28PM +0200, Christoph Hellwig wrote:
>>> Does anyone have objections to kill the ino64 mount option?  It's purely
>>> a debug tool to force inode numbers outside of the range representable
>>> in 32bits and is quite invasive for something that could easily be
>>> debugged by just having a large enough filesystem..
>> It's the "large enough fs" that is the problem. XFSQA uses
>> small partitions for the most part, and this allows testing
>> of 64 bit inode numbers with a standard qa config.
>> That being said, I don't really if it goes or stays...
> Although ino64 has interoperability issues with 32bit apps, it does
> have significant performance advantages over inode32 for some
> storage topologies and workloads, i.e. it's generally desirable to
> keep inodes near their data, but with large configs inode32 can't
> always oblige. ino64 is not just a debug tool.

You're confusing inode64, which allows inodes > 32 bits, with ino64,
which forces all inodes > 32 bits.  The latter debugging option is what
Christoph wants to remove...

Christoph, the "large enough fs" could be sparse I guess but you still
need to play tricks to get enough inodes up high I think.... I was
actually considering using ino64 just to see what breaks in fedora. :)

I guess I'm ambivalent too, is it really that invasive?  Maybe 10, 15
lines of code looks like?


<Prev in Thread] Current Thread [Next in Thread>