All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: markgw@sgi.com
Cc: Christoph Hellwig <hch@lst.de>, xfs@oss.sgi.com
Subject: Re: rfc: kill ino64 mount option
Date: Fri, 27 Jun 2008 23:31:39 -0500	[thread overview]
Message-ID: <4865BEAB.4030108@sandeen.net> (raw)
In-Reply-To: <486589E7.9010705@sgi.com>

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?

-Eric

  reply	other threads:[~2008-06-28  4:30 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-27 15:39 rfc: kill ino64 mount option Christoph Hellwig
2008-06-28  0:09 ` Dave Chinner
2008-06-28  0:46   ` Mark Goodwin
2008-06-28  4:31     ` Eric Sandeen [this message]
2008-06-28 15:25       ` Christoph Hellwig
2008-06-28 19:52         ` Eric Sandeen
2008-07-01  8:07     ` Christoph Litauer
2008-07-01 14:12       ` Mark Goodwin
2008-07-01 14:45         ` Christoph Litauer
2008-06-28 15:23   ` Christoph Hellwig
2008-06-29 23:13     ` Nathan Scott

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4865BEAB.4030108@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=hch@lst.de \
    --cc=markgw@sgi.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.