regarding the inode64 mount option

regarding the inode64 mount option

[Michael Weissenbacher]

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.

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
- Is there a way to convert the inodes back
- Why doesn't the filesystem remember that inode64 was used in the past and enable it automatically
- Do i have to pass inode64 via grub / lilo if i want to use it on my root filesystem

I haven't found any definitive clear documentation abount the pro's and con's, so maybe you can give me some hints :-)

tia,
Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: regarding the inode64 mount option

[Christoph Hellwig]

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.

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

> - Do i have to pass inode64 via grub / lilo if i want to use it on my root filesystem

Yes.

> I haven't found any definitive clear documentation abount the pro's and con's, so maybe you can give me some hints :-)

The only reason speaking against inode64 are old buggy programs that
can't cope with a 64bit ino_t, Eric had a quite scary list of those
in Fedora somewhere..

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: regarding the inode64 mount option

[Eric Sandeen]

Christoph Hellwig wrote:
> On Thu, May 28, 2009 at 02:21:44PM +0200, Michael Weissenbacher
...

>> I haven't found any definitive clear documentation abount the pro's
>> and con's, so maybe you can give me some hints :-)
> 
> The only reason speaking against inode64 are old buggy programs that 
> can't cope with a 64bit ino_t, Eric had a quite scary list of those 
> in Fedora somewhere..

http://sandeen.net/wordpress/?p=9
-Eric

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: regarding the inode64 mount option

[Michael Weissenbacher]

Hi Eric + Christoph!
> http://sandeen.net/wordpress/?p=9
This is a scary list indeed! Does this apply only to Fedora on i686 or also to x86_64?

In general, does the inode64 option make sense at all on a partition that is <1TB in size?

> Actually they should still be accessible, we just won't create new
> inodes not addressable by 32bit inode numbers.
Well, in my tests it didn't work. I tried this is on fedora core 6 with vanilla kernel 2.6.28.10 x86_64. See here:
(when mounted without inode64)
[root@mojave ~]# ls /backup/ -lha
ls: cannot access /backup/mojave_gentoo_backup: Invalid argument
total 8.0K
drwxr-xr-x  6 root         root   99 2009-05-25 18:07 .
drwxr-xr-x 26 root         root 4.0K 2009-05-28 17:38 ..
drwxr-xr-x  4 amandabackup disk   51 2009-05-07 15:46 amanda_holdings
??????????  ? ?            ?       ?                ? mojave_gentoo_backup
drwx--x--x  4 root         root   41 2009-04-29 11:57 servers
drwxrwxrwt  2 root         root    6 2009-06-02 10:38 tmp
[root@mojave ~]# ls /backup/mojave_gentoo_backup -lha
ls: cannot access /backup/mojave_gentoo_backup: Invalid argument
[root@mojave ~]#

(when mounted with inode64)
[root@mojave ~]# ls /backup/ -lha
total 12K
drwxr-xr-x  6 root         root   99 2009-05-25 18:07 .
drwxr-xr-x 26 root         root 4.0K 2009-05-28 17:38 ..
drwxr-xr-x  4 amandabackup disk   51 2009-05-07 15:46 amanda_holdings
drwxr-xr-x 23 root         root 4.0K 2009-05-05 10:53 mojave_gentoo_backup
drwx--x--x  4 root         root   41 2009-04-29 11:57 servers
drwxrwxrwt  2 root         root    6 2009-06-02 10:38 tmp
[root@mojave ~]# ls /backup/mojave_gentoo_backup/ -lha
total 27M
drwxr-xr-x 23 root root 4.0K 2009-05-05 10:53 .
drwxr-xr-x  6 root root   99 2009-05-25 18:07 ..
drwxr-xr-x  2 root root   10 2009-05-05 11:53 backup
(snipped)

The filesystem is consistent - xfs_check (3.0.1) doesn't report any problems.

thanks,
Michael

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: regarding the inode64 mount option

[Felix Blyakher]

On Jun 2, 2009, at 5:29 AM, Michael Weissenbacher wrote:

> Hi Eric + Christoph!
>> http://sandeen.net/wordpress/?p=9
> This is a scary list indeed! Does this apply only to Fedora on i686  
> or also to x86_64?
>
> In general, does the inode64 option make sense at all on a partition  
> that is <1TB in size?

inode64 doesn't do anything on a partition smaller than 1TB.

>> Actually they should still be accessible, we just won't create new
>> inodes not addressable by 32bit inode numbers.
> Well, in my tests it didn't work.

Indeed. (I thought I already replied stating this, but found my
mail in Drafts folder).

What you're seeing is expected result, which was observed in our
environment as well.

[snip]

> The filesystem is consistent - xfs_check (3.0.1) doesn't report any  
> problems.

Right, filesystem is still consistent.
And xfs_check/xfs_repair has no idea that filesystem may be mounted
without the inode64.

Felix

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: regarding the inode64 mount option

[Felix Blyakher]

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

Felix

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs