On 6/26/23 11:15, Roberto Ragusa wrote:
My attempts to work around the issue have failed: - adding resize=4290772992 in mkfs doesn't help - creating a bigger fs with packed_meta_blocks, then shrinking it, then re-extending it to the original size still allocates from the new space
An additional attempt is still not fully reaching the objective. mkfs.ext4 -E resize=1073741824 -G 32768 /dev/mydev I've tried raising G to have a single flex_bg group and this is partially working, since resizing places "block bitmap" and "inode bitmap" in the initial part of the disk, while "inode table" is still taken from the added space. (tested on a rather full fs) Do I have any other option? It looks like resize2fs has no way to force the inode table to be where a fresh mkfs would put it, pushing existing blocks out of the way. What complexity can I expect to find if I try to add this feature to resize2fs? Is there a way to NOT add more inodes when resizing? I would be happy to keep the same number I've originally got, but apparently each new block group assumes to have some inodes. My use case should be a really wide interest one: metadata on fast hardware, data on slow hardware. Is there no solution? Regards. -- Roberto Ragusa mail at robertoragusa.it
