[dm-devel] [RFC PATCH v2 3/3] dm zoned: add regular device info to metadata
Damien Le Moal
Damien.LeMoal at wdc.com
Wed Mar 25 08:02:30 UTC 2020
On 2020/03/25 15:47, Hannes Reinecke wrote:
> On 3/25/20 7:29 AM, Damien Le Moal wrote:
>> On 2020/03/24 20:04, Bob Liu wrote:
>>> This patch implemented metadata support for regular device by:
>>> - Emulated zone information for regular device.
>>> - Store metadata at the beginning of regular device.
>>>
>>> | --- zoned device --- | -- regular device ||
>>> ^ ^
>>> | |Metadata
>>> zone 0
>>>
>>> Signed-off-by: Bob Liu <bob.liu at oracle.com>
>>> ---
>>> drivers/md/dm-zoned-metadata.c | 135 +++++++++++++++++++++++++++++++----------
>>> drivers/md/dm-zoned-target.c | 6 +-
>>> drivers/md/dm-zoned.h | 3 +-
>>> 3 files changed, 108 insertions(+), 36 deletions(-)
>>>
> Having thought about it some more, I think we cannot continue with this
> 'simple' approach.
> The immediate problem is that we lie about the disk size; clearly the
> metadata cannot be used for regular data, yet we expose a target device
> with the full size of the underlying device.
> Making me wonder if anybody ever tested a disk-full scenario...
Current dm-zoned does not do that... What is exposed as target capacity is
number of chunks * zone size, with the number of chunks being number of zones
minus metadata zones minus number of zones reserved for reclaim. And I did test
disk full scenario (when performance goes to the trash bin because reclaim
struggles...)
> The other problem is that with two devices we need to be able to stitch
> them together in an automated fashion, eg via a systemd service or udev
> rule.
Yes, and that has been on my to-do list forever for the current dm-zoned...
> But for this we need to be able to identify the devices, which means
> both need to carry metadata, and both need to have unique identifier
> within the metadata. Which the current metadata doesn't allow to.
>
> Hence my plan is to implement a v2 metadata, carrying UUIDs for the dmz
> set _and_ the component device. With that we can update blkid to create
> links etc so that the devices can be identified in the system.
> Additionally I would be updating dmzadm to write the new metadata.
Yep. I think that is needed. And the metadata for the disk that does not store
the mapping tables and bitmaps can be read-only at run time, that is a super
block only holding identification/UUID.
> And I will add a new command 'start' to dmzadm which will then create
> the device-mapper device _with the correct size_. It also has the
> benefit that we can create the device-mapper target with the UUID
> specified in the metadata, so the persistent device links will be
> created automatically.
The size now should be correct with single device current setup.
>
> Bob, can you send me your improvements to dmzadm so that I can include
> them in my changes?
>
> Cheers,
>
> Hannes
>
--
Damien Le Moal
Western Digital Research
More information about the dm-devel
mailing list