[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAH2-hcJR8DpvHHFc+NjYkjrjqNiuE8CRxhQPh1YMnVWE3rXPQw@mail.gmail.com>
Date: Tue, 31 Dec 2024 12:02:15 +0100
From: Tomáš Mudruňka <tomas.mudrunka@...il.com>
To: Mariusz Tkaczyk <mtkaczyk@...nel.org>
Cc: Yu Kuai <yukuai1@...weicloud.com>, Song Liu <song@...nel.org>, linux-raid@...r.kernel.org,
linux-kernel@...r.kernel.org, "yukuai (C)" <yukuai3@...wei.com>
Subject: Re: [PATCH] Export MDRAID bitmap on disk structure in UAPI header file
> > 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
Powered by blists - more mailing lists