On Wed, Sep 21, 2016 at 2:41 PM, Simon Becks <beckssimon5@xxxxxxxxx> wrote: > So the old disk i removed 2 month ago reports > > /dev/loop1: SGI XFS filesystem data (blksz 4096, inosz 256, v2 dirs) > > So the filesystem on the raid is/was XFS. gave xfs_repair a shot but > it segfaults: > > i guess thats good, that it found at least the superblock? There's more than one and they're spread across the array. So it's possible you got the first device order correct, so it finds a superblock there, but then when it goes to the next position the drive is out of order so it gets confused. To me this sounds like one drive is in the correct position but the two others are reversed. But I'm not an XFS expert you'd have to ask on their list. > > root@grml ~ # xfs_repair /dev/md42 > 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... > found candidate secondary superblock... > error reading superblock 22 -- seek to offset 2031216754688 failed > unable to verify superblock, continuing... > found candidate secondary superblock... > unable to verify superblock, continuing... > ..found candidate secondary superblock... > verified secondary superblock... > writing modified primary superblock > - reporting progress in intervals of 15 minutes > sb root inode value 18446744073709551615 (NULLFSINO) inconsistent with > calculated value 2048 > resetting superblock root inode pointer to 2048 > sb realtime bitmap inode 18446744073709551615 (NULLFSINO) inconsistent Those big ones strike me as imaginary numbers. > with calculated value 2049 > resetting superblock realtime bitmap ino pointer to 2049 > sb realtime summary inode 18446744073709551615 (NULLFSINO) > inconsistent with calculated value 2050 > resetting superblock realtime summary ino pointer to 2050 > Phase 2 - using internal log > - zero log... > totally zeroed log > - scan filesystem freespace and inode maps... > bad magic number > bad magic number > bad magic number > Metadata corruption detected at block 0x8/0x1000 > bad magic number > Metadata corruption detected at block 0x23d3f408/0x1000 > bad magic numberbad magic number > > Metadata corruption detected at block 0x2afe5808/0x1000 > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > bad magic number > Metadata corruption detected at block 0x10/0x1000 > Metadata corruption detected at block 0xe54c808/0x1000 > bad magic # 0x494e81f6 for agf 0 > bad version # 16908289 for agf 0 > bad sequence # 99 for agf 0 > bad length 99 for agf 0, should be 15027328 > flfirst 1301384768 in agf 0 too large (max = 1024) > bad magic # 0x494e81f6 for agi 0 > bad version # 16908289 for agi 0 > bad sequence # 99 for agi 0 > bad length # 99 for agi 0, should be 15027328 > reset bad agf for ag 0 > reset bad agi for ag 0 > Metadata corruption detected at block 0xd6f7b808/0x1000 > Metadata corruption detected at block 0x2afe5810/0x1000 > bad on-disk superblock 6 - bad magic number > primary/secondary superblock 6 conflict - AG superblock geometry info > conflicts with filesystem geometry > zeroing unused portion of secondary superblock (AG #6) > [1] 23110 segmentation fault xfs_repair /dev/md42 > xfs_repair /dev/md42 > > > > 2016-09-21 21:50 GMT+02:00 Simon Becks <beckssimon5@xxxxxxxxx>: >> Thank you. I already learned a lot. Your command only shows data for >> all of the 3 disks. >> >> Out of curiosity i used strings /dev/loop42 | grep mp3 and many of my >> songs showed up - is that a good sign? >> >> Just tried the 5 orders like a,b,c a,c,b and so on and receive the >> same output about mount: wrong fs type, bad option, bad superblock on >> /dev/md42 and fsck.ext2: Superblock invalid, trying backup blocks.... >> >> Then used photorec in all 5 combinations of disks for several minutes >> without a single file found. >> >> Is it possible that i have to keep something else in mind, while >> assembling the raid? I expected at least some files with photorec when >> the raid was assembled in the right order. >> >> >> 2016-09-21 21:00 GMT+02:00 Andreas Klauer <Andreas.Klauer@xxxxxxxxxxxxxx>: >>> On Wed, Sep 21, 2016 at 08:31:23PM +0200, Simon Becks wrote: >>>> Maybe i just assembled it in the wrong order? >>> >>> Yes, or maybe the superblock was overwritten by XFS after all. >>> >>> You could check what's at offset 1M for each disk. >>> >>> losetup --find --show --read-only --offset=$((2048*512)) /the/disk >>> file -s /dev/loop42 >>> >>> If the superblock was still intact it should say ext4 or whatever >>> your filesystem was for at least one of them. >>> >>> You can also try this for the disk you removed 2 month ago. >>> >>> If that is not the case and fsck with backup superblock also >>> is not successful then you'll have to see if you find anything >>> valid in the raw data. >>> >>> Regards >>> Andreas Klauer > -- > To unsubscribe from this list: send the line "unsubscribe linux-raid" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Chris Murphy -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
