From: Mariusz Tkaczyk <mtkaczyk@kernel.org>
To: Yu Kuai <yukuai1@huaweicloud.com>
Cc: Tomas Mudrunka <tomas.mudrunka@gmail.com>,
linux-raid@vger.kernel.org, song@kernel.org, yukuai@kernel.org,
"yukuai (C)" <yukuai3@huawei.com>
Subject: Re: [PATCH] Export MDRAID bitmap on disk structure in UAPI header file
Date: Fri, 3 Jan 2025 10:38:01 +0100 [thread overview]
Message-ID: <20250103103801.1420d5d5@mtkaczyk-private-dev> (raw)
In-Reply-To: <65347b89-a7ef-927f-c6e7-0a1a08971248@huaweicloud.com>
On Fri, 3 Jan 2025 09:14:30 +0800
Yu Kuai <yukuai1@huaweicloud.com> wrote:
> Hi,
>
> 在 2025/01/02 19:48, Tomas Mudrunka 写道:
> >> Just curious, what you guys do for filesystems like ext4/xfs, and
> >> they just define the same structure in user-space tools.
> >>
> >> looks like your tool do support to create ext4 images, and it's
> >> using ext4's use-space tools directly. If it's true, do you
> >> consider to use mdadm directly?
> >>
> >> Thanks,
> >> Kuai
> >
> > Yes, we do use external tools when possible. It is not possible
> > with mdadm. Mdadm cannot create disk image of MD RAID array. Kernel
> > does this.
>
> I'm a bit confused here, if you mean metadata, I think it's mdadm that
> write init metadata to disk, the only exception is dm-raid.
I think it means that currently you have to create kernel (MD) raid
device (assemble using metadata) to have a chance creating image.
>
> > We want/need purely userspace generator, so we don't have to care
> > about permissions, losetup, kernel-side mdraid runtime, etc... We
> > just want to generate valid image without involving kernel in any
> > way.
>
> I believe mdadm can do this, Mtkaczyk what do you think?
I agree. The right way is to incorporate it with mdadm.
We should create a volume image (data) without MD internals.
With that, we will have control on this functionality. Also, we will be
able to provide support for every metadata format.
>
> The problem is that system service will recognize raid disks and
> assemble the array automatically, you might what to disable them.
I don't think we need to care. They goal is to not have and use MD
module so mdadm will fail to load personalities.
>
> Thanks,
> Kuai
>
> > I was using mdadm before switching to genimage and it adds
> > complexity of handling all the edge cases of kernel states.
> > Mkfs.ext4 can create image without involving kernel, mdadm cannot,
> > it always instructs kernel to create the metadata for it when
> > creating array.
> >
> > In my opinion we should decide whether it makes sense for kernel to
> > export the structures in header file and either provide all of
> > them, or provide none. That might be valid reasoning to say every
> > userspace program should include its own definitions of structures.
> > But providing half does not make any sense.
Sorry, This is old application and some solutions are here for years-
they are working so nobody tried to change them. If you are looking for
challenges this software is full of them!
Thanks,
Mariusz
next prev parent reply other threads:[~2025-01-03 9:38 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
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 [this message]
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=20250103103801.1420d5d5@mtkaczyk-private-dev \
--to=mtkaczyk@kernel.org \
--cc=linux-raid@vger.kernel.org \
--cc=song@kernel.org \
--cc=tomas.mudrunka@gmail.com \
--cc=yukuai1@huaweicloud.com \
--cc=yukuai3@huawei.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).