| 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
| ||
|
Date: Tue, 27 Jun 2023 10:35:34 +0200
From: Roberto Ragusa <mail@...ertoragusa.it>
To: "linux-ext4@...r.kernel.org" <linux-ext4@...r.kernel.org>
Subject: Re: packed_meta_blocks=1 incompatible with resize2fs?
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
Powered by blists - more mailing lists