On 2020/03/25 19:00, Hannes Reinecke wrote: > On 3/25/20 10:10 AM, Damien Le Moal wrote: >> On 2020/03/25 17:52, Hannes Reinecke wrote: >>> On 3/25/20 9:02 AM, Damien Le Moal wrote: >>>> 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...) >>>> >>> Thing is, the second number for the dmsetup target line is _supposed_ to >>> be the target size. >>> Which clearly is wrong here. >>> I must admit I'm not sure what device-mapper will do with a target >>> definition which is larger than the resulting target device ... >>> Mike should know, but it's definitely awkward. >> >> AHh. OK. Never thought of it like this, especially considering the fact that the >> table entry is checked to see if the entire drive is given. So instead of the >> target size, I was in fact using the size parameter of dmsetup as the size to >> use on the backend, which for dm-zoned must be the device capacity... >> >> Not sure if we can fix that now ? Especially considering that the number of >> reserved seq zones for reclaim is not constant but a dmzadm format option. So >> the average user would have to know exactly the useable size to dmsetup the >> target. Akward too, or rather, not super easy to use. I wonder how dm-thin or >> other targets with metadata handle this ? Do they format themselves >> automatically on dmsetup using the size specified ? >> > Which is _precisely_ why I want to have the 'start' option to dmzadm. > That can read the metadata, validate it, and then generate the correct > invocation for device-mapper. > _And_ we get a device-uuid to boot, as this can only be set from the ioctl. OK. Got it. Done like this, it will also be easy to support the v1 metadata. > > Cheers, > > Hannes > -- Damien Le Moal Western Digital Research -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
