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

["Jan Lübbe" <jlu@pengutronix.de>]

On Wed, 2025-09-03 at 22:19 +0200, Tobias Waldekranz wrote:
> 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.

OK, I've never tried to figure out how much work such a subset would be.

> > 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 complication arises because one VG can have multiple PVs. So you have a
userspace component which scans new block devices to see if they are PVs and
assembles them into VGs. As "new" block devices can come in late on discoverable
busses, you're not sure if some more might appear of if an incomplete VG will
never be done.

For our embedded case, you can limit yourself to a strict nesting: one physical
partition can contain multiple dynamic partitions. So you when that specific
physical partition shows up, you can synchronously setup all dynamic partitions
(or fail due to an error). So there's no waiting and scanning of block devs
appearing at runtime.

Perhaps there's a way to do LVM probing synchronously as well, but if so, I'm
not aware that that's supported.

> > 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.

Yes, it would mean custom tooling. Building Android tools externally seems a lot
of pain (just look at what's needed to build fastboot and adb).

My idea is probably more of a long-term plan or wish. ;) One neat trick of the
android partitioning ("virtual A/B") is that they can temporarily use space from
the data partition to hold the newly installed system until it's confirmed good.
Doing that with LVM would mean using the thin provisioning device mappers.

Regards
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 |