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: <2927ca47-3105-7111-92ef-30e5501de52e@uls.co.za>
Date:   Sat, 28 Jul 2018 15:47:18 +0200
From:   Jaco Kroon <jaco@....co.za>
To:     "Theodore Y. Ts'o" <tytso@....edu>
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

Hi,

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?

Kind Regards,
Jaco


On 27/07/2018 00:16, Theodore Y. Ts'o wrote:
> On Thu, Jul 26, 2018 at 07:47:10PM +0200, Jaco Kroon wrote:
>> I really need to further expand that filesystem.  I can take it offline
>> for a few hours or so if there is no other options, but that's not ideal
>> (even getting to run umount when nothing is accessing that is a scarce
>> opportunity).  The VG on which it's contained does have 4.5TB available
>> for expansion, I just don't want to allocate that anywhere until I have
>> a known working strategy.
> Further expanding the file system is going to require kernel and
> e2fsprogs changes, and a new read-only compat feature flag.  That's
> because what we would have to do is to be able to support block groups
> that do not have any inode table blocks.  So we would have to teach
> ext4 how to ignore inode table blocks in block groups that would
> result in inode numbers going beyond 2**32.
>
> So that is not something that we can do easily, unfortunately.  It
> shouldn't be *that* hard to make this change, but it will require real
> (and new) development effort.
>
> 							- Ted