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
