Prev: Is it possible to login as root with GDM3?
Next: Non Working Keyboard
From: Mark Allums on 23 May 2010 03:20
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-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BF8D657.2000300(a)allums.com
From: Todd A. Jacobs on 31 May 2010 04:50
On Fri, May 21, 2010 at 07:19:13PM -0500, Mark Allums wrote:

> Really? Well, I expect XFS has a substitute. If not, it should.

No, it doesn't. XFS will handle journaling issues at boot automagically,
but a real fsck requires a bit of manual intervention. I just went
through this today, and this is what you need to do:

1. Boot into rescue mode. Most people I know keep their boot and
root partitions as ext3, so this should go smoothly even if you
need to fsck your xfs partitions.

2. Unmount the XFS partitions you want to check. xfs_repair will do
evil things to mounted partitions.

3. Run xfs_repair on your unmounted partitions.

4. Remount your partitions, and check lost+found. I strongly
recommend running "debsums --all" after running xfs_repair on
/usr, /var, and so on if any problems are found.

5. Reinstall any package that may have been corrupted.

6. Reboot--not always necessary, but highly recommended.

Keep in mind that XFS only checks journaled metadata during mount--it
doesn't do any filesystem integrity checks, even when one touches
/forcefsck. Running xfs_repair once in a while is something I strongly
recommend on home systems and workstations.

--
"Oh, look: rocks!"
-- Doctor Who, "Destiny of the Daleks"


--
To UNSUBSCRIBE, email to debian-user-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/20100531083103.GF7844(a)penguin.codegnome.org
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Is it possible to login as root with GDM3?
Next: Non Working Keyboard