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: <20180726221642.GC13922@thunk.org>
Date:   Thu, 26 Jul 2018 18:16:42 -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 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