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
