linux-ext4 - Re: allowing ext4 file systems that wrapped inode count to continue working

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]

Message-ID: <20180728181910.GA16717@thunk.org>
Date:   Sat, 28 Jul 2018 14:19:10 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Jaco Kroon <jaco@....co.za>
Cc:     Andreas Dilger <adilger@...ger.ca>, Jan Kara <jack@...e.cz>,
        linux-ext4 <linux-ext4@...r.kernel.org>
Subject: Re: allowing ext4 file systems that wrapped inode count to continue
 working

On Sat, Jul 28, 2018 at 03:47:18PM +0200, Jaco Kroon wrote:
> 
> Just a note.  In order to be able to utilize dumpe2fs I had to apply the
> patch from my first email.  The only utility that would start up (and
> fail) was fsck.  It should be noted that I've hacked s_inodes_count to
> 0xFFFFFFFF the first time we encountered this (with assistance from Jan).
> 
> Group 524287: (Blocks 17179836416-17179869183) csum 0xe0ea
> [INODE_UNINIT, ITABLE_ZEROED]
>   Group descriptor at 17179836416
>   Block bitmap at 17179344911 (bg #524272 + 15)
>   Inode bitmap at 17179344927 (bg #524272 + 31)
>   Inode table at 17179352608-17179353119 (bg #524272 + 7712)
>   12 free blocks, 8192 free inodes, 0 directories, 8192 unused inodes
>   Free blocks: 17179838452-17179838463
>   Free inodes: 4294959105-4294967296
> 
> If I read that correctly none of the inodes are in use, but there are
> some data blocks in use (in fact, most of it).
> 
> Suggestions/pointers on how to get those blocks re-allocated elsewhere?

I'd suggest trying to see if you can use debugfs's icheck command to
take a block number (such as 17179353120, for example, just beyond the
inode table) and map it to an inode number:

debugfs: icheck 17179353120

This will give you some inode number, perhaps 156789 (for example).
You can then take the inode number and map it to a pathname:

debugfs: ncheck 156789

You can then mount the file system, copy that file off, and then
delete it.  Then see what blocks are left as in use.  Lather, Rinse,
Repeat.  :-)

						- Ted