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;
Date:   Tue, 27 Jun 2023 20:03:27 -0400
From:   "Theodore Ts'o" <tytso@mit.edu>
To:     Roberto Ragusa <mail@robertoragusa.it>
Cc:     "linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: packed_meta_blocks=1 incompatible with resize2fs?
Message-ID: <20230628000327.GG8954@mit.edu>
References: <49752bf2-71ec-7fbf-dcdf-93940cfa92c9@robertoragusa.it>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <49752bf2-71ec-7fbf-dcdf-93940cfa92c9@robertoragusa.it>
Precedence: bulk

On Mon, Jun 26, 2023 at 11:15:14AM +0200, Roberto Ragusa wrote:
> 
> mkfs.ext4 -E packed_meta_blocks=1
> 
> all the fs metadata is placed at the start of the disk.
> Unfortunately I have not found a way to enlarge the fs
> and maintain this property, new metadata is allocated from the
> added space.

Yeah, sorry, there isn't a way of doing this.  packed_meta_blocks=1 is
an mkfs.ext4 (aka mke2fs) option, and it influences where it choose to
allocate the metadata blocks when the file system is created.
Unfortunately, (a) there is no place where the fact that the file
system was created with this mkfs option is recorded in the
superblock, and (b) once the file system starts getting used, the
blocks where the metadata would need to be allocated at the start of
the disk will get used for directory and data blocks.

> Is there a way to have metadata at the beginning of the disk
> and be able to enlarge the fs later?
> Planning to do this on big filesystems, placing the initial part
> on SSD extents; reformat+copy is not an option.

OK, so I think what you're trying to do is to create a RAID0 device
where the first part of the md raid device is stored on SSD, and after
that there would be one or more HDD devices.  Is that right?

In theory, it would be possible to add a file system extension where
the first portion of the MD device is not allowed to be used for
normal block allocations, so that when you later grow the raid0
device, the SSD blocks are available for use for the extended
metadata.  This would require adding support for this in the
superblock format, which would have to be an RO_COMPAT feature (that
is, kernels that didn't understand the meaning of the feature bit
would be prohibited from mounting the file system read/write, and
older versions of fsck.ext4 would be prohibited from touching the file
system at all).  We would then have to add support for off-line and
on-line resizing for using the reserved SSD space for this use case.

The downside of this particular approach is that the SSD space would
be "wasted" until the file system is resized, and you have to know up
front how big you might want to grow the file system eventually.  I
could imagine another approach might be that when you grow the file
system, if you are using an LVM-type approach, you would append a
certain number of LVM stripes backed by SSD, and a certain number
backed by HDD's, and then give a hint to the resizing code where the
metadata blocks should be allocated, and you would need to know ahead
of time how many SSD-backed LV stripes to allocate to support the
additional number of HDD-backed LV stripes.

This would require a bunch of abstraction violations, and it's a
little bit gross.  More to the point, it would require a bunch of
development work, and I'm not sure there is interest in the ext4
development community, or the companies that back those developers,
for implementing such a feature.

Cheers,

						- Ted