Re: [PATCH v4 1/5] expand-on-first-boot: support resizing a btrfs

[Henning Schild <henning.schild@siemens.com>]

Am Tue, 13 Dec 2022 18:01:49 +0100
schrieb "Roberto A. Foglietta" <roberto.foglietta@gmail.com>:

> On Tue, 13 Dec 2022 at 11:15, <henning.schild@siemens.com> wrote:
> >
> > From: Henning Schild <henning.schild@siemens.com>
> >
> > This adds support for resizing btrfs filesystems if they are in that
> > last partition. It also prepares for potentially other filesystems
> > to come in the future by introducing a switch-case.
> >
> > The mounting logic is taken from the systemd-growfs patches we had
> > to revert again. Some filesystems need to online for resizing, but
> > in order to find the filesystem of a partition (without udev)
> > mounting it and letting the kernel detect seems a good idea.
> >  
> 
> It is possible to avoid the udevadm settle constraints only because
> the boot device [1] is the same as the rootfs device. The boot device
> should be mapped by the kernel at boot time, so it would be available
> but not necessarily present in /dev partition if this has no static
> links or devfs mounted at the time of mount. If udevd is the demon
> that we choose to populate the /dev then it would be better to wait
> until it settles down. The stats about boot time on different
> platforms will show that only hardware slow to detect has a larger
> boot time.
> 
> [1] in some embedded devices the boot device is an internal and small
> device dedicated to the boot while the rootfs is on a separate
> plug-able device.
> 
> I have no clue how this would matter in the case of ISAR.

The whole thing is about only one device and its last partition, not
more! And we clearly expect boot and root to reside on the same
mass-storage. Or any other last partition (my series was also manually
tested against another /data partition to be grown).

Thanks for approving that we do not need to "udevadm settle" in that
case!

For any more advanced scenario people can always run whatever they
want, possibly systemd-repart. Isar is all about a single image for one
mass storage device, it can be used for more but such code will have to
live in layers.

With btrfs we could have one filesystem with multiple
devices/partitions and the code i (and you and Joe) proposed here will
likely not work. Let us keep things simple in the core while allowing
layers to do whatever they please.

expand-on-first-boot is for the "normal rpi case" where a stand-alone
image gets flashed to one device of which we only know the final size
when we boot it up. Not just rpi ... it could also be your qemuamd64
image flashed to an ssd/hdd in any PC. 

ciao,
Henning

> Best regards, R-
>