> > 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/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
