From: Mariusz Tkaczyk <mtkaczyk@kernel.org>
To: "Tomáš Mudruňka" <tomas.mudrunka@gmail.com>,
linux-raid@vger.kernel.org, "Song Liu" <song@kernel.org>,
yukuai@kernel.org
Subject: Re: [PATCH] Export MDRAID bitmap on disk structure in UAPI header file
Date: Tue, 31 Dec 2024 15:23:02 +0100 [thread overview]
Message-ID: <20241231152302.3dc7a710@mtkaczyk-private-dev> (raw)
In-Reply-To: <20241231123108.215cc05e@mtkaczyk-private-dev>
Sorry missclick, adding linux-raid now.
I think we don't need to spam on linux-kernel as these are MD internals.
Kuai please take a look again.
Thanks,
Mariusz
On Tue, 31 Dec 2024 12:31:08 +0100
Mariusz Tkaczyk <mtkaczyk@kernel.org> wrote:
> On Tue, 31 Dec 2024 12:00:31 +0100
> Tomáš Mudruňka <tomas.mudrunka@gmail.com> wrote:
>
> > > > Thanks for the patch, however, Why do you want to directly
> > > > manipulate the metadata instead of using mdadm? You must first
> > > > provide an explanation to convince us that what you're doing
> > > > makes sense, and it's best to show your work.
> >
> > I am adding MD RAID support to genimage tool:
> > https://github.com/pengutronix/genimage/
> >
> > It is used to generate firmware/disk images. Without such a tool it
> > is impossible to build disk image containing md raid metadata
> > without actually assembling it in the kernel via losetup or
> > something...
> >
> > I am already using #include <linux/raid/md_p.h> which includes
> > references to bitmap structures:
> >
> > $ grep -ri bitmap /usr/include/linux/raid/md_p.h
> > #define MD_SB_BITMAP_PRESENT 8 /* bitmap may be present nearby
> > */ __le32 feature_map; /* bit 0 set if 'bitmap_offset' is
> > meaningful */ __le32 bitmap_offset; /* sectors after start of
> > superblock that bitmap starts
> > * NOTE: signed, so bitmap can be before
> > superblock #define MD_FEATURE_BITMAP_OFFSET 1
> > #define MD_FEATURE_RECOVERY_BITMAP 128 /* recovery that is
> > happening
> > * is guided by bitmap.
> > #define MD_FEATURE_ALL (MD_FEATURE_BITMAP_OFFSET \
> > |MD_FEATURE_RECOVERY_BITMAP \
> >
> > But when i use those, the resulting metadata is invalid, unless i
> > populate the structures from drivers/md/md-bitmap.h so i had to
> > copypaste its contents to my code, but i am not happy about it
> > (including half and copypasting half):
>
> https://github.com/md-raid-utilities/mdadm/blob/main/bitmap.h
>
> Correct me if I'm wrong but looks like it is what we did in mdadm.
> Well, If you don't want to care about it, you can consider adding
> mdadm as submodule in your application and use mdadm's headers.
>
> Just an option, I have no hard feelings here.
>
> Looking into that now make me more feeling that we should export this
> header long time ago instead of reimplementing it in mdadm. Kuai, what
> do you think?
>
> >
> > https://github.com/Harvie/genimage/blob/master/image-mdraid.c
> >
> > > I'm with Kuai here. I would also add that for such purposes you
> > > can use externally managed metadata, not native. External
> > > management was proposed to address your problem however over the
> > > years it turned out to not be good conception (kernel driver
> > > relies on userspace daemon which is not secure).
> > >
> > > Thanks,
> > > Mariusz
> >
> > Hope my reply is sufficient.
> >
> > Thank you guys!
> > Tom
>
> Looks like old problem we get used to. If Kuai agrees too, I'm open to
> add this but.. as a mdadm maintainer (primary tool to manipulate
> mdraid) I would like you to handle this on mdadm site too to make sure
> we have it consistent and we exported exactly what is needed.
>
> Hope, it has some sense now!
> Thanks,
> Mariusz
next prev parent reply other threads:[~2024-12-31 14:23 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-31 3:09 [PATCH] Export MDRAID bitmap on disk structure in UAPI header file Tomas Mudrunka
2024-12-31 3:47 ` Yu Kuai
2024-12-31 8:59 ` Mariusz Tkaczyk
2024-12-31 11:02 ` Tomáš Mudruňka
[not found] ` <CAH2-hc+QK0SZgDjOScegsDk8R8gQEZgJ5Vg1M1J_v-yDEym=Dw@mail.gmail.com>
[not found] ` <20241231123108.215cc05e@mtkaczyk-private-dev>
2024-12-31 14:23 ` Mariusz Tkaczyk [this message]
2025-01-02 1:43 ` Yu Kuai
2025-01-02 11:48 ` Tomas Mudrunka
2025-01-03 1:14 ` Yu Kuai
2025-01-03 9:38 ` Mariusz Tkaczyk
2025-01-03 11:54 ` Tomas Mudrunka
2025-01-07 8:36 ` Mariusz Tkaczyk
2025-01-07 22:58 ` Song Liu
2025-01-15 15:23 ` Tomáš Mudruňka
2025-01-06 15:25 ` Christoph Hellwig
2025-01-06 15:40 ` Tomáš Mudruňka
2025-01-06 15:45 ` Christoph Hellwig
2025-02-03 11:43 ` Mariusz Tkaczyk
2025-02-03 17:18 ` [PATCH v2] " Tomas Mudrunka
2025-02-06 22:30 ` [PATCH v3] " Tomas Mudrunka
2025-02-18 2:32 ` Yu Kuai
2025-02-18 11:38 ` [PATCH v4] " Tomas Mudrunka
2025-02-19 6:11 ` Christoph Hellwig
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=20241231152302.3dc7a710@mtkaczyk-private-dev \
--to=mtkaczyk@kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=tomas.mudrunka@gmail.com \
--cc=yukuai@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.