[Top] [All Lists]

Re: rfc: kill ino64 mount option

To: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
Subject: Re: rfc: kill ino64 mount option
From: Mark Goodwin <markgw@xxxxxxx>
Date: Sat, 28 Jun 2008 10:46:31 +1000
In-reply-to: <20080628000914.GE29319@disturbed>
Organization: SGI Engineering
References: <20080627153928.GA31384@xxxxxx> <20080628000914.GE29319@disturbed>
Reply-to: markgw@xxxxxxx
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Thunderbird (Windows/20080421)

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.

We have a design proposal known as "inode32+" that essentially removes
the direct mapping between inode number and disk offset. This will
provide all the layout and performance benefits of ino64 without the
interop issues.  Until inode32+ is available, we need to keep ino64.



 Mark Goodwin                                  markgw@xxxxxxx
 Engineering Manager for XFS and PCP    Phone: +61-3-99631937
 SGI Australian Software Group           Cell: +61-4-18969583

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