From: "Jan Lübbe" <jlu@pengutronix.de>
To: Tobias Waldekranz <tobias@waldekranz.com>,
Ahmad Fatoum <a.fatoum@pengutronix.de>,
barebox@lists.infradead.org
Cc: Richard Weinberger <richard@nod.at>,
Michael Olbrich <mol@pengutronix.de>,
anis chali <chalianis1@gmail.com>,
Marco Felsch <m.felsch@pengutronix.de>
Subject: Re: [PATCH 0/5] dm: Initial work on a device mapper
Date: Wed, 03 Sep 2025 08:50:02 +0200 [thread overview]
Message-ID: <234808b66fb792f4b9ab50654dd3c018e90db6b8.camel@pengutronix.de> (raw)
In-Reply-To: <874itk4jzn.fsf@waldekranz.com>
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. 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. 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? :)
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 |
next prev parent reply other threads:[~2025-09-03 6:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-28 15:05 Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 1/5] string: add strtok/strtokv Tobias Waldekranz
2025-09-04 11:00 ` Ahmad Fatoum
2025-09-04 13:35 ` Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 2/5] dm: Add initial device mapper infrastructure Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 3/5] dm: linear: Add linear target Tobias Waldekranz
2025-08-29 5:56 ` Ahmad Fatoum
2025-08-28 15:05 ` [PATCH 4/5] test: self: dm: Add test of " Tobias Waldekranz
2025-08-28 15:05 ` [PATCH 5/5] commands: dmsetup: Basic command set for dm device management Tobias Waldekranz
2025-08-29 8:29 ` [PATCH 0/5] dm: Initial work on a device mapper Sascha Hauer
2025-08-31 7:48 ` Tobias Waldekranz
2025-09-02 8:40 ` Ahmad Fatoum
2025-09-02 9:44 ` Tobias Waldekranz
2025-08-29 11:24 ` Ahmad Fatoum
2025-08-31 7:48 ` Tobias Waldekranz
2025-09-02 9:03 ` Ahmad Fatoum
2025-09-02 13:01 ` Tobias Waldekranz
2025-09-03 7:05 ` Jan Lübbe
2025-09-02 14:46 ` Jan Lübbe
2025-09-02 21:34 ` Tobias Waldekranz
2025-09-03 6:50 ` Jan Lübbe [this message]
2025-09-03 20:19 ` Tobias Waldekranz
2025-09-02 14:34 ` Jan Lübbe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=234808b66fb792f4b9ab50654dd3c018e90db6b8.camel@pengutronix.de \
--to=jlu@pengutronix.de \
--cc=a.fatoum@pengutronix.de \
--cc=barebox@lists.infradead.org \
--cc=chalianis1@gmail.com \
--cc=m.felsch@pengutronix.de \
--cc=mol@pengutronix.de \
--cc=richard@nod.at \
--cc=tobias@waldekranz.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox