On 2020/05/11 18:19, Hannes Reinecke wrote:
> On 5/11/20 10:51 AM, Damien Le Moal wrote:
>> On 2020/05/11 17:46, Hannes Reinecke wrote:
>>> On 5/11/20 10:36 AM, Damien Le Moal wrote:
>>>> On 2020/05/11 17:24, Hannes Reinecke wrote:
>>>>> Implement handling for metadata version 2. The new metadata adds
>>>>> a label and UUID for the device mapper device, and additional UUID
>>>>> for the underlying block devices.
>>>>> It also allows for an additional regular drive to be used for
>>>>> emulating random access zones. The emulated zones will be placed
>>>>> logically in front of the zones from the zoned block device, causing
>>>>> the superblocks and metadata to be stored on that device.
>>>>> The first zone of the original zoned device will be used to hold
>>>>> another, tertiary copy of the metadata; this copy carries a
>>>>> generation number of 0 and is never updated; it's just used
>>>>> for identification.
>>>>>
>>>>> Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
>>>>> Reviewed-by: Bob Liu <bob.liu@xxxxxxxxxx>
>>>>> Reviewed-by: Damien Le Moal <damien.lemoal@xxxxxxx>
>>>>
>>>> Forgot to read through the documentation update. A couple of comments added below.
>>>>
>>>>> ---
>>>>> .../admin-guide/device-mapper/dm-zoned.rst | 34 ++-
>>>>> drivers/md/dm-zoned-metadata.c | 310 +++++++++++++++++----
>>>>> drivers/md/dm-zoned-target.c | 185 ++++++++----
>>>>> drivers/md/dm-zoned.h | 7 +-
>>>>> 4 files changed, 427 insertions(+), 109 deletions(-)
>>>>>
>>>>> diff --git a/Documentation/admin-guide/device-mapper/dm-zoned.rst b/Documentation/admin-guide/device-mapper/dm-zoned.rst
>>>>> index 7547ce635161..553752ea2521 100644
>>>>> --- a/Documentation/admin-guide/device-mapper/dm-zoned.rst
>>>>> +++ b/Documentation/admin-guide/device-mapper/dm-zoned.rst
>>>>> @@ -37,9 +37,13 @@ Algorithm
>>>>> dm-zoned implements an on-disk buffering scheme to handle non-sequential
>>>>> write accesses to the sequential zones of a zoned block device.
>>>>> Conventional zones are used for caching as well as for storing internal
>>>>> -metadata.
>>>>> +metadata. It can also use a regular block device together with the zoned
>>>>> +block device; in that case the regular block device will be split logically
>>>>> +in zones with the same size as the zoned block device. These zones will be
>>>>> +placed in front of the zones from the zoned block device and will be handled
>>>>> +just like conventional zones.
>>>>>
>>>>> -The zones of the device are separated into 2 types:
>>>>> +The zones of the device(s) are separated into 2 types:
>>>>>
>>>>> 1) Metadata zones: these are conventional zones used to store metadata.
>>>>> Metadata zones are not reported as useable capacity to the user.
>>>>> @@ -127,6 +131,13 @@ resumed. Flushing metadata thus only temporarily delays write and
>>>>> discard requests. Read requests can be processed concurrently while
>>>>> metadata flush is being executed.
>>>>>
>>>>> +If a regular device is used in conjunction with the zoned block device,
>>>>> +a third set of metadata (without the zone bitmaps) is written to the
>>>>> +start of the zoned block device. This metadata has a generation counter of
>>>>> +'0' and will never be updated during normal operation; it just serves for
>>>>> +identification purposes. The first and second copy of the metadata
>>>>> +are located at the start of the regular block device.
>>>>> +
>>>>> Usage
>>>>> =====
>>>>>
>>>>> @@ -138,12 +149,21 @@ Ex::
>>>>>
>>>>> dmzadm --format /dev/sdxx
>>>>>
>>>>> -For a formatted device, the target can be created normally with the
>>>>> -dmsetup utility. The only parameter that dm-zoned requires is the
>>>>> -underlying zoned block device name. Ex::
>>>>>
>>>>> - echo "0 `blockdev --getsize ${dev}` zoned ${dev}" | \
>>>>> - dmsetup create dmz-`basename ${dev}`
>>>>> +If two drives are to be used, both devices must be specified, with the
>>>>> +regular block device as the first device.
>>>>
>>>> Actually, the zoned block device must be first. Otherwise dmzadm complains. We
>>>> can change that, or change the doc. Which do you prefer ? No strong opinion here.
>>>>
>>> Nope, not any more. Fixed it in my local repo (which I haven't pushed,
>>> sorry).
>>>
>>> But after the last discussion we had I thought it better and more
>>> consistent to have the regular device first, just like the device-mapper
>>> interface.
>>
>> Works for me !
>>
>
> I do hope so :-)
> I've spun a new version against the master branch.
>
>>>
>>>>> +
>>>>> +Ex::
>>>>> +
>>>>> + dmzadm --format /dev/sdxx /dev/sdyy
>>>>> +
>>>>> +
>>>>> +Fomatted device(s) can be started with the dmzadm utility, too.:
>>>>> +
>>>>> +Ex::
>>>>> +
>>>>> + dmzadm --start /dev/sdxx /dev/sdyy
>>>>
>>>> And same here, the zoned device must come first. I added a patch that internally
>>>> reverse that order for the dm start operation so that the regular device is
>>>> specified first.
>>>>
>>> See above. I've fixed up dmzadm for this.
>>>
>>> I just hadn't pushed the patch as I wanted to get the kernel bits
>>> settled. But now that we have I'll be pushing the dm-zoned-tools updates.
>>
>> Please send changes on top of the "staging" branch. Your first batch of changes
>> is already merged in that branch.
>>
> Rah. Send a new merge request for 'master'; will be doing an update to
> the 'staging' branch, too.
Don't bother, will respin the staging branch with the new PR.
>
> Cheers,
>
> Hannes
>
--
Damien Le Moal
Western Digital Research
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
