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