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
