linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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

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