linux-ext4 - Re: Recover from a "deleted inode referenced" situation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 11 Oct 2017 07:36:31 -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

Hi Andreas,

Thanks a lot for taking the time to answer my plea for help. :)

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?

> This is made *much* more complex if you have other LVs on the same
> storage, and the LV was increased in size over multiple iterations,
> resulting in a fragmented allocation of PEs.

Just one LV there.

>> $ ls /vol
>> ls: cannot access backup: Input/output error
>> drwxr-xr-x 2 root root 4096 Sep 28 11:10 .
>> drwxr-xr-x 4 root root 4096 Sep 14  2013 ..
>> -????????? ? ?    ?       ?            ? backup
>> [...]
>>
>> I re-remounted read-only as soon as I realized my mistake, but the
>> filesystem stayed mounted r/w for a few minutes.
>
> It sounds like this replayed a corrupted journal over the rest of your
> filesystem, leading to further corruption.

Ah I see. So even of no process was actively writing to the
filesystem, simply remounting it read-write made it replay an old
journal? I know I shouldn't have done that, but I really didn't expect
so much impact: there's probably only around 15-20% of the original
data left... :(

> My only recommendation would be to update to the latest e2fsprogs,
> since it usually fixes important issues found in older versions.

Will make sure to use the latest one.

> Seems unlikely, unless you have an LVM snapshot.

I so wish, but I don't. :(

> e2fsck is good at recovering what files are available, much better
> than other filesystem recovery tools, but it can only work with the
> data it has.

So, another question: given e2fsck doesn't complain about a missing or
damaged superblock, is there any reason why running it with an
alternative superblock (with -b) would yield different results?

Thanks!
-- 
Kilian