Re: [RFC PATCH v2 3/3] dm zoned: add regular device info to metadata

[Damien Le Moal <Damien.LeMoal@wdc.com>]

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