On Oct 12, 2017, at 4:02 PM, Kilian Cavalotti <kilian.cavalotti.work@xxxxxxxxx> wrote: > > On Wed, Oct 11, 2017 at 7:36 AM, Kilian Cavalotti > <kilian.cavalotti.work@xxxxxxxxx> wrote: >> On Tue, Oct 10, 2017 at 1:36 PM, Andreas Dilger <adilger@xxxxxxxxx> wrote: >>> If the problem is only one of the partition being misaligned compared >>> to the logical volume, you can run the "findsuper" utility which is >>> part of e2fsprogs *sources* (it isn't built and packaged by default). >>> It will scan your block device and print out the ext2/3/4 superblocks >>> that it finds, along with the *byte* offset of each one found. You >>> can use this to determine where the start of the filesystem should be. >> >> I will give this a try, thanks. Although I don't really had any issue >> to mount the filesystem r/o, which seems to indicate that there is no >> misalignment issue, right? > > So... I tried findsuper, and it started listing things (including, for > some, non-printable characters in the "label" field, but I guess it's > just false-positives). The findsuper comment was potentially misleading, as I was mixing up your problem with one in another thread where the partition table was clobbered. > It's still running right now, but it already listed superblocks which > are obviously not related to the actual filesystem, but to raw disk > images (created via dd) that I had on that filesystem. For instance: > > -- 8< --------------------------------------------------------- > # /usr/local/sbin/findsuper /dev/mapper/overlay > starting at 0, with 512 byte increments > byte_offset byte_start byte_end fs_blocks blksz grp > mkfs/mount_time sb_uuid label > 1024 0 17983724322816 95590400 4096 0 Thu Nov > 26 23:22:42 2015 12c2c019 1.42.6-5644 This is likely to be the proper superblock, but it has a bit of a strange label. Looks like a really old e2fsprogs build version? > 2556972232704 2556972231680 2560139979776 773376 4096 0 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > 2557257444352 2557123226624 2560290974720 773376 4096 1 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > 2557962087424 2557559434240 2560727182336 773376 4096 3 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > 2558532512768 2557861424128 2561029172224 773376 4096 5 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > 2559086160896 2558146636800 2561314384896 773376 4096 7 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > 2559656586240 2558448626688 2561616374784 773376 4096 9 Tue > Jan 29 20:40:53 2013 da57c5f6 casper-rw > -- 8< --------------------------------------------------------- > > That makes me think I should be able to recover those dd images with > the correct offsets, right? So for instance, looking at the > "casper-rw" label, I tried this: > > -- 8< --------------------------------------------------------- > # dd if=/dev/ro_device of=/tmp/test.dd bs=4096 skip=2556972231680 > count=773376 iflag=skip_bytes > -- 8< --------------------------------------------------------- > > The resulting /tmp/test.dd file looks like a correct filesystem: > -- 8< --------------------------------------------------------- > # file /tmp/dd_test > /tmp/dd_test: Linux rev 1.0 ext2 filesystem data (mounted or unclean), > UUID=da57c5f6-1018-8a45-83b9-e12a39be7ce2, volume name "casper-rw" > (large files) > -- 8< --------------------------------------------------------- > > But I can't seem to be able to mount it: > -- 8< --------------------------------------------------------- > [507159.565593] EXT2-fs (loop3): warning: mounting unchecked fs, > running e2fsck is recommended > [507165.114603] EXT2-fs (loop3): error: ext2_check_page: bad entry in > directory #2: : unaligned directory entry - offset=0, > inode=2263518911, rec_len=23425, name_len=177 > [507165.129657] EXT2-fs (loop3): error: ext2_readdir: bad page in #2 > -- 8< --------------------------------------------------------- > > Did I misinterpret the output of findsuper? No, this looks like the _start_ of a filesystem image, but there is no real guarantee that the blocks in the file are allocated contiguously in the actual filesystem, so your "dd" is unlikely to work properly. The filesystem itself is 773376 * 4KB ~= 3GB in size, and if it was originally created as a sparse file there is little chance those blocks were allocated contiguously. The findsuper utility is meant to locate superblocks in a block device to help recover from partition table woes. If you still have access to some of the files, you should consider to copy them out of the filesystem. Next, I would recommend to make an LVM snapshot and run e2fsck on that to see what else you get out of it. Depending on the amount and type of corruption, that may take a very long time on a 20TB filesystem, and not be worthwhile to wait for. Cheers, Andreas
Attachment:
signature.asc
Description: Message signed with OpenPGP
