rfc: kill ino64 mount option

rfc: kill ino64 mount option

[Christoph Hellwig]

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..

Re: rfc: kill ino64 mount option

[Dave Chinner]

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...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

Re: rfc: kill ino64 mount option

[Mark Goodwin]

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.

Cheers

-- 

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

Re: rfc: kill ino64 mount option

[Eric Sandeen]

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

Re: rfc: kill ino64 mount option

[Christoph Hellwig]

On Sat, Jun 28, 2008 at 10:09:14AM +1000, 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.

Well, it allows showing 64bit inode numbers to userspace.  All XFS
internal codepathes are still using the smaller inode numbers and we
only add a fixed offset to them just before the inode number is returned
to userspace.

Re: rfc: kill ino64 mount option

[Christoph Hellwig]

On Fri, Jun 27, 2008 at 11:31:39PM -0500, Eric Sandeen wrote:
> I guess I'm ambivalent too, is it really that invasive?  Maybe 10, 15
> lines of code looks like?

Currently it's implemented by adding m_inoadd surrounded by an
#if XFS_BIG_INUMS.  This can be cleaned up by adding a helper ala

xfs_ino_t xfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino);

but I don't really see the point as the option seems quite useless.  But
if others thing the option is worth keeping around I'll do the helper
instead.I'll do the helper
instead.

Re: rfc: kill ino64 mount option

[Eric Sandeen]

Christoph Hellwig wrote:
> On Fri, Jun 27, 2008 at 11:31:39PM -0500, Eric Sandeen wrote:
>> I guess I'm ambivalent too, is it really that invasive?  Maybe 10, 15
>> lines of code looks like?
> 
> Currently it's implemented by adding m_inoadd surrounded by an
> #if XFS_BIG_INUMS.  This can be cleaned up by adding a helper ala
> 
> xfs_ino_t xfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino);
> 
> but I don't really see the point as the option seems quite useless.  But
> if others thing the option is worth keeping around I'll do the helper
> instead.

Well, to be honest i've never even enabled it  :)

how much does xfsqa use it?

I guess I don't really care if it goes.

-Eric

Re: rfc: kill ino64 mount option

[Nathan Scott]

On Sat, 2008-06-28 at 17:23 +0200, Christoph Hellwig wrote:
> On Sat, Jun 28, 2008 at 10:09:14AM +1000, 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.
> 
> Well, it allows showing 64bit inode numbers to userspace.  All XFS
> internal codepathes are still using the smaller inode numbers and we
> only add a fixed offset to them just before the inode number is returned
> to userspace.

I'd vote for removing it - I've used it in the past, and it didn't do
what I wanted (its not really useful for XFS testing) and the confusion
it causes with inode64 is not worth it.

cheers.

--
Nathan

Re: rfc: kill ino64 mount option

[Christoph Litauer]

Mark Goodwin schrieb:
> 
> 
> 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.

Hi,

as I have massive performance problems using xfs with millions of 
inodes, I am very interested in this "incode32+". My server is a 32 bit 
machine, so I am not able to use inode64.
Is it available?

-- 
Regards
Christoph
________________________________________________________________________
Christoph Litauer                  litauer@uni-koblenz.de
Uni Koblenz, Computing Center,     http://www.uni-koblenz.de/~litauer
Postfach 201602, 56016 Koblenz     Fon: +49 261 287-1311, Fax: -100 1311
PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2

Re: rfc: kill ino64 mount option

[Mark Goodwin]

Christoph Litauer wrote:
> Mark Goodwin schrieb:
> ..
>> 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.
>
> Hi,
>
> as I have massive performance problems using xfs with millions of
> inodes, I am very interested in this "incode32+". 

can you please post some details of the problems you're seeing?

> My server is a 32 bit machine, so I am not able to use inode64.
> Is it available?

inode32+ is only a design at the moment. An implementation is several
months away. Until then, you'll have to update your server to 64bit.

Thanks
-- Mark

Re: rfc: kill ino64 mount option

[Christoph Litauer]

Mark Goodwin schrieb:
> 
> 
> Christoph Litauer wrote:
>> Mark Goodwin schrieb:
>> ..
>>> 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.
>>
>> Hi,
>>
>> as I have massive performance problems using xfs with millions of
>> inodes, I am very interested in this "incode32+". 
> 
> can you please post some details of the problems you're seeing?

Please see thread "Performance problems with millions of inodes". If you 
don't have it anymore, I can send it to you.

> 
>> My server is a 32 bit machine, so I am not able to use inode64.
>> Is it available?
> 
> inode32+ is only a design at the moment. An implementation is several
> months away. Until then, you'll have to update your server to 64bit.

This is, sadly, not an option at the moment ...

-- 
Regards
Christoph
________________________________________________________________________
Christoph Litauer                  litauer@uni-koblenz.de
Uni Koblenz, Computing Center,     http://www.uni-koblenz.de/~litauer
Postfach 201602, 56016 Koblenz     Fon: +49 261 287-1311, Fax: -100 1311
PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2