* Power loss causes bad magic number??
@ 2008-07-16 2:18 Stephen Porter
2008-07-16 2:40 ` Eric Sandeen
2009-02-07 20:46 ` kevin.dual
0 siblings, 2 replies; 14+ messages in thread
From: Stephen Porter @ 2008-07-16 2:18 UTC (permalink / raw)
To: xfs
Hello,
Hoping someone may be able to offer some advice/assistance.
I lost power twice (within a few hours) to my machine which had a ~2.2TB
XFS volume on it. The first time the machine (running Xubuntu 8.04)
came back up ok, the second time the XFS volume will not mount. Is
there any chance of recovering the data? /dev/sdc is seen by xubuntu as
one ~2.2TB disk, and I put the XFS file system straight onto the disk.
It's 4x750GB drives on a hardware raid controller (rocketraid 2320).
Driver/module for rocket raid (rr232x) is loaded ok.
In the system log I see:
XFS: bad magic number
XFS: SB validate failed
I tried running xfs_check, the result of this was:
xfs_check /dev/sdc
xfs_check: unexpected XFS SB magic number 0x33c08ed0
xfs_check: size check failed
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
xfs_check: failed to alloc -225176656 bytes: Cannot allocate memory
I looked at running xfs_repair, but the man page states that this will
only work on a volume that has been unmounted cleanly... as I lost power
the volume has not been unmounted cleanly, but I cannot mount it again
to unmount it cleanly.
Running xfs_repair gives the following:
xfs_repair -n /dev/sdc
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
...attempting to find secondary superblock...
...found candidate secondary superblock... unable to verify superblock,
continuing...
(the above appears a few times, until finally)
...Sorry, could not find valid secondary superblock
Exiting now.
I've seen it mentioned in other posts to the xfs archive to check that
there is an xfs volume there, so I've also included the output of "dd
if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x" below:
$ dd if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x
000000 c033 d08e 00bc fb7c 0750 1f50 befc 7c1b
000010 1bbf 5006 b957 01e5 a4f3 bdcb 07be 04b1
000020 6e38 7c00 7509 8313 10c5 f4e2 18cd f58b
000030 c683 4910 1974 2c38 f674 b5a0 b407 8b07
000040 acf0 003c fc74 07bb b400 cd0e eb10 88f2
000050 104e 46e8 7300 fe2a 1046 7e80 0b04 0b74
000060 7e80 0c04 0574 b6a0 7507 80d2 0246 8306
000070 0846 8306 0a56 e800 0021 0573 b6a0 eb07
000080 81bc fe3e 557d 74aa 800b 107e 7400 a0c8
000090 07b7 a9eb fc8b 571e f58b bfcb 0005 568a
0000a0 b400 cd08 7213 8a23 24c1 983f de8a fc8a
0000b0 f743 8be3 86d1 b1d6 d206 42ee e2f7 5639
0000c0 770a 7223 3905 0846 1c73 01b8 bb02 7c00
0000d0 4e8b 8b02 0056 13cd 5173 744f 324e 8ae4
0000e0 0056 13cd e4eb 568a 6000 aabb b455 cd41
0000f0 7213 8136 55fb 75aa f630 01c1 2b74 6061
000100 006a 006a 76ff ff0a 0876 006a 0068 6a7c
000110 6a01 b410 8b42 cdf4 6113 7361 4f0e 0b74
000120 e432 568a cd00 eb13 61d6 c3f9 6e49 6176
000130 696c 2064 6170 7472 7469 6f69 206e 6174
000140 6c62 0065 7245 6f72 2072 6f6c 6461 6e69
000150 2067 706f 7265 7461 6e69 2067 7973 7473
000160 6d65 4d00 7369 6973 676e 6f20 6570 6172
000170 6974 676e 7320 7379 6574 006d 0000 0000
000180 0000 0000 0000 0000 0000 0000 0000 0000
*
0001b0 0000 0000 2c00 6344 089d 089e 0000 0100
0001c0 0001 fefd 3c3f 003f 0000 f3be 000e 0000
0001d0 3d01 fefd ffff f3fd 000e cbe5 0e40 0000
0001e0 0000 0000 0000 0000 0000 0000 0000 0000
0001f0 0000 0000 0000 0000 0000 0000 0000 aa55
000200
Any help greatly appreciated.
Thanks,
Stephen
[[HTML alternate version deleted]]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-16 2:18 Power loss causes bad magic number?? Stephen Porter
@ 2008-07-16 2:40 ` Eric Sandeen
2008-07-16 7:01 ` Stephen Porter
2009-02-07 20:46 ` kevin.dual
1 sibling, 1 reply; 14+ messages in thread
From: Eric Sandeen @ 2008-07-16 2:40 UTC (permalink / raw)
To: Stephen Porter; +Cc: xfs
Stephen Porter wrote:
> Hello,
>
> Hoping someone may be able to offer some advice/assistance.
>
> I lost power twice (within a few hours) to my machine which had a ~2.2TB
> XFS volume on it. The first time the machine (running Xubuntu 8.04)
> came back up ok, the second time the XFS volume will not mount. Is
> there any chance of recovering the data? /dev/sdc is seen by xubuntu as
> one ~2.2TB disk, and I put the XFS file system straight onto the disk.
> It's 4x750GB drives on a hardware raid controller (rocketraid 2320).
> Driver/module for rocket raid (rr232x) is loaded ok.
hm, not an in-kernel driver, I guess?
> In the system log I see:
>
> XFS: bad magic number
>
> XFS: SB validate failed
>
> I tried running xfs_check, the result of this was:
>
> xfs_check /dev/sdc
> xfs_check: unexpected XFS SB magic number 0x33c08ed0
> xfs_check: size check failed
> xfs_check: read failed: Invalid argument
> xfs_check: data size check failed
> xfs_check: failed to alloc -225176656 bytes: Cannot allocate memory
>
> I looked at running xfs_repair, but the man page states that this will
> only work on a volume that has been unmounted cleanly... as I lost power
> the volume has not been unmounted cleanly, but I cannot mount it again
> to unmount it cleanly.
If you have to, you can zero the log w/ xfs_repair as a last resort.
> Running xfs_repair gives the following:
>
> xfs_repair -n /dev/sdc
>
> Phase 1 - find and verify superblock...
>
> bad primary superblock - bad magic number !!!
>
> ...attempting to find secondary superblock...
>
> ...found candidate secondary superblock... unable to verify superblock,
> continuing...
I always wished it said where, and why it did not verify....
> (the above appears a few times, until finally)
>
> ...Sorry, could not find valid secondary superblock
>
> Exiting now.
>
> I've seen it mentioned in other posts to the xfs archive to check that
> there is an xfs volume there, so I've also included the output of "dd
> if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x" below:
>
> $ dd if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x
>
> 000000 c033 d08e 00bc fb7c 0750 1f50 befc 7c1b
> 000010 1bbf 5006 b957 01e5 a4f3 bdcb 07be 04b1
Can you try piping it through "hexdump -C" instead, I'm more used to
eyeballing that output :)
You might also try looking a bit further:
dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
to see if maybe the raid card does something else at the front of your
disk and the superblock is further in, and something got scrambled up?
Just a longshot....
-Eric
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Power loss causes bad magic number??
2008-07-16 2:40 ` Eric Sandeen
@ 2008-07-16 7:01 ` Stephen Porter
2008-07-16 7:35 ` Dave Chinner
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Porter @ 2008-07-16 7:01 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
Hi Eric,
It's not an in-kernel driver, I need to rebuild it each time the kernel is updated.
The output of the dd command follows:
$ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0241381 s, 2.7 MB/s
I thought the XFSB marked the start of the superblock... and it not being there would be a Bad Thing??
without the "| grep XFSB" the output looks like:
$ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C
00000000 33 c0 8e d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c |3.....|.P.P....||
00000010 bf 1b 06 50 57 b9 e5 01 f3 a4 cb bd be 07 b1 04 |...PW...........|
00000020 38 6e 00 7c 09 75 13 83 c5 10 e2 f4 cd 18 8b f5 |8n.|.u..........|
00000030 83 c6 10 49 74 19 38 2c 74 f6 a0 b5 07 b4 07 8b |...It.8,t.......|
00000040 f0 ac 3c 00 74 fc bb 07 00 b4 0e cd 10 eb f2 88 |..<.t...........|
00000050 4e 10 e8 46 00 73 2a fe 46 10 80 7e 04 0b 74 0b |N..F.s*.F..~..t.|
00000060 80 7e 04 0c 74 05 a0 b6 07 75 d2 80 46 02 06 83 |.~..t....u..F...|
00000070 46 08 06 83 56 0a 00 e8 21 00 73 05 a0 b6 07 eb |F...V...!.s.....|
00000080 bc 81 3e fe 7d 55 aa 74 0b 80 7e 10 00 74 c8 a0 |..>.}U.t..~..t..|
00000090 b7 07 eb a9 8b fc 1e 57 8b f5 cb bf 05 00 8a 56 |.......W.......V|
000000a0 00 b4 08 cd 13 72 23 8a c1 24 3f 98 8a de 8a fc |.....r#..$?.....|
000000b0 43 f7 e3 8b d1 86 d6 b1 06 d2 ee 42 f7 e2 39 56 |C..........B..9V|
000000c0 0a 77 23 72 05 39 46 08 73 1c b8 01 02 bb 00 7c |.w#r.9F.s......||
000000d0 8b 4e 02 8b 56 00 cd 13 73 51 4f 74 4e 32 e4 8a |.N..V...sQOtN2..|
000000e0 56 00 cd 13 eb e4 8a 56 00 60 bb aa 55 b4 41 cd |V......V.`..U.A.|
000000f0 13 72 36 81 fb 55 aa 75 30 f6 c1 01 74 2b 61 60 |.r6..U.u0...t+a`|
00000100 6a 00 6a 00 ff 76 0a ff 76 08 6a 00 68 00 7c 6a |j.j..v..v.j.h.|j|
00000110 01 6a 10 b4 42 8b f4 cd 13 61 61 73 0e 4f 74 0b |.j..B....aas.Ot.|
00000120 32 e4 8a 56 00 cd 13 eb d6 61 f9 c3 49 6e 76 61 |2..V.....a..Inva|
00000130 6c 69 64 20 70 61 72 74 69 74 69 6f 6e 20 74 61 |lid partition ta|
00000140 62 6c 65 00 45 72 72 6f 72 20 6c 6f 61 64 69 6e |ble.Error loadin|
00000150 67 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 |g operating syst|
00000160 65 6d 00 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 |em.Missing opera|
00000170 74 69 6e 67 20 73 79 73 74 65 6d 00 00 00 00 00 |ting system.....|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
000001b0 00 00 00 00 00 2c 44 63 9d 08 9e 08 00 00 00 01 |.....,Dc........|
000001c0 01 00 fd fe 3f 3c 3f 00 00 00 be f3 0e 00 00 00 |....?<?.........|
000001d0 01 3d fd fe ff ff fd f3 0e 00 e5 cb 40 0e 00 00 |.=..........@...|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00008200 20 be 03 00 80 79 07 00 ac 5f 00 00 11 b5 06 00 | ....y..._......|
00008210 01 be 03 00 01 00 00 00 00 00 00 00 00 00 00 00 |................|
00008220 00 20 00 00 00 20 00 00 f8 0f 00 00 31 9a 1d 48 |. ... ......1..H|
00008230 d0 9d 1d 48 01 00 1e 00 53 ef 01 00 01 00 00 00 |...H....S.......|
00008240 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 |................|
00008250 00 00 00 00 0b 00 00 00 80 00 00 00 00 00 00 00 |................|
00008260 02 00 00 00 01 00 00 00 d6 ce 40 e9 33 3a 4d 30 |..........@.3:M0|
00008270 8f 62 60 62 04 e9 34 24 62 6f 6f 74 00 00 00 00 |.b`b..4$boot....|
00008280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00008600 04 00 00 00 05 00 00 00 06 00 00 00 00 00 e8 0f |................|
00008610 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008620 04 20 00 00 05 20 00 00 06 20 00 00 d2 10 f8 0f |. ... ... ......|
00008630 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008640 01 40 00 00 02 40 00 00 06 40 00 00 ff 1d f8 0f |.@...@...@......|
00008650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008660 04 60 00 00 05 60 00 00 06 60 00 00 fc 1d f6 0f |.`...`...`......|
00008670 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008680 01 80 00 00 02 80 00 00 06 80 00 00 69 10 f8 0f |............i...|
00008690 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000086a0 04 a0 00 00 05 a0 00 00 06 a0 00 00 4b 0b f8 0f |............K...|
000086b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000086c0 01 c0 00 00 02 c0 00 00 06 c0 00 00 ff 1d f8 0f |................|
000086d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000086e0 04 e0 00 00 05 e0 00 00 06 e0 00 00 fc 1d f8 0f |................|
000086f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008700 01 00 01 00 02 00 01 00 06 00 01 00 ff 1d f8 0f |................|
00008710 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008720 04 20 01 00 05 20 01 00 06 20 01 00 fc 1d f8 0f |. ... ... ......|
00008730 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008740 01 40 01 00 02 40 01 00 06 40 01 00 ff 1d f8 0f |.@...@...@......|
00008750 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008760 01 60 01 00 02 60 01 00 06 60 01 00 ff 1d f8 0f |.`...`...`......|
00008770 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008780 01 80 01 00 02 80 01 00 06 80 01 00 ff 1d f8 0f |................|
00008790 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000087a0 01 a0 01 00 02 a0 01 00 06 a0 01 00 ff 1d f8 0f |................|
000087b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000087c0 01 c0 01 00 02 c0 01 00 06 c0 01 00 ff 1d f8 0f |................|
000087d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000087e0 01 e0 01 00 02 e0 01 00 06 e0 01 00 ff 1d f8 0f |................|
000087f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008800 01 00 02 00 02 00 02 00 06 00 02 00 ff 1d f8 0f |................|
00008810 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008820 01 20 02 00 02 20 02 00 06 20 02 00 ff 1d f8 0f |. ... ... ......|
00008830 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008840 01 40 02 00 02 40 02 00 06 40 02 00 ff 1d f8 0f |.@...@...@......|
00008850 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008860 01 60 02 00 02 60 02 00 06 60 02 00 ff 1d f8 0f |.`...`...`......|
00008870 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008880 01 80 02 00 02 80 02 00 06 80 02 00 ff 1d f8 0f |................|
00008890 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000088a0 01 a0 02 00 02 a0 02 00 06 a0 02 00 ff 1d f8 0f |................|
000088b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000088c0 01 c0 02 00 02 c0 02 00 06 c0 02 00 ff 1d f8 0f |................|
000088d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000088e0 01 e0 02 00 02 e0 02 00 06 e0 02 00 ff 1d f8 0f |................|
000088f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008900 01 00 03 00 02 00 03 00 06 00 03 00 ff 1d f8 0f |................|
00008910 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008920 04 20 03 00 05 20 03 00 06 20 03 00 fc 1d f8 0f |. ... ... ......|
00008930 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008940 01 40 03 00 02 40 03 00 06 40 03 00 55 1d eb 0f |.@...@...@..U...|
00008950 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008960 04 60 03 00 05 60 03 00 06 60 03 00 fc 1d f8 0f |.`...`...`......|
00008970 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008980 01 80 03 00 02 80 03 00 06 80 03 00 ff 1d f8 0f |................|
00008990 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000089a0 01 a0 03 00 02 a0 03 00 06 a0 03 00 ff 1d f8 0f |................|
000089b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000089c0 01 c0 03 00 02 c0 03 00 06 c0 03 00 ff 1d f8 0f |................|
000089d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000089e0 01 e0 03 00 02 e0 03 00 06 e0 03 00 ff 1d f8 0f |................|
000089f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008a00 01 00 04 00 02 00 04 00 06 00 04 00 ff 1d f8 0f |................|
00008a10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008a20 01 20 04 00 02 20 04 00 06 20 04 00 ff 1d f8 0f |. ... ... ......|
00008a30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008a40 01 40 04 00 02 40 04 00 06 40 04 00 ff 1d f8 0f |.@...@...@......|
00008a50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008a60 01 60 04 00 02 60 04 00 06 60 04 00 ff 1d f8 0f |.`...`...`......|
00008a70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008a80 01 80 04 00 02 80 04 00 06 80 04 00 ff 1d f8 0f |................|
00008a90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008aa0 01 a0 04 00 02 a0 04 00 06 a0 04 00 ff 1d f8 0f |................|
00008ab0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008ac0 01 c0 04 00 02 c0 04 00 06 c0 04 00 ff 1d f8 0f |................|
00008ad0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008ae0 01 e0 04 00 02 e0 04 00 06 e0 04 00 ff 1d f8 0f |................|
00008af0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008b00 01 00 05 00 02 00 05 00 06 00 05 00 ff 1d f8 0f |................|
00008b10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008b20 01 20 05 00 02 20 05 00 06 20 05 00 ff 1d f8 0f |. ... ... ......|
00008b30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008b40 01 40 05 00 02 40 05 00 06 40 05 00 ff 1d f8 0f |.@...@...@......|
00008b50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008b60 01 60 05 00 02 60 05 00 06 60 05 00 ff 1d f8 0f |.`...`...`......|
00008b70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008b80 01 80 05 00 02 80 05 00 06 80 05 00 ff 1d f8 0f |................|
00008b90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008ba0 01 a0 05 00 02 a0 05 00 06 a0 05 00 ff 1d f8 0f |................|
00008bb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008bc0 01 c0 05 00 02 c0 05 00 06 c0 05 00 ff 1d f8 0f |................|
00008bd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008be0 01 e0 05 00 02 e0 05 00 06 e0 05 00 ff 1d f8 0f |................|
00008bf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008c00 01 00 06 00 02 00 06 00 06 00 06 00 ff 1d f8 0f |................|
00008c10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008c20 04 20 06 00 05 20 06 00 06 20 06 00 fc 1d f8 0f |. ... ... ......|
00008c30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008c40 01 40 06 00 02 40 06 00 06 40 06 00 ff 1d f8 0f |.@...@...@......|
00008c50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008c60 01 60 06 00 02 60 06 00 06 60 06 00 ff 1d f8 0f |.`...`...`......|
00008c70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008c80 01 80 06 00 02 80 06 00 06 80 06 00 ff 1d f8 0f |................|
00008c90 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008ca0 01 a0 06 00 02 a0 06 00 06 a0 06 00 ff 1d f8 0f |................|
00008cb0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008cc0 01 c0 06 00 02 c0 06 00 06 c0 06 00 ff 1d f8 0f |................|
00008cd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008ce0 01 e0 06 00 02 e0 06 00 06 e0 06 00 ff 1d f8 0f |................|
00008cf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008d00 01 00 07 00 02 00 07 00 06 00 07 00 ff 1d f8 0f |................|
00008d10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008d20 01 20 07 00 02 20 07 00 06 20 07 00 ff 1d f8 0f |. ... ... ......|
00008d30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008d40 01 40 07 00 02 40 07 00 06 40 07 00 ff 1d f8 0f |.@...@...@......|
00008d50 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008d60 01 60 07 00 02 60 07 00 06 60 07 00 7e 17 f8 0f |.`...`...`..~...|
00008d70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00008d80 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff |................|
*
00009200 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00009210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00009680 ed 41 00 00 00 04 00 00 f7 42 04 48 a9 9d 1d 48 |.A.......B.H...H|
00009690 a9 9d 1d 48 00 00 00 00 00 00 04 00 02 00 00 00 |...H............|
000096a0 00 00 00 00 00 00 00 00 05 02 00 00 00 00 00 00 |................|
000096b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00009b00 ed 41 00 00 00 30 00 00 12 9a 1d 48 12 9a 1d 48 |.A...0.....H...H|
00009b10 12 9a 1d 48 00 00 00 00 00 00 02 00 18 00 00 00 |...H............|
00009b20 00 00 00 00 00 00 00 00 06 02 00 00 07 02 00 00 |................|
00009b30 08 02 00 00 09 02 00 00 0a 02 00 00 0b 02 00 00 |................|
00009b40 0c 02 00 00 0d 02 00 00 0e 02 00 00 0f 02 00 00 |................|
00009b50 10 02 00 00 11 02 00 00 00 00 00 00 00 00 00 00 |................|
00009b60 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00009b80 a4 81 00 00 78 0e 1d 00 ab 9a 1d 48 ab 9a 1d 48 |....x......H...H|
00009b90 95 45 fe 47 00 00 00 00 00 00 01 00 9a 0e 00 00 |.E.G............|
00009ba0 00 00 00 00 00 00 00 00 12 02 00 00 13 02 00 00 |................|
00009bb0 14 02 00 00 15 02 00 00 16 02 00 00 17 02 00 00 |................|
00009bc0 18 02 00 00 19 02 00 00 1a 02 00 00 1b 02 00 00 |................|
00009bd0 1c 02 00 00 1d 02 00 00 1e 02 00 00 1f 03 00 00 |................|
00009be0 00 00 00 00 d9 e9 41 20 00 00 00 00 00 00 00 00 |......A ........|
00009bf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00009c00 a4 81 00 00 5c 38 01 00 ab 9a 1d 48 ab 9a 1d 48 |....\8.....H...H|
00009c10 95 45 fe 47 00 00 00 00 00 00 01 00 a0 00 00 00 |.E.G............|
00009c20 00 00 00 00 00 00 00 00 5f 09 00 00 60 09 00 00 |........_...`...|
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0243211 s, 2.7 MB/s
00009c30 61 09 00 00 62 09 00 00 63 09 00 00 64 09 00 00 |a...b...c...d...|
00009c40 65 09 00 00 66 09 00 00 67 09 00 00 68 09 00 00 |e...f...g...h...|
00009c50 69 09 00 00 6a 09 00 00 6b 09 00 00 00 00 00 00 |i...j...k.......|
00009c60 00 00 00 00 da e9 41 20 00 00 00 00 00 00 00 00 |......A ........|
00009c70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00009c80 a4 81 00 00 cf 72 06 00 ab 9a 1d 48 ab 9a 1d 48 |.....r.....H...H|
00009c90 95 45 fe 47 00 00 00 00 00 00 01 00 40 03 00 00 |.E.G........@...|
00009ca0 00 00 00 00 00 00 00 00 af 09 00 00 b0 09 00 00 |................|
00009cb0 b1 09 00 00 b2 09 00 00 b3 09 00 00 b4 09 00 00 |................|
00009cc0 b5 09 00 00 b6 09 00 00 b7 09 00 00 b8 09 00 00 |................|
00009cd0 b9 09 00 00 ba 09 00 00 bb 09 00 00 bc 0a 00 00 |................|
00009ce0 00 00 00 00 db e9 41 20 00 00 00 00 00 00 00 00 |......A ........|
00009cf0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00009d00 a4 81 00 00 34 bb 0d 00 ab 9a 1d 48 ab 9a 1d 48 |....4......H...H|
00009d10 95 45 fe 47 00 00 00 00 00 00 01 00 e8 06 00 00 |.E.G............|
00009d20 00 00 00 00 00 00 00 00 4f 0b 00 00 50 0b 00 00 |........O...P...|
00009d30 51 0b 00 00 52 0b 00 00 53 0b 00 00 54 0b 00 00 |Q...R...S...T...|
00009d40 55 0b 00 00 56 0b 00 00 57 0b 00 00 58 0b 00 00 |U...V...W...X...|
00009d50 59 0b 00 00 5a 0b 00 00 5b 0b 00 00 5c 0c 00 00 |Y...Z...[...\...|
00009d60 00 00 00 00 dc e9 41 20 00 00 00 00 00 00 00 00 |......A ........|
00009d70 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00009d80 a4 81 00 00 6b 1f 79 00 b5 9a 1d 48 c8 9a 1d 48 |....k.y....H...H|
00009d90 be 9a 1d 48 00 00 00 00 00 00 01 00 d0 3c 00 00 |...H.........<..|
00009da0 00 00 00 00 00 00 00 00 c3 0e 00 00 c4 0e 00 00 |................|
00009db0 c5 0e 00 00 c6 0e 00 00 c7 0e 00 00 c8 0e 00 00 |................|
00009dc0 c9 0e 00 00 ca 0e 00 00 cb 0e 00 00 cc 0e 00 00 |................|
00009dd0 cd 0e 00 00 ce 0e 00 00 cf 0e 00 00 d0 0f 00 00 |................|
00009de0 00 00 00 00 dd e9 41 20 00 00 00 00 00 00 00 00 |......A ........|
00009df0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
*
00010000
cypr3ss@server1:~$
This volume isn't now, and has never been (as far as i can remember) a boot volume.
I also did some more googling and found this, which (afaict) is just a replication of the above, but thought it may help.
$ sudo hexdump -C /dev/sdc | head
00000000 33 c0 8e d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c |3.....|.P.P....||
00000010 bf 1b 06 50 57 b9 e5 01 f3 a4 cb bd be 07 b1 04 |...PW...........|
00000020 38 6e 00 7c 09 75 13 83 c5 10 e2 f4 cd 18 8b f5 |8n.|.u..........|
00000030 83 c6 10 49 74 19 38 2c 74 f6 a0 b5 07 b4 07 8b |...It.8,t.......|
00000040 f0 ac 3c 00 74 fc bb 07 00 b4 0e cd 10 eb f2 88 |..<.t...........|
00000050 4e 10 e8 46 00 73 2a fe 46 10 80 7e 04 0b 74 0b |N..F.s*.F..~..t.|
00000060 80 7e 04 0c 74 05 a0 b6 07 75 d2 80 46 02 06 83 |.~..t....u..F...|
00000070 46 08 06 83 56 0a 00 e8 21 00 73 05 a0 b6 07 eb |F...V...!.s.....|
00000080 bc 81 3e fe 7d 55 aa 74 0b 80 7e 10 00 74 c8 a0 |..>.}U.t..~..t..|
00000090 b7 07 eb a9 8b fc 1e 57 8b f5 cb bf 05 00 8a 56 |.......W.......V|
I don't know what this output should look like when it's "correct", but I get the feeling this isn't right.
Regards,
Stephen.
Stephen Porter wrote:
> Hello,
>
> Hoping someone may be able to offer some advice/assistance.
>
> I lost power twice (within a few hours) to my machine which had a ~2.2TB
> XFS volume on it. The first time the machine (running Xubuntu 8.04)
> came back up ok, the second time the XFS volume will not mount. Is
> there any chance of recovering the data? /dev/sdc is seen by xubuntu as
> one ~2.2TB disk, and I put the XFS file system straight onto the disk.
> It's 4x750GB drives on a hardware raid controller (rocketraid 2320).
> Driver/module for rocket raid (rr232x) is loaded ok.
hm, not an in-kernel driver, I guess?
> In the system log I see:
>
> XFS: bad magic number
>
> XFS: SB validate failed
>
> I tried running xfs_check, the result of this was:
>
> xfs_check /dev/sdc
> xfs_check: unexpected XFS SB magic number 0x33c08ed0
> xfs_check: size check failed
> xfs_check: read failed: Invalid argument
> xfs_check: data size check failed
> xfs_check: failed to alloc -225176656 bytes: Cannot allocate memory
>
> I looked at running xfs_repair, but the man page states that this will
> only work on a volume that has been unmounted cleanly... as I lost power
> the volume has not been unmounted cleanly, but I cannot mount it again
> to unmount it cleanly.
If you have to, you can zero the log w/ xfs_repair as a last resort.
> Running xfs_repair gives the following:
>
> xfs_repair -n /dev/sdc
>
> Phase 1 - find and verify superblock...
>
> bad primary superblock - bad magic number !!!
>
> ...attempting to find secondary superblock...
>
> ...found candidate secondary superblock... unable to verify superblock,
> continuing...
I always wished it said where, and why it did not verify....
> (the above appears a few times, until finally)
>
> ...Sorry, could not find valid secondary superblock
>
> Exiting now.
>
> I've seen it mentioned in other posts to the xfs archive to check that
> there is an xfs volume there, so I've also included the output of "dd
> if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x" below:
>
> $ dd if=/dev/sdc bs=512 count=1 iflag=direct 2> /dev/null | od -Ax -x
>
> 000000 c033 d08e 00bc fb7c 0750 1f50 befc 7c1b
> 000010 1bbf 5006 b957 01e5 a4f3 bdcb 07be 04b1
Can you try piping it through "hexdump -C" instead, I'm more used to
eyeballing that output :)
You might also try looking a bit further:
dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
to see if maybe the raid card does something else at the front of your
disk and the superblock is further in, and something got scrambled up?
Just a longshot....
-Eric
[[HTML alternate version deleted]]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-16 7:01 ` Stephen Porter
@ 2008-07-16 7:35 ` Dave Chinner
2008-07-16 8:17 ` Stephen Porter
0 siblings, 1 reply; 14+ messages in thread
From: Dave Chinner @ 2008-07-16 7:35 UTC (permalink / raw)
To: Stephen Porter; +Cc: Eric Sandeen, xfs
On Wed, Jul 16, 2008 at 05:01:56PM +1000, Stephen Porter wrote:
> Hi Eric,
>
> It's not an in-kernel driver, I need to rebuild it each time the kernel is updated.
>
> The output of the dd command follows:
>
> $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0241381 s, 2.7 MB/s
>
> I thought the XFSB marked the start of the superblock... and it not being there would be a Bad Thing??
>
> without the "| grep XFSB" the output looks like:
>
> $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C
> 00000000 33 c0 8e d0 bc 00 7c fb 50 07 50 1f fc be 1b 7c |3.....|.P.P....||
> 00000010 bf 1b 06 50 57 b9 e5 01 f3 a4 cb bd be 07 b1 04 |...PW...........|
> 00000020 38 6e 00 7c 09 75 13 83 c5 10 e2 f4 cd 18 8b f5 |8n.|.u..........|
> 00000030 83 c6 10 49 74 19 38 2c 74 f6 a0 b5 07 b4 07 8b |...It.8,t.......|
> 00000040 f0 ac 3c 00 74 fc bb 07 00 b4 0e cd 10 eb f2 88 |..<.t...........|
> 00000050 4e 10 e8 46 00 73 2a fe 46 10 80 7e 04 0b 74 0b |N..F.s*.F..~..t.|
> 00000060 80 7e 04 0c 74 05 a0 b6 07 75 d2 80 46 02 06 83 |.~..t....u..F...|
> 00000070 46 08 06 83 56 0a 00 e8 21 00 73 05 a0 b6 07 eb |F...V...!.s.....|
> 00000080 bc 81 3e fe 7d 55 aa 74 0b 80 7e 10 00 74 c8 a0 |..>.}U.t..~..t..|
> 00000090 b7 07 eb a9 8b fc 1e 57 8b f5 cb bf 05 00 8a 56 |.......W.......V|
> 000000a0 00 b4 08 cd 13 72 23 8a c1 24 3f 98 8a de 8a fc |.....r#..$?.....|
> 000000b0 43 f7 e3 8b d1 86 d6 b1 06 d2 ee 42 f7 e2 39 56 |C..........B..9V|
> 000000c0 0a 77 23 72 05 39 46 08 73 1c b8 01 02 bb 00 7c |.w#r.9F.s......||
> 000000d0 8b 4e 02 8b 56 00 cd 13 73 51 4f 74 4e 32 e4 8a |.N..V...sQOtN2..|
> 000000e0 56 00 cd 13 eb e4 8a 56 00 60 bb aa 55 b4 41 cd |V......V.`..U.A.|
> 000000f0 13 72 36 81 fb 55 aa 75 30 f6 c1 01 74 2b 61 60 |.r6..U.u0...t+a`|
> 00000100 6a 00 6a 00 ff 76 0a ff 76 08 6a 00 68 00 7c 6a |j.j..v..v.j.h.|j|
> 00000110 01 6a 10 b4 42 8b f4 cd 13 61 61 73 0e 4f 74 0b |.j..B....aas.Ot.|
> 00000120 32 e4 8a 56 00 cd 13 eb d6 61 f9 c3 49 6e 76 61 |2..V.....a..Inva|
> 00000130 6c 69 64 20 70 61 72 74 69 74 69 6f 6e 20 74 61 |lid partition ta|
> 00000140 62 6c 65 00 45 72 72 6f 72 20 6c 6f 61 64 69 6e |ble.Error loadin|
> 00000150 67 20 6f 70 65 72 61 74 69 6e 67 20 73 79 73 74 |g operating syst|
> 00000160 65 6d 00 4d 69 73 73 69 6e 67 20 6f 70 65 72 61 |em.Missing opera|
> 00000170 74 69 6e 67 20 73 79 73 74 65 6d 00 00 00 00 00 |ting system.....|
> 00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
That looks like a boot loader.
> *
> 000001b0 00 00 00 00 00 2c 44 63 9d 08 9e 08 00 00 00 01 |.....,Dc........|
> 000001c0 01 00 fd fe 3f 3c 3f 00 00 00 be f3 0e 00 00 00 |....?<?.........|
> 000001d0 01 3d fd fe ff ff fd f3 0e 00 e5 cb 40 0e 00 00 |.=..........@...|
> 000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
> 000001f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa |..............U.|
> 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
And at 0x200 I'd expect to see an AGF header, not zeros. To
me, that says that either XFS is inside a partition on the drive
or someone ran a partitioning tool on /dev/sdc and overwrote the
XFS filesystem headers...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Power loss causes bad magic number??
2008-07-16 7:35 ` Dave Chinner
@ 2008-07-16 8:17 ` Stephen Porter
2008-07-16 16:00 ` Chris Wedgwood
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Stephen Porter @ 2008-07-16 8:17 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs, sandeen
-----Original Message-----
From: Dave Chinner [mailto:david@fromorbit.com]
> That looks like a boot loader.
That's what I thought, but again, this isn't a boot volume, could running xfs_repair without the -n have done this?
> And at 0x200 I'd expect to see an AGF header, not zeros. To
> me, that says that either XFS is inside a partition on the drive
> or someone ran a partitioning tool on /dev/sdc and overwrote the
> XFS filesystem headers...
relevant line from /etc/fstab:
/dev/sdc /home/username/Data xfs defaults 0 2
the raid management tool is reporting everythings ok... any idea what could have caused this?
....
Ok, my apologies, I've just done an ls of /dev/sd* and the devices have been remapped (any idea what would have caused that?), sdc is no longer sdc, it is now sda, the boot devices are now detected as sdb and sdc (2 mirrored physical disks, used to be sda and sdb). How was the machine able to boot? I'm more confused than ever now, but the data is all there.
Sorry for wasting everyones time.
Regards,
Stephen.
[[HTML alternate version deleted]]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-16 8:17 ` Stephen Porter
@ 2008-07-16 16:00 ` Chris Wedgwood
2008-07-17 13:36 ` Russell Cattelan
2008-07-18 18:19 ` Peter Grandi
2 siblings, 0 replies; 14+ messages in thread
From: Chris Wedgwood @ 2008-07-16 16:00 UTC (permalink / raw)
To: Stephen Porter; +Cc: Dave Chinner, xfs, sandeen
On Wed, Jul 16, 2008 at 06:17:37PM +1000, Stephen Porter wrote:
> Ok, my apologies, I've just done an ls of /dev/sd* and the devices
> have been remapped (any idea what would have caused that?), sdc is
> no longer sdc, it is now sda, the boot devices are now detected as
> sdb and sdc (2 mirrored physical disks, used to be sda and sdb).
> How was the machine able to boot? I'm more confused than ever now,
> but the data is all there.
There are quite a few things that can cause devices to get 'remapped'
from the kernels point of view between reboots. It's actually a lot
better now than it used to be.
For mount-points you need to think about labels or UUIDs if this
becomes a problem. For booting (I've also had this happen, the boot
volume which is bios device 0x80 moved from /dev/sda to /dev/sdc) so
you need to be sure the boot-loader DTRT and also the kernel is able
to find the root file-system on boot (I think most distributions use
initrd's which can mount my label).
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-16 8:17 ` Stephen Porter
2008-07-16 16:00 ` Chris Wedgwood
@ 2008-07-17 13:36 ` Russell Cattelan
2008-07-17 21:52 ` Stephen Porter
2008-07-18 18:19 ` Peter Grandi
2 siblings, 1 reply; 14+ messages in thread
From: Russell Cattelan @ 2008-07-17 13:36 UTC (permalink / raw)
To: Stephen Porter; +Cc: xfs
Stephen Porter wrote:
>
> -----Original Message-----
> From: Dave Chinner [mailto:david@fromorbit.com]
>
>
>> That looks like a boot loader.
>>
>
> That's what I thought, but again, this isn't a boot volume, could running xfs_repair without the -n have done this?
>
>
>> And at 0x200 I'd expect to see an AGF header, not zeros. To
>> me, that says that either XFS is inside a partition on the drive
>> or someone ran a partitioning tool on /dev/sdc and overwrote the
>> XFS filesystem headers...
>>
>
> relevant line from /etc/fstab:
>
> /dev/sdc /home/username/Data xfs defaults 0 2
>
> the raid management tool is reporting everythings ok... any idea what could have caused this?
>
> ....
>
> Ok, my apologies, I've just done an ls of /dev/sd* and the devices have been remapped (any idea what would have caused that?), sdc is no longer sdc, it is now sda, the boot devices are now detected as sdb and sdc (2 mirrored physical disks, used to be sda and sdb). How was the machine able to boot? I'm more confused than ever now, but the data is all there.
>
Heh welcome to the world of linux's poor device name handling.
Did you make some sort of change to the hardware? added drives, moved
cards around, etc?
Anything that changes the order that drives are discovered will affect
the sd[a-...] naming.
Mount by label or mount by uuid may be your friend in this case.
> Sorry for wasting everyones time.
>
> Regards,
>
> Stephen.
>
>
>
>
> [[HTML alternate version deleted]]
>
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Power loss causes bad magic number??
2008-07-17 13:36 ` Russell Cattelan
@ 2008-07-17 21:52 ` Stephen Porter
2008-07-18 11:17 ` Andi Kleen
0 siblings, 1 reply; 14+ messages in thread
From: Stephen Porter @ 2008-07-17 21:52 UTC (permalink / raw)
To: Russell Cattelan; +Cc: xfs
-----Original Message-----
From: Russell Cattelan [mailto:cattelan@thebarn.com]
Sent: Thursday, 17 July 2008 11:36 PM
To: Stephen Porter
Cc: xfs@oss.sgi.com
Subject: Re: Power loss causes bad magic number??
> Heh welcome to the world of linux's poor device name handling.
Hehe, gee thanks! :)
> Did you make some sort of change to the hardware? added drives, moved
> cards around, etc?
> Anything that changes the order that drives are discovered will affect
> the sd[a-...] naming.
No changes were made to the hardware, though as I mentioned originally I
did loose power twice within a few hours, and it was the 2nd time the
issue appeared.
Having said that, after "fixing" the issue (updating the fstab entry) I
have since installed a few updates, and it broke again (remapped back to
sdc). :/
> Mount by label or mount by uuid may be your friend in this case.
I think this is going to be my only option (unless I want to keep
updating fstab entries each time _something_ updates on the box). Time
to visit google again. I realise this is now way off topic, but is
there a "preferred method" with regards to mounting by labels or uuid?
Thanks.
Stephen.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-17 21:52 ` Stephen Porter
@ 2008-07-18 11:17 ` Andi Kleen
0 siblings, 0 replies; 14+ messages in thread
From: Andi Kleen @ 2008-07-18 11:17 UTC (permalink / raw)
To: Stephen Porter; +Cc: Russell Cattelan, xfs
"Stephen Porter" <stephenp@r-s.com.au> writes:
>
> I think this is going to be my only option (unless I want to keep
> updating fstab entries each time _something_ updates on the box). Time
> to visit google again. I realise this is now way off topic, but is
> there a "preferred method" with regards to mounting by labels or uuid?
Modern distributions generall give you several other options using udev.
e.g. common is using /dev/disk/by-path/ (which should be stable)
Drawback is that this always requires a initrd for mounting /
-Andi
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: Power loss causes bad magic number??
2008-07-16 8:17 ` Stephen Porter
2008-07-16 16:00 ` Chris Wedgwood
2008-07-17 13:36 ` Russell Cattelan
@ 2008-07-18 18:19 ` Peter Grandi
2 siblings, 0 replies; 14+ messages in thread
From: Peter Grandi @ 2008-07-18 18:19 UTC (permalink / raw)
To: Linux XFS
[ ... ]
> [ ... ] ls of /dev/sd* and the devices have been remapped (any
> idea what would have caused that?), sdc is no longer sdc, it
> is now sda, the boot devices are now detected as sdb and sdc
> (2 mirrored physical disks, used to be sda and sdb).
A BIOS or OS upgrade or just about anything might change the
names of any device because there isn't any well defined
enumeration order for devices.
Therefore the only safe option is the same as used by XFS or MD:
to give a unique name/token, but to all storage volumes.
The most useful scheme would be to give unique names to container
volumes like hard drives and then position based letters/numbers
for partitions (because for partitions the ordering is well
defined), but no current GNU/Linux distro supports that.
Probably you should then investigate the 'LABEL=' and 'UUID='
options of '/etc/fstab'.
> How was the machine able to boot? [ ... ]
Depends a bit on which booter you have installed; for example
LILO nowadays uses MS-DOS volume IDs to identify hard drives.
GRUB does not, and therefore I have stopped using it, as the
frequent drive reordering that I suffer has made it almost
unusable.
Also, the BIOS (used for booting) and Linux can and will number
drives in a different order, so the BIOS boot drive may well be
not '/dev/sda' or '/dev/hda'.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2008-07-16 2:18 Power loss causes bad magic number?? Stephen Porter
2008-07-16 2:40 ` Eric Sandeen
@ 2009-02-07 20:46 ` kevin.dual
2009-02-07 21:10 ` Eric Sandeen
1 sibling, 1 reply; 14+ messages in thread
From: kevin.dual @ 2009-02-07 20:46 UTC (permalink / raw)
To: xfs
I'm having a very similar problem... My 1TB RAID-5 array formatted with XFS assembles, but refuses to mount:
--------------------------------------------------
$ dmesg
...
[19827.704838] XFS: bad magic number
[19827.704847] XFS: SB validate failed
--------------------------------------------------
$ cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
--------------------------------------------------
$ sudo parted -l
Model: ATA ST3500641AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 480GB 480GB primary ext3 boot
2 480GB 500GB 20.3GB extended
5 480GB 500GB 20.3GB logical linux-swap
Model: ATA ST3500641AS (scsi)
Disk /dev/sdb: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 500GB 500GB primary raid
Model: ATA ST3500641AS (scsi)
Disk /dev/sdc: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 500GB 500GB primary raid
Model: ATA ST3500641AS (scsi)
Disk /dev/sdd: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Number Start End Size Type File system Flags
1 32.3kB 500GB 500GB primary raid
Error: /dev/md0: unrecognised disk label
--------------------------------------------------
$ sudo xfs_check /dev/md0
xfs_check: unexpected XFS SB magic number 0x110812af
cache_node_purge: refcount was 1, not zero (node=0x1300220)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x1300440)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault
$ sudo xfs_check /dev/sdb1
xfs_check: unexpected XFS SB magic number 0x110812af
cache_node_purge: refcount was 1, not zero (node=0x2213220)
xfs_check: cannot read root inode (22)
bad superblock magic number 110812af, giving up
$ sudo xfs_check /dev/sdc1
cache_node_purge: refcount was 1, not zero (node=0x2377220)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x2377440)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault
$ sudo xfs_check /dev/sdd1
xfs_check: unexpected XFS SB magic number 0x494e41ed
xfs_check: size check failed
xfs_check: read failed: Invalid argument
xfs_check: data size check failed
cache_node_purge: refcount was 1, not zero (node=0x24f1c20)
xfs_check: cannot read root inode (22)
cache_node_purge: refcount was 1, not zero (node=0x24f1d70)
xfs_check: cannot read realtime bitmap inode (22)
Segmentation fault
--------------------------------------------------
$ sudo xfs_repair -n /dev/md0
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
...etc...etc...fail fail fail
$ sudo xfs_repair -n /dev/sdb1
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!
attempting to find secondary superblock...
...etc...etc...fail fail fail
$ sudo xfs_repair -n /dev/sdc1
Phase 1 - find and verify superblock...
error reading superblock 17 -- seek to offset 531361234944 failed
couldn't verify primary superblock - bad magic number !!!
attempting to find secondary superblock...
...found candidate secondary superblock...
error reading superblock 17 -- seek to offset 531361234944 failed
unable to verify superblock, continuing...
...etc...etc...fail fail fail
you know the routine...
--------------------------------------------------
$ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s
$ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s
$ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00 |XFSB............|
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s
$ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
128+0 records in
128+0 records out
65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s
Looks like /dev/sdc is the only one with any recognizable superblock data on it.
--------------------------------------------------
Now what should I do with all this information? The array assembles fine, but the XFS volume seems to be screwed up somehow. Is there any way the array could have put itself together wrong then re-synced and corrupted all my data?
--
This message was sent on behalf of kevin.dual@gmail.com at openSubscriber.com
http://www.opensubscriber.com/message/xfs@oss.sgi.com/9638260.html
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2009-02-07 20:46 ` kevin.dual
@ 2009-02-07 21:10 ` Eric Sandeen
2009-02-07 21:54 ` Eric Sandeen
2009-02-08 6:10 ` Kevin Dual
0 siblings, 2 replies; 14+ messages in thread
From: Eric Sandeen @ 2009-02-07 21:10 UTC (permalink / raw)
To: kevin.dual; +Cc: xfs
kevin.dual@gmail.com wrote:
> I'm having a very similar problem... My 1TB RAID-5 array formatted with XFS assembles, but refuses to mount:
...
> $ cat /proc/mdstat
> Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
> md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
> 976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
>
> unused devices: <none>
...
> --------------------------------------------------
> $ sudo xfs_check /dev/md0
> xfs_check: unexpected XFS SB magic number 0x110812af
> cache_node_purge: refcount was 1, not zero (node=0x1300220)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=0x1300440)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault
hm, ok...
but below you don't expect each component drive to be a consistent xfs
fs do you? It's not a mirror :)
> $ sudo xfs_check /dev/sdb1
> xfs_check: unexpected XFS SB magic number 0x110812af
> cache_node_purge: refcount was 1, not zero (node=0x2213220)
> xfs_check: cannot read root inode (22)
> bad superblock magic number 110812af, giving up
>
> $ sudo xfs_check /dev/sdc1
> cache_node_purge: refcount was 1, not zero (node=0x2377220)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=0x2377440)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault
>
> $ sudo xfs_check /dev/sdd1
> xfs_check: unexpected XFS SB magic number 0x494e41ed
> xfs_check: size check failed
> xfs_check: read failed: Invalid argument
> xfs_check: data size check failed
> cache_node_purge: refcount was 1, not zero (node=0x24f1c20)
> xfs_check: cannot read root inode (22)
> cache_node_purge: refcount was 1, not zero (node=0x24f1d70)
> xfs_check: cannot read realtime bitmap inode (22)
> Segmentation fault
>
none of the above surprises me
> --------------------------------------------------
> $ sudo xfs_repair -n /dev/md0
> Phase 1 - find and verify superblock...
> bad primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...etc...etc...fail fail fail
Ok so above is the real problem.
again below is not expected to work!
> $ sudo xfs_repair -n /dev/sdb1
> Phase 1 - find and verify superblock...
> bad primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...etc...etc...fail fail fail
>
> $ sudo xfs_repair -n /dev/sdc1
> Phase 1 - find and verify superblock...
> error reading superblock 17 -- seek to offset 531361234944 failed
> couldn't verify primary superblock - bad magic number !!!
>
> attempting to find secondary superblock...
> ...found candidate secondary superblock...
> error reading superblock 17 -- seek to offset 531361234944 failed
> unable to verify superblock, continuing...
> ...etc...etc...fail fail fail
>
> you know the routine...
>
>
> --------------------------------------------------
> $ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s
>
> $ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s
>
> $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
> 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00 |XFSB............|
ibase=16
7E00
32256, or 63x512
and sdc was:
> Model: ATA ST3500641AS (scsi)
> Disk /dev/sdc: 500GB
> Sector size (logical/physical): 512B/512B
> Partition Table: msdos
>
> Number Start End Size Type File system Flags
> 1 32.3kB 500GB 500GB primary raid
IOW the normal msdos 63 sectors.
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s
>
> $ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep XFSB
> 128+0 records in
> 128+0 records out
> 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s
>
> Looks like /dev/sdc is the only one with any recognizable superblock data on it.
> --------------------------------------------------
>
> Now what should I do with all this information? The array assembles fine, but the XFS volume seems to be screwed up somehow. Is there any way the array could have put itself together wrong then re-synced and corrupted all my data?
It seems like maybe it assembled out of order, as if sdc1 should be the
first drive, since it has the magic at the right place.
Dunno how much damage could have been done, or if you can just try to
fix the assembly perhaps...?
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2009-02-07 21:10 ` Eric Sandeen
@ 2009-02-07 21:54 ` Eric Sandeen
2009-02-08 6:10 ` Kevin Dual
1 sibling, 0 replies; 14+ messages in thread
From: Eric Sandeen @ 2009-02-07 21:54 UTC (permalink / raw)
To: kevin.dual; +Cc: xfs
Eric Sandeen wrote:
> Dunno how much damage could have been done, or if you can just try to
> fix the assembly perhaps...?
>
> -Eric
FWIW on a 3-disk raid5:
[root@inode tmp]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid5 loop3[2] loop2[1] loop1[0]
262016 blocks level 5, 4k chunk, algorithm 2 [3/3] [UUU]
unused devices: <none>
it's the 0th device which should have the superblock:
[root@inode tmp]# file -s /dev/loop[123]
/dev/loop1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs)
/dev/loop2: data
/dev/loop3: data
whereas yours was the 1st (not 0th)
(I wasn't sure how mdstat showed the order so double checked...)
-Eric
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Power loss causes bad magic number??
2009-02-07 21:10 ` Eric Sandeen
2009-02-07 21:54 ` Eric Sandeen
@ 2009-02-08 6:10 ` Kevin Dual
1 sibling, 0 replies; 14+ messages in thread
From: Kevin Dual @ 2009-02-08 6:10 UTC (permalink / raw)
To: Eric Sandeen; +Cc: xfs
[-- Attachment #1.1: Type: text/plain, Size: 6133 bytes --]
On Sat, Feb 7, 2009 at 3:10 PM, Eric Sandeen <sandeen@sandeen.net> wrote:
> kevin.dual@gmail.com wrote:
> > I'm having a very similar problem... My 1TB RAID-5 array formatted with
> XFS assembles, but refuses to mount:
>
> ...
>
> > $ cat /proc/mdstat
> > Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5]
> [raid4] [raid10]
> > md0 : active raid5 sdd1[2] sdc1[1] sdb1[0]
> > 976767872 blocks level 5, 64k chunk, algorithm 2 [3/3] [UUU]
> >
> > unused devices: <none>
>
> ...
>
>
> > --------------------------------------------------
> > $ sudo xfs_check /dev/md0
> > xfs_check: unexpected XFS SB magic number 0x110812af
> > cache_node_purge: refcount was 1, not zero (node=0x1300220)
> > xfs_check: cannot read root inode (22)
> > cache_node_purge: refcount was 1, not zero (node=0x1300440)
> > xfs_check: cannot read realtime bitmap inode (22)
> > Segmentation fault
>
> hm, ok...
>
> but below you don't expect each component drive to be a consistent xfs
> fs do you? It's not a mirror :)
Actually, I did not expect each component drive to be a consistent xfs file
system, I was just trying to gather as much information as possible. I'm
glad I did because it was running "sudo dd if=/dev/sd* bs=512 count=128
iflag=direct | hexdump -C | grep XFSB" on all my drives that showed which
drive had the xfs info on it and allowed you to suggest that I try creating
the array with that drive first:
$ sudo mdadm --create /dev/md0 --level=5 --raid-devices=3 --assume-clean
/dev/sdc1 /dev/sdd1 /dev/sdb1
mdadm: /dev/sdc1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009
mdadm: /dev/sdd1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009
mdadm: /dev/sdb1 appears to be part of a raid array:
level=raid5 devices=3 ctime=Fri Feb 6 18:01:59 2009
Continue creating array? y
mdadm: array /dev/md0 started.
$ sudo mount -t xfs /dev/md0 test
$ cd test
/test$ ls
ALL MY DATA!
So it seems that creating a RAID-5 array in the wrong order and allowing it
to sync does not destroy the data, which is very to know ;P
Thank you very much for your help!
>
> > $ sudo xfs_check /dev/sdb1
> > xfs_check: unexpected XFS SB magic number 0x110812af
> > cache_node_purge: refcount was 1, not zero (node=0x2213220)
> > xfs_check: cannot read root inode (22)
> > bad superblock magic number 110812af, giving up
> >
> > $ sudo xfs_check /dev/sdc1
> > cache_node_purge: refcount was 1, not zero (node=0x2377220)
> > xfs_check: cannot read root inode (22)
> > cache_node_purge: refcount was 1, not zero (node=0x2377440)
> > xfs_check: cannot read realtime bitmap inode (22)
> > Segmentation fault
> >
> > $ sudo xfs_check /dev/sdd1
> > xfs_check: unexpected XFS SB magic number 0x494e41ed
> > xfs_check: size check failed
> > xfs_check: read failed: Invalid argument
> > xfs_check: data size check failed
> > cache_node_purge: refcount was 1, not zero (node=0x24f1c20)
> > xfs_check: cannot read root inode (22)
> > cache_node_purge: refcount was 1, not zero (node=0x24f1d70)
> > xfs_check: cannot read realtime bitmap inode (22)
> > Segmentation fault
> >
>
> none of the above surprises me
>
> > --------------------------------------------------
> > $ sudo xfs_repair -n /dev/md0
> > Phase 1 - find and verify superblock...
> > bad primary superblock - bad magic number !!!
> >
> > attempting to find secondary superblock...
> > ...etc...etc...fail fail fail
>
> Ok so above is the real problem.
>
> again below is not expected to work!
>
> > $ sudo xfs_repair -n /dev/sdb1
> > Phase 1 - find and verify superblock...
> > bad primary superblock - bad magic number !!!
> >
> > attempting to find secondary superblock...
> > ...etc...etc...fail fail fail
> >
> > $ sudo xfs_repair -n /dev/sdc1
> > Phase 1 - find and verify superblock...
> > error reading superblock 17 -- seek to offset 531361234944 failed
> > couldn't verify primary superblock - bad magic number !!!
> >
> > attempting to find secondary superblock...
> > ...found candidate secondary superblock...
> > error reading superblock 17 -- seek to offset 531361234944 failed
> > unable to verify superblock, continuing...
> > ...etc...etc...fail fail fail
> >
> > you know the routine...
> >
> >
> > --------------------------------------------------
> > $ sudo dd if=/dev/md0 bs=512 count=128 iflag=direct | hexdump -C | grep
> XFSB
> > 128+0 records in
> > 128+0 records out
> > 65536 bytes (66 kB) copied, 0.0257556 s, 2.5 MB/s
> >
> > $ sudo dd if=/dev/sdb bs=512 count=128 iflag=direct | hexdump -C | grep
> XFSB
> > 128+0 records in
> > 128+0 records out
> > 65536 bytes (66 kB) copied, 0.0352348 s, 1.9 MB/s
> >
> > $ sudo dd if=/dev/sdc bs=512 count=128 iflag=direct | hexdump -C | grep
> XFSB
> > 00007e00 58 46 53 42 00 00 10 00 00 00 00 00 0e 8e 12 00
> |XFSB............|
>
> ibase=16
> 7E00
> 32256, or 63x512
>
> and sdc was:
>
> > Model: ATA ST3500641AS (scsi)
> > Disk /dev/sdc: 500GB
> > Sector size (logical/physical): 512B/512B
> > Partition Table: msdos
> >
> > Number Start End Size Type File system Flags
> > 1 32.3kB 500GB 500GB primary raid
>
> IOW the normal msdos 63 sectors.
>
> > 128+0 records in
> > 128+0 records out
> > 65536 bytes (66 kB) copied, 0.0386271 s, 1.7 MB/s
> >
> > $ sudo dd if=/dev/sdd bs=512 count=128 iflag=direct | hexdump -C | grep
> XFSB
> > 128+0 records in
> > 128+0 records out
> > 65536 bytes (66 kB) copied, 0.0928554 s, 706 kB/s
> >
> > Looks like /dev/sdc is the only one with any recognizable superblock data
> on it.
> > --------------------------------------------------
> >
> > Now what should I do with all this information? The array assembles
> fine, but the XFS volume seems to be screwed up somehow. Is there any way
> the array could have put itself together wrong then re-synced and corrupted
> all my data?
>
> It seems like maybe it assembled out of order, as if sdc1 should be the
> first drive, since it has the magic at the right place.
>
> Dunno how much damage could have been done, or if you can just try to
> fix the assembly perhaps...?
>
> -Eric
>
>
[-- Attachment #1.2: Type: text/html, Size: 7677 bytes --]
[-- Attachment #2: Type: text/plain, Size: 121 bytes --]
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-02-08 6:11 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-07-16 2:18 Power loss causes bad magic number?? Stephen Porter
2008-07-16 2:40 ` Eric Sandeen
2008-07-16 7:01 ` Stephen Porter
2008-07-16 7:35 ` Dave Chinner
2008-07-16 8:17 ` Stephen Porter
2008-07-16 16:00 ` Chris Wedgwood
2008-07-17 13:36 ` Russell Cattelan
2008-07-17 21:52 ` Stephen Porter
2008-07-18 11:17 ` Andi Kleen
2008-07-18 18:19 ` Peter Grandi
2009-02-07 20:46 ` kevin.dual
2009-02-07 21:10 ` Eric Sandeen
2009-02-07 21:54 ` Eric Sandeen
2009-02-08 6:10 ` Kevin Dual
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox