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

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

Message-ID: <20180724174226.GC3670@thunk.org>
Date:   Tue, 24 Jul 2018 13:42:26 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Jaco Kroon <jaco@....co.za>
Cc:     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 Tue, Jul 24, 2018 at 05:00:04PM +0200, Jaco Kroon wrote:
> I'm busy trying to write a patch for e2fsck that would allow it to (on
> top of the referenced series by Jan) enable fsck to at least clear the
> filesystem from other errors where currently if I hack the inode count
> to ~0U fsck, tune2fs and friends fail.

Can you run dumpe2fs on the file system and make sure the last block
group is not used?  It probably shouldn't be in use if you just
converted the file system.

The simplest way to get your file system working again would be to
just drop the last block group.  To do that, look at the starting
number of the last block group, and use debugfs set the number blocks
in the superblock.  So if the last block group looks like this:

Group 524287: (Blocks 17179836416-17179869183) csum 0x90d9 [INODE_UNINIT]
  Block bitmap at 17179344911 (bg #524272 + 15), csum 0xdd9ecdea
  Inode bitmap at 17179344927 (bg #524272 + 31), csum 0x00000000
  Inode table at 17179346848-17179346975 (bg #524272 + 1952)
  32768 free blocks, 2048 free inodes, 0 directories, 2048 unused inodes
  Free blocks: 17179836416-17179869183
  Free inodes: 1073739777-1073741824

Then you would do this:

debugfs -w /tmp/exp/exp
debugfs: ssv blocks_count 17179836416

You can then set the inodes_count to be

   (<new_blocks_count> / 32768) * <inodes_per_group>

Inodes per group is reported by dumpe2fs -h.

This might be simpler than trying to make e2fsprogs be able to deal
with it.

Cheers,

					- Ted