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

[Tomáš Mudruňka]

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