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....@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...)
>>
> 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 ?

> 
> Cheers,
> 
> Hannes
> 


-- 
Damien Le Moal
Western Digital Research



--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel

Reply via email to