Re: [PATCH] Export MDRAID bitmap on disk structure in UAPI header file

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

在 2024/12/31 22:23, Mariusz Tkaczyk 写道:
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@xxxxxxxxxx> wrote:

On Tue, 31 Dec 2024 12:00:31 +0100
Tomáš Mudruňka <tomas.mudrunka@xxxxxxxxx> 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):

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


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


.






[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux