default to inode64 on 64-bit systems
RFC PATCH 1/1 default to inode64 on 64-bit systems
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
---
fs/xfs/linux-2.6/xfs_super.c +2 -0
@@ -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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Eric Sandeen
I'm tiring of telling people to use the inode64 mount option when they are experiencing bad performance on large xfs filesystems...
Quoted 8 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Christoph Hellwig
Quoted 8 lines · 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.
Quoted 7 lines
Quoted 4 lines
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").
Signature · 9 lines
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: [email protected]
_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfsHi!
Quoted 5 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 4 lines · Eric Sandeen
I'm tiring of telling people to use the inode64 mount option when they are experiencing bad performance on large xfs filesystems...
Quoted 8 lines
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
Signature · 9 lines
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 [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 9 lines · Matthias Schniedermeyer
Quoted 8 lines · 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.
Quoted 7 lines
Quoted 4 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs
Quoted 10 lines · Eric Sandeen
Quoted 9 lines · Matthias Schniedermeyer
Quoted 8 lines · 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.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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
Signature · 9 lines
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 [email protected] http://oss.sgi.com/mailman/listinfo/xfs
Quoted 23 lines · Matthias Schniedermeyer
Quoted 10 lines · Eric Sandeen
Quoted 9 lines · Matthias Schniedermeyer
Quoted 8 lines · 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.
Quoted 6 lines
Quoted 5 lines
Quoted 4 lines
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.
Quoted 5 lines
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
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs