On 5/23/2010 12:41 AM, Stan Hoeppner wrote:
Mark Allums put forth on 5/22/2010 8:32 PM:That's a very odd thing. Thanks for correcting me. I would not have guessed that file system structure would be dependent on OS word width. I mean, that seems like a catastrophic implementation/design bug.It's not an instruction word width issue, but has more to do with the width of the data registers, and addressable virtual memory of 32bit platforms.
I mistyped. Of course, I meant machine word width, not "OS" word width. And I use the term "machine word width" to mean "register".
Running a 32bit kernel, how do you process 64bit inode numbers in 32bit data registers? That would require a lot of code changes for a dying platform (ia32). Add the fact that i386 kernels have a maximum virtual address space of 16TB, which, not coincidentally, is the maximum 32bit XFS filesystem size. I think this last point is really the key to this issue, because if you were to add support to 32bit XFS for 9 exabyte filesystems, you'd only be able to mmap files up to the 16TB boundary. AFAIK, most I/O these days is done with mmap. If you have files or filesystems larger than your virtual memory space, you can't mmap anything beyond that address boundary.
Is 32-bit dying or not? When I express an opinion that new installs should be 64-bit, someone takes me to task, and claim that 32-bit can do everything 32-bit can do.
Yes, Stan. Making 32-bit Linux work with 64-bit inodes would require work. It would mean touching very many places in a fairly large codebase, and then a lot of testing would need to be done. Yes. I think it is worth doing, but, I am not a part of the XFS (or kernel) maintenance team(s), and I never will be. I am only a potential user. I guess my opinion is not worth much.
I think I do have a problem sometimes when I post: I have a bit of a terminology gap with people like yourself. Please try not to hold me to a 100% literal interpretation. Certainly, correct my factual errors, as Ron Johnson did when I suggested the OP use tune2fs to cause an fsck to be performed on his XFS partition.
So when I say something to the effect that it is a design error for some piece of code not to be able to handle what is essentially a data width problem, please understand that it is an opinion based partly on experience, partly on theory, and and partly on speculation. I don't pretend otherwise. I speculate. And I think, based on theory and speculation, that it is odd that no one has fixed what must surely be a problem for some users.
Perhaps it isn't a trivial bug to fix. When the code was first designed, it was certainly a design decision. It was a decision *then*. But it is a *bug* now. Perhaps it isn't worth investing the effort to fix it. But it is certainly fixable.
Whether you would use mmap for the first 16TB or not would just be another design decision. If you had a filesystem larger than that, obviously, you wouldn't be using mmap for a window larger than that. There would be potential wraparound bugs. Performance would probably be terrible. But it would allow someone to get the job done.
MAA