[Top] [All Lists]

Re: regarding the inode64 mount option

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: regarding the inode64 mount option
From: Felix Blyakher <felixb@xxxxxxx>
Date: Tue, 2 Jun 2009 11:13:22 -0500
Cc: Michael Weissenbacher <mw@xxxxxxxxxxxx>, xfs@xxxxxxxxxxx
In-reply-to: <20090528145612.GA14684@xxxxxxxxxxxxx>
References: <4A1E81D8.7010706@xxxxxxxxxxxx> <20090528145612.GA14684@xxxxxxxxxxxxx>
[my unsent mail from yesterday, mostly for the second blob]

On May 28, 2009, at 9:56 AM, Christoph Hellwig wrote:

On Thu, May 28, 2009 at 02:21:44PM +0200, Michael Weissenbacher wrote:
Hi XFS-List!
I understand that the inode64 mount option allows inodes to be created beyond 1TB. There are also certain performance problems that can be cured by using this option when handling LOTS of inodes. During my tests i noticed that enabling it is like a one- way street. Inodes created with inode64 enabled aren't accessible when the option is left out.

Actually they should still be accessible, we just won't create new
inodes not addressable by 32bit inode numbers.

The inodes are indeed accessible by most apps, but those 32bit
apps using stat() (vs. stat64() ) will get confused and
may bailout processing such inodes all together.

Now i got a few questions:
- Does the inode64 option work only on 64bit architectures or is it also possible to use it with i686

It is available for 32bit kernels starting with kernel 2.6.29.

- Is there a way to convert the inodes back

There's an xfs_reno tool ported from IRIX to renumber the inodes. I'll
see if I can finally get it packaged.

- Why doesn't the filesystem remember that inode64 was used in the past and enable it automatically

Good question.  We could introduce a flag in the superblock for this.

Agree, it's a good idea to record that inode64 was used on
previous mount, but I don't think we should enable it
automatically. Though, providing the warning will be good.


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