Re: [PATCH 0/5] dm: Initial work on a device mapper

[Tobias Waldekranz <tobias@waldekranz.com>]

On ons, sep 03, 2025 at 08:50, Jan Lübbe <jlu@pengutronix.de> wrote:
> On Tue, 2025-09-02 at 23:34 +0200, Tobias Waldekranz wrote:
>> On tis, sep 02, 2025 at 16:46, Jan Lübbe <jlu@pengutronix.de> wrote:
>> > On Tue, 2025-09-02 at 11:03 +0200, Ahmad Fatoum wrote:
>> > > > Yeah I noticed that, _very_ useful. For Infix, if we end up going with
>> > > > LVM, I suspect we won't be able to send all of that info along with the
>> > > > commandline, and will end up needing to figure that out (again) in an
>> > > > initramfs - but for most cases I think it would work really well!
>> > > 
>> > > Ah, didn't think of LVM. If mix-and-match is no problem for you, then
>> > > doing it in the initramfs is a workable solution of course.
>> > 
>> > If you are thinking about LVM, you may want to take a look at how Android is
>> > using dm-linear for "dynamic partitions":
>> > https://source.android.com/docs/core/ota/dynamic_partitions/ab_launch
>> > https://source.android.com/docs/core/ota/dynamic_partitions/implement
>> > 
>> > This is also related to virtual A/B:
>> > https://source.android.com/docs/core/ota/virtual_ab
>> > 
>> > The components are "snapuserd" and "dm-user" (which was not merged):
>> > https://lpc.events/event/11/contributions/1049/attachments/826/1562/2021%20LPC_%20dm-snapshot%20in%20user%20space.pdf
>> > https://lwn.net/Articles/838986/
>> > 
>> > I'm not sure what they use at the moment...
>> 
>> Very interesting, thank you!
>> 
>> I get why they want something like that for Android, but it does feel
>> quite daunting to deploy for the systems I typically work on.
>> 
>> If one was to ignore the business of background-merging of COW data
>> etc. and was just looking to have a way of allocating volumes from
>> persistent storage, do you see any advantages with Android's metadata
>> format and/or tooling over that provided by the LVM2 project?
>
> LVM2 in general is quite complex.

Oh yes, full LVM support would be mind-bendingly complicated in a
bootloader. I am aiming for an extremely small subset:

Being able to parse a VG made up of a single PV, containing LV's made up
of only linear segments.

> Some people don't like that it's not easily
> possible to know (in udev/systemd) when all volumes are found and set-up, making
> boot time dependencies difficult.

I see. Is that because, in contrast to most other devices, userspace
needs to initiate device creation? Are Android dynamic partitions better
behaved in this respect?

> The Android metadata (or something similar)
> seems to be simple enough to implement in a bootloader. So, as we only need a
> small subset of the full LVM functionality on embedded devices, perhaps there's
> space for a lightweight alternative? :)

Agreed, I am not exactly thrilled about needing a parser for the LVM
ASCII metadata format in Barebox :)

Android dynamic partitions undoubtedly seem much better from that
perspective.

Here is my concern with it: wouldn't going this route mean that you have
to either (a) build your own tooling for working with Android dynamic
partitions, or (b) have some semi-automated way of extracting the
existing tooling from the Android source tree? In contrast, the LVM2
package is just a config option away in both Buildroot, PTXdist, and
Yocto.

> Jan
> -- 
> Pengutronix e.K.                           |                             |
> Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
> 31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |