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: <76e86548-d265-c2dd-b874-154a16b4dadb@uls.co.za>
Date:   Fri, 27 Jul 2018 08:11:04 +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

Thanks Ted.

Your explanation confirms my own deductions from last night.

I was contemplating the change to change the number of inodes/group
after my email last night, and that is something which should be do-able
(with some major risks), albeit with major risks, and would also require
code changes (unless the patches Andreas mentioned is somewhere and
working).

I've initiated the process of moving blocks of data at a time.   Will
have to do the move data, shrink old, grow new repetitive cycle.  It
will take significant time, but that's what it will have to be.  I'll
advise if I get stuck on the first shrink of taking away that single
group.  Hopefully those blocks won't be in use (nor the inodes).

Thanks again to both yourself, Andreas as well as Jan.

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