rfc: kill ino64 mount option
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
That being said, I don't really if it goes or stays...
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 11 lines · Dave Chinner
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
That being said, I don't really if it goes or stays...
Although ino64 has interoperability issues with 32bit apps, it does have significant performance advantages over inode32 for some storage topologies and workloads, i.e. it's generally desirable to keep inodes near their data, but with large configs inode32 can't always oblige. ino64 is not just a debug tool.
We have a design proposal known as "inode32+" that essentially removes the direct mapping between inode number and disk offset. This will provide all the layout and performance benefits of ino64 without the interop issues. Until inode32+ is available, we need to keep ino64.
Cheers
Signature · 4 lines
Mark Goodwin [email protected] Engineering Manager for XFS and PCP Phone: +61-3-99631937 SGI Australian Software Group Cell: +61-4-18969583 -------------------------------------------------------------
Quoted 11 lines · Mark Goodwin
Quoted 9 lines · Dave Chinner
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
Quoted 7 lines
Quoted 1 line
That being said, I don't really if it goes or stays...
Although ino64 has interoperability issues with 32bit apps, it does have significant performance advantages over inode32 for some storage topologies and workloads, i.e. it's generally desirable to keep inodes near their data, but with large configs inode32 can't always oblige. ino64 is not just a debug tool.
You're confusing inode64, which allows inodes > 32 bits, with ino64, which forces all inodes > 32 bits. The latter debugging option is what Christoph wants to remove...
Christoph, the "large enough fs" could be sparse I guess but you still need to play tricks to get enough inodes up high I think.... I was actually considering using ino64 just to see what breaks in fedora. :)
I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 lines of code looks like?
-Eric
Quoted 2 lines · Eric Sandeen
I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 lines of code looks like?
Currently it's implemented by adding m_inoadd surrounded by an #if XFS_BIG_INUMS. This can be cleaned up by adding a helper ala
xfs_ino_t xfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino);
but I don't really see the point as the option seems quite useless. But if others thing the option is worth keeping around I'll do the helper instead.I'll do the helper
instead.
Quoted 4 lines · Christoph Hellwig
Quoted 2 lines · Eric Sandeen
I guess I'm ambivalent too, is it really that invasive? Maybe 10, 15 lines of code looks like?
Quoted 8 lines
Currently it's implemented by adding
m_inoaddsurrounded by an #ifXFS_BIG_INUMS. This can be cleaned up by adding a helper ala
xfs_ino_txfs_user_ino(struct xfs_mount *mp, xfs_ino_t ino);but I don't really see the point as the option seems quite useless. But if others thing the option is worth keeping around I'll do the helper instead.
Well, to be honest i've never even enabled it :)
how much does xfsqa use it?
I guess I don't really care if it goes.
-Eric
Quoted 21 lines · Mark Goodwin
Quoted 11 lines · Dave Chinner
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
That being said, I don't really if it goes or stays...
Although ino64 has interoperability issues with 32bit apps, it does have significant performance advantages over inode32 for some storage topologies and workloads, i.e. it's generally desirable to keep inodes near their data, but with large configs inode32 can't always oblige. ino64 is not just a debug tool.
Quoted 4 lines
We have a design proposal known as "inode32+" that essentially removes the direct mapping between inode number and disk offset. This will provide all the layout and performance benefits of ino64 without the interop issues. Until inode32+ is available, we need to keep ino64.
Hi,
as I have massive performance problems using xfs with millions of inodes, I am very interested in this "incode32+". My server is a 32 bit machine, so I am not able to use inode64. Is it available?
Signature · 7 lines
Regards Christoph ________________________________________________________________________ Christoph Litauer [email protected] Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2
Quoted 11 lines · Christoph Litauer
Mark Goodwin schrieb:
..Quoted 4 lines
We have a design proposal known as "inode32+" that essentially removes the direct mapping between inode number and disk offset. This will provide all the layout and performance benefits of ino64 without the interop issues. Until inode32+ is available, we need to keep ino64.
Hi,
as I have massive performance problems using xfs with millions of inodes, I am very interested in this "incode32+".
can you please post some details of the problems you're seeing?
Quoted 2 lines
My server is a 32 bit machine, so I am not able to use inode64. Is it available?
inode32+ is only a design at the moment. An implementation is several months away. Until then, you'll have to update your server to 64bit.
Thanks
-- Mark
Quoted 10 lines · Mark Goodwin
Quoted 7 lines · Christoph Litauer
Mark Goodwin schrieb:
..Quoted 4 lines
We have a design proposal known as "inode32+" that essentially removes the direct mapping between inode number and disk offset. This will provide all the layout and performance benefits of ino64 without the interop issues. Until inode32+ is available, we need to keep ino64.
Quoted 6 lines
Quoted 4 lines
Hi,
as I have massive performance problems using xfs with millions of inodes, I am very interested in this "incode32+".
can you please post some details of the problems you're seeing?
Please see thread "Performance problems with millions of inodes". If you don't have it anymore, I can send it to you.
Quoted 6 lines
Quoted 3 lines
My server is a 32 bit machine, so I am not able to use inode64. Is it available?
inode32+ is only a design at the moment. An implementation is several months away. Until then, you'll have to update your server to 64bit.
This is, sadly, not an option at the moment ...
Signature · 7 lines
Regards Christoph ________________________________________________________________________ Christoph Litauer [email protected] Uni Koblenz, Computing Center, http://www.uni-koblenz.de/~litauer Postfach 201602, 56016 Koblenz Fon: +49 261 287-1311, Fax: -100 1311 PGP-Fingerprint: F39C E314 2650 650D 8092 9514 3A56 FBD8 79E3 27B2
Quoted 9 lines · Dave Chinner
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
Well, it allows showing 64bit inode numbers to userspace. All XFS internal codepathes are still using the smaller inode numbers and we only add a fixed offset to them just before the inode number is returned to userspace.
Quoted 7 lines · Christoph Hellwig
Quoted 6 lines · Dave Chinner
Quoted 4 lines · Christoph Hellwig
Does anyone have objections to kill the ino64 mount option? It's purely a debug tool to force inode numbers outside of the range representable in 32bits and is quite invasive for something that could easily be debugged by just having a large enough filesystem..
Quoted 8 lines
Quoted 3 lines
It's the "large enough fs" that is the problem. XFSQA uses small partitions for the most part, and this allows testing of 64 bit inode numbers with a standard qa config.
Well, it allows showing 64bit inode numbers to userspace. All XFS internal codepathes are still using the smaller inode numbers and we only add a fixed offset to them just before the inode number is returned to userspace.
I'd vote for removing it - I've used it in the past, and it didn't do what I wanted (its not really useful for XFS testing) and the confusion it causes with inode64 is not worth it.
cheers.
--
Nathan