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
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4bf8d657.2000...@allums.com
