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

[Damien Le Moal]

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