xfs partition refuses to mount

xfs partition refuses to mount

[Vincent van de Camp]

I run a gentoo system, and after updating python 2.3.3-r1, the emerge 
-DU that was running segfaulted. I had to hard reset the computer and 
since then the main (and only) partition refuses to mount.

The motherboard is an A7N8X Deluxe, with a Western Digital 36GB SATA 
Raptor drive. Kernel version was 2.6.5. The message:

XFS mounting filesystem ide2(33,1)
Starting XFS recovery on filesystem: ide2(33,1) (dev: ide2(33,1))
XFS assertion failed: *(uint *)dp == XFS_TRANS_HEADER_MAGIC, file: 
xfs_log_recover.c, line: 1424
kernel BUG at debug.c:55!
invalid operand: 0000
ohci1394 ieee1394 3c59x floppy serial isa-pnp usb-storage hid usb-ohci 
ehci-hcd usbcore
CPU:    0
EIP:    0010:[<c02c4f96>]    Not tainted
EFLAGS: 00010282
eax: 00000061   ebx: 00000001   ecx: 00000000   edx: f773c000
esi: f6d79780   edi: 00000034   ebp: 00000008   esp: f6de7b68
ds: 0018   es: 0018   ss: 0018
Process mount (pid: 2689, stackpage=f6de7000)
Stack: c04180e0 c0414be0 c03ed901 00000590 c029d43e c0414be0 c03ed901 
00000590
        f7340720 f7c36260 f6d79774 00000008 c029f6e5 f7340720 f6d79780 
00000034
        f6d79780 00000020 f6d7a200 00000001 f7341200 f6de7c24 f73d1070 
00000011
Call Trace: [<c029d43e>]  [<c029f6e5>]  [<c02a04d5>]  [<c0308912>] 
[<c02a0dd4>]  [<c02a0e96>]  [<c02a10a4>]  [<c029735b>]  [<c02a523f>] 
[<c02b995a>]  [<c02a4782>]  [<c02b953c>]  [<c0294df0>]  [<c02ae54c>] 
[<c02c4151>]  [<c02c3f80>]  [<c01daea5>]  [<c01db87d>]  [<c01eaedb>] 
[<c01dbafb>]  [<c01ebcf1>]  [<c01ebf68>]  [<c01ebdef>]  [<c01ec2c8>] 
[<c01aaab3>]
Code: 0f 0b 37 00 6f f1 3e c0 83 c4 10 c3 89 f6 8b 0d e0 95 10 c0

If there's a separate xfs list, I'll be happy to post it there too.

Thanks,
Vincent

Re: xfs partition refuses to mount

[Steve Lord]

