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