linux-ext4 - Re: Possible ext4 corruption

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:	Tue, 10 Mar 2009 18:48:10 -0400
From:	Theodore Tso <tytso@....edu>
To:	Kevin Shanahan <kmshanah@...b.org.au>
Cc:	Andreas Dilger <adilger@....com>,
	Eric Sandeen <sandeen@...hat.com>, linux-ext4@...r.kernel.org
Subject: Re: Possible ext4 corruption - ACL related?

On Wed, Mar 11, 2009 at 07:44:51AM +1030, Kevin Shanahan wrote:
> Thanks Ted. Just so I know what I'm doing if/when this comes up again, I
> guess the process would be:
> 
>   - debugfs /dev/some-filesystem
>   - debugfs:  stat "some/problem/file"
>   - get the inode number from the output above (867 in this case)
>   - debugfs dump 867 inode867.bin

Actually, it's a bit more complicated than that.  I should really add
a hook to debugfs to automate this, but... to find the block to grab,
you do this.   

1)  Grab the following fields from dumpe2fs (or debugfs's "stats" command)

Inodes per group:         8192
Block size:               4096
Inodes per group:         8192
Inode size:               256

2) To find out which block group the inode is located in, we calculate:

inode bg = inode_number / inodes_per_group
         = 867 / 8192 = block group 0

(everything done using integer division, rounding any fraction down to 0.)

3) To find where the inode table for block group in question can be
found, check out dumpe2fs.

Group 0: (Blocks 0-32767) [ITABLE_ZEROED]
      ...
  Inode table at 65-576 (+65)
                 ^^^^^^

OK, we know it begins at block 65.

Now some more math:

inode_per_block = block_size / inode_size
		= 4096 / 256 = 16

offset_block = (inode_number % inodes_per_group) / inodes_per_block
             = (867 % 8192) / 16
	     = 54

So now we know that the block containing inode 867 is 65+54 = 119

Now to dump that block, we do:

    dd if=/dev/fs-device of=block-119.dump bs=4k skip=119 count=1


> Or perhaps running e2fsck -n first to see which inodes really look
> corrupted and get the numbers that way. 

Yep.  In general, when you get corruption like this, the bad inodes
comes in chunks of 16 (if you are using 256 byte inodes) or 32 (if you
are using 128 byte inodes).

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html