linux-ext4 - Re: ext4fs block role, debugfs testb and icheck mismatch

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 20 Jan 2019 12:35:50 +0100
From:   Etienne Buira <etienne.buira@...e.fr>
To:     linux-ext4@...r.kernel.org
Subject: Re: ext4fs block role, debugfs testb and icheck mismatch

On Wed, Jan 16, 2019 at 10:34:23PM +0100, Etienne Buira wrote:
> For the background: i've hit defect sectors (on part of md array), and i
> want to rewrite those sectors to force hdd reallocation, so i need to
> figure out what they are used for.

Hi,

I could resolve my issue, i was wrong on block number.

What's left is the weird behaviour of debugfs, which reports a given
block as "in use", and not linked to any inode (although it is in data
part):

> Unrolling the layers under fs, i'm interested in a 4K blocks range that
> starts at 2035, here starts the trouble:
> debugfs 1.43.9 (8-Feb-2018)
> debugfs:  testb 2035
> Block 2035 marked in use
> debugfs:  icheck 2035
> Block   Inode number
> 2035    <block not found>
> 
> From this result, i tried to figure out if this block were used for fs
> internal structures.
> Using dumpe2fs, i see that this block belongs to group 0, and falls
> beyond fs structures (last block for inode table is reported as 1568).
> Block 2035 is not reported as free blocks.

The debugfs queries have been done multiple times, so it is quite
unprobable fs allocated this block everytime before i issued testb,
and released it by the time i issued icheck.

Regards.