All of lore.kernel.org
 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 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.