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