Mark Allums put forth on 5/22/2010 8:32 PM: > On 5/22/2010 2:22 AM, Stan Hoeppner wrote: >> Mark Allums put forth on 5/21/2010 7:37 PM: >> >>> 64-bit Knoppix is in the TODO list of Klaus Knopper, but for rescue >>> purposes, 32-bit should be able to do the job. >> >> This is incorrect _if_ the filesystem is large and thus contains 64 >> bit inode >> numbers. If there is any remote possibility that 64 bit inodes exist >> on the >> XFS filesystem to be checked/repaired, the rescue kernel and xfsprogs >> need to >> be 64 bit binaries. >> > > 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. 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. -- Stan -- 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/4bf8bff8.8080...@hardwarefreak.com
