Prev: Is it possible to login as root with GDM3?
Next: Non Working Keyboard
From: Andrei Popescu on 22 May 2010 04:00
On Fri,21.May.10, 19:19:13, Mark Allums wrote:

> Does touch /forcefsck (as root) work?

$ grep forcefsck /etc/init.d/*
/etc/init.d/checkfs.sh: if [ -f /forcefsck ] || grep -s -w -i "forcefsck" /proc/cmdline
/etc/init.d/checkfs.sh: rm -f /fastboot /forcefsck 2>/dev/null
/etc/init.d/checkroot.sh: if [ -f /forcefsck ] || grep -s -w -i "forcefsck" /proc/cmdline

Both scripts don't seem generic enough to me. Fscking for XFS should
work as long as you have the relevant tools installed.

Regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
From: Mark Allums on 22 May 2010 21:40
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.

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/4BF885C9.90705(a)allums.com
From: Tom H on 22 May 2010 21:50
On Sat, May 22, 2010 at 9:32 PM, Mark Allums <mark(a)allums.com> wrote:
> 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.

>From the SGI site:

Maximum Filesystem Size

For Linux 2.4, 2 TB. For Linux 2.6 and beyond, when using 64 bit
addressing in the block devices layer (CONFIG_LBD) and a 64 bit
platform, filesystem size limit increases to 9 million terabytes (or
the device limits). For these later kernels on 32 bit platforms, 16TB
is the current limit even with 64 bit addressing enabled in the block
layer.


--
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/AANLkTimFdUwn0C6wOpg22vgzcHBcfsERbtKpg6O4EYq1(a)mail.gmail.com
From: Stan Hoeppner on 23 May 2010 01:40
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-REQUEST(a)lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster(a)lists.debian.org
Archive: http://lists.debian.org/4BF8BFF8.8080501(a)hardwarefreak.com
From: Mark Allums on 23 May 2010 02:40
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.

Yes, Stan. Okay, Stan. Fine, Stan. Whatever you say, Stan.

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/4BF8CC08.2030407(a)allums.com
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Is it possible to login as root with GDM3?
Next: Non Working Keyboard