Received-SPF: pass (google.com: domain of linux-ext4-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <c4351547-af48-d023-e6a8-cbc353effa75@robertoragusa.it>
Date:   Tue, 27 Jun 2023 10:35:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.4.0
Subject: Re: packed_meta_blocks=1 incompatible with resize2fs?
Content-Language: en-US
From:   Roberto Ragusa <mail@robertoragusa.it>
To:     "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
References: <49752bf2-71ec-7fbf-dcdf-93940cfa92c9@robertoragusa.it>
In-Reply-To: <49752bf2-71ec-7fbf-dcdf-93940cfa92c9@robertoragusa.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk

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