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
|