Vincent van de Camp wrote:
> I run a gentoo system, and after updating python 2.3.3-r1, the emerge 
> -DU that was running segfaulted. I had to hard reset the computer and 
> since then the main (and only) partition refuses to mount.
> 
> The motherboard is an A7N8X Deluxe, with a Western Digital 36GB SATA 
> Raptor drive. Kernel version was 2.6.5. The message:
> 
> XFS mounting filesystem ide2(33,1)
> Starting XFS recovery on filesystem: ide2(33,1) (dev: ide2(33,1))
> XFS assertion failed: *(uint *)dp == XFS_TRANS_HEADER_MAGIC, file: 
> xfs_log_recover.c, line: 1424
> kernel BUG at debug.c:55!
> invalid operand: 0000
> ohci1394 ieee1394 3c59x floppy serial isa-pnp usb-storage hid usb-ohci 
> ehci-hcd usbcore
> CPU:    0
> EIP:    0010:[<c02c4f96>]    Not tainted
> EFLAGS: 00010282
> eax: 00000061   ebx: 00000001   ecx: 00000000   edx: f773c000
> esi: f6d79780   edi: 00000034   ebp: 00000008   esp: f6de7b68
> ds: 0018   es: 0018   ss: 0018
> Process mount (pid: 2689, stackpage=f6de7000)
> Stack: c04180e0 c0414be0 c03ed901 00000590 c029d43e c0414be0 c03ed901 
> 00000590
>        f7340720 f7c36260 f6d79774 00000008 c029f6e5 f7340720 f6d79780 
> 00000034
>        f6d79780 00000020 f6d7a200 00000001 f7341200 f6de7c24 f73d1070 
> 00000011
> Call Trace: [<c029d43e>]  [<c029f6e5>]  [<c02a04d5>]  [<c0308912>] 
> [<c02a0dd4>]  [<c02a0e96>]  [<c02a10a4>]  [<c029735b>]  [<c02a523f>] 
> [<c02b995a>]  [<c02a4782>]  [<c02b953c>]  [<c0294df0>]  [<c02ae54c>] 
> [<c02c4151>]  [<c02c3f80>]  [<c01daea5>]  [<c01db87d>]  [<c01eaedb>] 
> [<c01dbafb>]  [<c01ebcf1>]  [<c01ebf68>]  [<c01ebdef>]  [<c01ec2c8>] 
> [<c01aaab3>]
> Code: 0f 0b 37 00 6f f1 3e c0 83 c4 10 c3 89 f6 8b 0d e0 95 10 c0
> 
> If there's a separate xfs list, I'll be happy to post it there too.
> 
> Thanks,
> Vincent

Added the XFS mailing list to the cc list....

You have turned on XFS debug, which is really a developer option. It
looks like you have a corrupt journal though. A non debug kernel may
still refuse to mount it and you would need to run xfs_repair from
a rescue disk in that case.

Steve

Re: xfs partition refuses to mount

[Ricky Beam]

On Sat, 29 May 2004, Steve Lord wrote:
>You have turned on XFS debug, which is really a developer option. It
>looks like you have a corrupt journal though. A non debug kernel may
>still refuse to mount it and you would need to run xfs_repair from
>a rescue disk in that case.

Unless xfs_repair has been changed recently, all it will be able to do it
delete (zero) the journal.  If it detects metadata in the journal, it'll
stop and tell you mount the filesystem to replay the journal.  Personally,
I think that's sorta stupid... if I could mount the fs, I wouldn't be
running xfs_repair. (I've had the journal become spooge on a sparc64
box a few times.)

