[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJz=VjEOnU=wsdjmHitxQsTXvW7AMgYRiKFJPGq_imPUbu5+GQ@mail.gmail.com>
Date: Thu, 12 Oct 2017 15:02:03 -0700
From: Kilian Cavalotti <kilian.cavalotti.work@...il.com>
To: Andreas Dilger <adilger@...ger.ca>
Cc: linux-ext4@...r.kernel.org
Subject: Re: Recover from a "deleted inode referenced" situation
On Wed, Oct 11, 2017 at 7:36 AM, Kilian Cavalotti
<kilian.cavalotti.work@...il.com> wrote:
> On Tue, Oct 10, 2017 at 1:36 PM, Andreas Dilger <adilger@...ger.ca> 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).
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
149595921408 18323935265112545280 13818231386087778304 2356078660
1024 28990 Sun Sep 7 13:34:55 2098 dc41997c 8�b���a`/����03��x^��|
��Fq��<<��_�sߠ蒿���Cx�X��Z��8���MxR��(R���/
�@�-+�>�F�������ۂ����@�
���$�}��|���)����
��K����y��l��0�ހc.3`B�~g݄`A�~��{�12��!^p���������k�Dn
0������oD�����I��;&ڢ�B�����/�Y� �_Ba�o���?$}�b'�B���%A�!�#�$@u�8~
293534171136 293534170112 18277258492928 95590400 4096 0 Thu
Nov 26 23:22:42 2015 12c2c019 1.42.6-5644
716505512960 716505511936 716628391936 120000 1024 0 Thu Aug
20 23:31:41 2009 d33ff464
716539067392 716530677760 716653557760 120000 1024 1 Thu Aug
20 23:31:41 2009 d33ff464
[...]
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?
Thanks!
--
Kilian
Powered by blists - more mailing lists