xfs
[Top] [All Lists]

Re: Power loss causes bad magic number??

To: Eric Sandeen <sandeen@xxxxxxxxxxx>
Subject: Re: Power loss causes bad magic number??
From: Kevin Dual <kevin.dual@xxxxxxxxx>
Date: Sun, 8 Feb 2009 00:10:22 -0600
Cc: xfs@xxxxxxxxxxx
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=7Jf91MEA1FjgiX9x/t2gDcbL1vvoXazPL0D+9Oi57DU=; b=UQDO8t1ZL99j4gBxvY0iISkA2jxERvbqrHDeuvOwKdhFFZWuelpcslRuTBGdVJ9Bun py1S764k9plajzWulxp4F22E0e+ucJtH1EGBBzZkDDHuAvtWK79p5/uwT0+dT3YKRbMy IUglrDQQw1CMIq5rjL6eRwznXJDb2SiCetVSM=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=rjbu1offdj7pBlJ79c+dlCwSZbCi7grrmzV3wmycyfgUJalhZweg7gspAcq/zl1r3z Ila34Uf0m2yyj2SnF46l5C4vQuCfkq+bI9xaQpwZrxEgQS53S3+euzVjzAVJ4TKJWEx3 uNQEW8fLjya3uA/1B07E3jaKvjr/v3nO2bUaY=
In-reply-to: <498DF8AD.3020903@xxxxxxxxxxx>
References: <22271900.11234039561556.JavaMail.root@xxxxxxxxxxxxxxxxxx> <498DF8AD.3020903@xxxxxxxxxxx>


On Sat, Feb 7, 2009 at 3:10 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote:
kevin.dual@xxxxxxxxx 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


<Prev in Thread] Current Thread [Next in Thread>