There should be a way to instruct the kernel's rootfs mount to not look
at the log.  I don't know if one can pass any generic mount options at
boot. ("ro"/"rw" and rootfs type, but I don't know of any others.)  This
would be handy for more than just xfs, btw.

--Ricky

Re: xfs partition refuses to mount

[Vincent van de Camp]

Thanks for the information. The debug option certainly was not intentional.
I have tried fsck.xfs, but that didn't do anything but print a version 
message. I haven't tried xfs_repair. I didn't know of it's existance. 
That's definately something to try out next time, though.

Thanks,
Vincent

Steve Lord wrote:
> Vincent van de Camp wrote:
> 
>> I run a gentoo system, and after updating python 2.3.3-r1, the emerge 
>> -DU that was running segfaulted. I had to hard reset the computer and 
>> since then the main (and only) partition refuses to mount.
>>
>> The motherboard is an A7N8X Deluxe, with a Western Digital 36GB SATA 
>> Raptor drive. Kernel version was 2.6.5. The message:
>>
>> XFS mounting filesystem ide2(33,1)
>> Starting XFS recovery on filesystem: ide2(33,1) (dev: ide2(33,1))
>> XFS assertion failed: *(uint *)dp == XFS_TRANS_HEADER_MAGIC, file: 
>> xfs_log_recover.c, line: 1424
>> kernel BUG at debug.c:55!
>> invalid operand: 0000
>> ohci1394 ieee1394 3c59x floppy serial isa-pnp usb-storage hid usb-ohci 
>> ehci-hcd usbcore
>> CPU:    0
>> EIP:    0010:[<c02c4f96>]    Not tainted
>> EFLAGS: 00010282
>> eax: 00000061   ebx: 00000001   ecx: 00000000   edx: f773c000
>> esi: f6d79780   edi: 00000034   ebp: 00000008   esp: f6de7b68
>> ds: 0018   es: 0018   ss: 0018
>> Process mount (pid: 2689, stackpage=f6de7000)
>> Stack: c04180e0 c0414be0 c03ed901 00000590 c029d43e c0414be0 c03ed901 
>> 00000590
>>        f7340720 f7c36260 f6d79774 00000008 c029f6e5 f7340720 f6d79780 
>> 00000034
>>        f6d79780 00000020 f6d7a200 00000001 f7341200 f6de7c24 f73d1070 
>> 00000011
>> Call Trace: [<c029d43e>]  [<c029f6e5>]  [<c02a04d5>]  [<c0308912>] 
>> [<c02a0dd4>]  [<c02a0e96>]  [<c02a10a4>]  [<c029735b>]  [<c02a523f>] 
>> [<c02b995a>]  [<c02a4782>]  [<c02b953c>]  [<c0294df0>]  [<c02ae54c>] 
>> [<c02c4151>]  [<c02c3f80>]  [<c01daea5>]  [<c01db87d>]  [<c01eaedb>] 
>> [<c01dbafb>]  [<c01ebcf1>]  [<c01ebf68>]  [<c01ebdef>]  [<c01ec2c8>] 
>> [<c01aaab3>]
>> Code: 0f 0b 37 00 6f f1 3e c0 83 c4 10 c3 89 f6 8b 0d e0 95 10 c0
>>
>> If there's a separate xfs list, I'll be happy to post it there too.
>>
>> Thanks,
>> Vincent
> 
> 
> Added the XFS mailing list to the cc list....
> 
> You have turned on XFS debug, which is really a developer option. It
> looks like you have a corrupt journal though. A non debug kernel may
> still refuse to mount it and you would need to run xfs_repair from
> a rescue disk in that case.
> 
> Steve
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: xfs partition refuses to mount

[Steve Lord]

Ricky Beam wrote:
> On Sat, 29 May 2004, Steve Lord wrote:
> 
>>You have turned on XFS debug, which is really a developer option. It
>>looks like you have a corrupt journal though. A non debug kernel may
>>still refuse to mount it and you would need to run xfs_repair from
>>a rescue disk in that case.
> 
> 
> Unless xfs_repair has been changed recently, all it will be able to do it
> delete (zero) the journal.  If it detects metadata in the journal, it'll
> stop and tell you mount the filesystem to replay the journal.  Personally,
> I think that's sorta stupid... if I could mount the fs, I wouldn't be
> running xfs_repair. (I've had the journal become spooge on a sparc64
> box a few times.)

Yes, xfs_repair will not replay a log, and if it finds dirty metadata in
the log it wants you to replay it via mount. Having xfs_repair able to
replay the log would be handy, but if mount cannot replay it, then
repair will not either. xfs_repair -L bypasses this check and resets
the log. Following that it does a complete consistancy check and
fixup of metadata - it does a good job in most cases. Note that it
deletes lost+found, and if you had files in there, they would be
disconnected and get put back in lost+found again.

The whole reason for -L was customers who automatically ran xfs_repair
after a crash, and hence threw away anything which was in the log. So
it is more of a stop and think what you are doing option.

> 
> There should be a way to instruct the kernel's rootfs mount to not look
> at the log.  I don't know if one can pass any generic mount options at
> boot. ("ro"/"rw" and rootfs type, but I don't know of any others.)  This
> would be handy for more than just xfs, btw.
> 

You can mount norecovery,ro - but no guarantees that it will stay up
long. See Documentation/filesystems/xfs.txt for a list of xfs mount
options.

Steve

Re: xfs partition refuses to mount

[Ricky Beam]

On Sat, 29 May 2004, Steve Lord wrote:
>Yes, xfs_repair will not replay a log, and if it finds dirty metadata in
>the log it wants you to replay it via mount. Having xfs_repair able to
>replay the log would be handy, but if mount cannot replay it, then
>repair will not either.

Except xfs_repair can be a lot smarter in the process.  I would never
suggest putting 3MB worth of log recovery code in the kernel when it's
likely to very be used.  Such "fogiving" log recovery belongs in userland.

>The whole reason for -L was customers who automatically ran xfs_repair
>after a crash, and hence threw away anything which was in the log. So
>it is more of a stop and think what you are doing option.

"Don't do that." *grin*

>> There should be a way to instruct the kernel's rootfs mount to not look
>> at the log.  I don't know if one can pass any generic mount options at
>> boot. ("ro"/"rw" and rootfs type, but I don't know of any others.)  This
>> would be handy for more than just xfs, btw.
>
>You can mount norecovery,ro - but no guarantees that it will stay up
>long. See Documentation/filesystems/xfs.txt for a list of xfs mount
>options.

I know I can tell the userland mount (/sbin/mount) to not replay the log.
But I'm looking for a way to tell the kernel, at boot, to not replay the
log.  (digs through kernel) Ahh... 'rootflags=...' is what I'm looking for.

--Ricky

Re: xfs partition refuses to mount

[Ricky Beam]

On Sat, 29 May 2004, Vincent van de Camp wrote:
>Thanks for the information. The debug option certainly was not intentional.
>I have tried fsck.xfs, but that didn't do anything but print a version
>message. I haven't tried xfs_repair. I didn't know of it's existance.
>That's definately something to try out next time, though.

fsck.xfs is a nop.  It intentionally doesn't do anything... if you've
reached a point where the filesystem *needs* to be checked and repaired,
you don't want any part of it to be automated.

And most distro's these days will needlessly run fsck everytime it's
been shutdown "improperly" (where "improperly" is defined as a file
didn't get deleted.)

--Ricky

Re: xfs partition refuses to mount

[Tim Shimmin]

Hi Ricky,

On Sat, May 29, 2004 at 03:35:34PM -0400, Ricky Beam wrote:
> (I've had the journal become spooge on a sparc64 box a few times.)
> 
Until May 20 (just over a week ago) recovery on sparc64 (and big endian
64) did not work. A fix went into xfs_bit.c thanks to Nicolas
Boullis. (Our XFS qa tests are routinely run on intel cpus)

--Tim

Re: xfs partition refuses to mount

[Måns Rullgård]

Tim Shimmin <tes@sgi.com> writes:

> Hi Ricky,
>
> On Sat, May 29, 2004 at 03:35:34PM -0400, Ricky Beam wrote:
>> (I've had the journal become spooge on a sparc64 box a few times.)
>> 
> Until May 20 (just over a week ago) recovery on sparc64 (and big endian
> 64) did not work. A fix went into xfs_bit.c thanks to Nicolas
> Boullis. (Our XFS qa tests are routinely run on intel cpus)

What about 64-bit little endian?  I'm using XFS on Alpha, and it seems
to be working.  Is there something I should watch out for?

-- 
Måns Rullgård
mru@kth.se

Re: xfs partition refuses to mount

[Christoph Hellwig]

On Mon, May 31, 2004 at 04:02:31AM +0200, Måns Rullgård wrote:
> > Until May 20 (just over a week ago) recovery on sparc64 (and big endian
> > 64) did not work. A fix went into xfs_bit.c thanks to Nicolas
> > Boullis. (Our XFS qa tests are routinely run on intel cpus)
> 
> What about 64-bit little endian?  I'm using XFS on Alpha, and it seems
> to be working.  Is there something I should watch out for?

64bit Little Endian is fine, it gets regular testing on Altix (IA64),
I'm also testing 32bit Big Endian, so only 64bit BE was the problem.