[PATCH, RFC] default to inode64 on 64-bit systems

[PATCH, RFC] default to inode64 on 64-bit systems

[Eric Sandeen]

I'm tiring of telling people to use the inode64 mount option
when they are experiencing bad performance on large xfs 
filesystems...

32-bit userspace is still largely broken when it comes to still
using 32-bit stat calls, but on 64-bit systems this should be
safe.

The only problem here is moving the disk onto a 32-bit system, or using
32-bit apps.  But I think it's a small risk.

What do we think about the following?

Thanks,
-Eric

Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
---

diff --git a/fs/xfs/linux-2.6/xfs_super.c b/fs/xfs/linux-2.6/xfs_super.c
index a220d36..5d134fd 100644
--- a/fs/xfs/linux-2.6/xfs_super.c
+++ b/fs/xfs/linux-2.6/xfs_super.c
@@ -195,7 +195,9 @@ xfs_parseargs(
 	 */
 	mp->m_flags |= XFS_MOUNT_BARRIER;
 	mp->m_flags |= XFS_MOUNT_COMPAT_IOSIZE;
+#if BITS_PER_LONG == 32
 	mp->m_flags |= XFS_MOUNT_SMALL_INUMS;
+#endif
 
 	/*
 	 * These can be overridden by the mount option parsing.

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Christoph Hellwig]

On Mon, Jul 06, 2009 at 01:25:34PM -0500, Eric Sandeen wrote:
> I'm tiring of telling people to use the inode64 mount option
> when they are experiencing bad performance on large xfs 
> filesystems...
> 
> 32-bit userspace is still largely broken when it comes to still
> using 32-bit stat calls, but on 64-bit systems this should be
> safe.
> 
> The only problem here is moving the disk onto a 32-bit system, or using
> 32-bit apps.  But I think it's a small risk.
> 
> What do we think about the following?

Looks good to me, but it could use a comment in the code explaining why
we do this.

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Olaf Weber]

Christoph Hellwig writes:
> On Mon, Jul 06, 2009 at 01:25:34PM -0500, Eric Sandeen wrote:

>> I'm tiring of telling people to use the inode64 mount option
>> when they are experiencing bad performance on large xfs 
>> filesystems...
>> 
>> 32-bit userspace is still largely broken when it comes to still
>> using 32-bit stat calls, but on 64-bit systems this should be
>> safe.
>> 
>> The only problem here is moving the disk onto a 32-bit system, or using
>> 32-bit apps.  But I think it's a small risk.
>> 
>> What do we think about the following?

> Looks good to me, but it could use a comment in the code explaining why
> we do this.

Making inode64 the default on 64 bit systems seems like a good idea to
me.  But would it not be advisable to have a mount option that forces
the old behaviour, just in case?  Something like "broken32bituserspace"
(or maybe "inode32").

-- 
Olaf Weber                 SGI               Phone:  +31(0)30-6696752
                           Veldzigt 2b       Fax:    +31(0)30-6696799
Technical Lead             3454 PW de Meern  Vnet:   955-7151
Storage Software           The Netherlands   Email:  olaf@sgi.com

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Michael Weissenbacher]

Hi!
> Making inode64 the default on 64 bit systems seems like a good idea to
> me.  But would it not be advisable to have a mount option that forces
> the old behaviour, just in case?  Something like "broken32bituserspace"
> (or maybe "inode32").
> 
I think such a mount option would be a must. There is lots of 32-bit Software that cannot cope with 64-bit inodes. Unfortunately there are closed-source 32-bit apps (which can be run on 64 bit systems) where nothing can be done for 64-bit inode compatiblity in the short term. Had this problem very recently with the Zmanda Enterprise Backup Software, which forced me to remove the inode64 option.

regards,
Michael

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Matthias Schniedermeyer]

On 06.07.2009 13:25, Eric Sandeen wrote:
> I'm tiring of telling people to use the inode64 mount option
> when they are experiencing bad performance on large xfs 
> filesystems...
> 
> 32-bit userspace is still largely broken when it comes to still
> using 32-bit stat calls, but on 64-bit systems this should be
> safe.
> 
> The only problem here is moving the disk onto a 32-bit system, or using
> 32-bit apps.  But I think it's a small risk.
> 
> What do we think about the following?

What is with people running 64bit kernel but 32bit Userspace?





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Eric Sandeen]

Matthias Schniedermeyer wrote:
> On 06.07.2009 13:25, Eric Sandeen wrote:
>> I'm tiring of telling people to use the inode64 mount option
>> when they are experiencing bad performance on large xfs 
>> filesystems...
>>
>> 32-bit userspace is still largely broken when it comes to still
>> using 32-bit stat calls, but on 64-bit systems this should be
>> safe.
>>
>> The only problem here is moving the disk onto a 32-bit system, or using
>> 32-bit apps.  But I think it's a small risk.
>>
>> What do we think about the following?
> 
> What is with people running 64bit kernel but 32bit Userspace?
> 

Good point.  I wonder how many do that...   hrm.

-Eric

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Matthias Schniedermeyer]

On 07.07.2009 09:06, Eric Sandeen wrote:
> Matthias Schniedermeyer wrote:
> > On 06.07.2009 13:25, Eric Sandeen wrote:
> >> I'm tiring of telling people to use the inode64 mount option
> >> when they are experiencing bad performance on large xfs 
> >> filesystems...
> >>
> >> 32-bit userspace is still largely broken when it comes to still
> >> using 32-bit stat calls, but on 64-bit systems this should be
> >> safe.
> >>
> >> The only problem here is moving the disk onto a 32-bit system, or using
> >> 32-bit apps.  But I think it's a small risk.
> >>
> >> What do we think about the following?
> > 
> > What is with people running 64bit kernel but 32bit Userspace?
> 
> Good point.  I wonder how many do that...   hrm.

I'd guess pretty much anybody who what's to utilize the amount of RAM 
you can have nowadays, but doesn't have any single program that needs 
that amount of memory. Or, like in my case, just needs it for 
tmpfs/buffer cache.

Throw in some "i don't want to reinstall" or "my Distribution isn't 
biarch" and you have someone who justs recompils their kernel and be 
done with it. It took me only a few minutes (rotating my hardware around 
that day took way longer)





Bis denn

-- 
Real Programmers consider "what you see is what you get" to be just as 
bad a concept in Text Editors as it is in women. No, the Real Programmer
wants a "you asked for it, you got it" text editor -- complicated, 
cryptic, powerful, unforgiving, dangerous.

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

Re: [PATCH, RFC] default to inode64 on 64-bit systems

[Eric Sandeen]

Matthias Schniedermeyer wrote:
> On 07.07.2009 09:06, Eric Sandeen wrote:
>> Matthias Schniedermeyer wrote:
>>> On 06.07.2009 13:25, Eric Sandeen wrote:
>>>> I'm tiring of telling people to use the inode64 mount option
>>>> when they are experiencing bad performance on large xfs 
>>>> filesystems...
>>>>
>>>> 32-bit userspace is still largely broken when it comes to still
>>>> using 32-bit stat calls, but on 64-bit systems this should be
>>>> safe.
>>>>
>>>> The only problem here is moving the disk onto a 32-bit system, or using
>>>> 32-bit apps.  But I think it's a small risk.
>>>>
>>>> What do we think about the following?
>>> What is with people running 64bit kernel but 32bit Userspace?
>> Good point.  I wonder how many do that...   hrm.
> 
> I'd guess pretty much anybody who what's to utilize the amount of RAM 
> you can have nowadays, but doesn't have any single program that needs 
> that amount of memory. Or, like in my case, just needs it for 
> tmpfs/buffer cache.
> 
> Throw in some "i don't want to reinstall" or "my Distribution isn't 
> biarch" and you have someone who justs recompils their kernel and be 
> done with it. It took me only a few minutes (rotating my hardware around 
> that day took way longer)
> 

*nod*

I waved hands about the mount path checking whether the "mount" command
that started it was a 32-bit binary, and making a decision based on
that... and Christoph pointed out that it'd be easy ... and then he gave
me a dirty look for even thinking about it ;)

-Eric

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