[dm-devel] [RFC PATCH] dm-zoned: extend the way of exposing zoned block device

[Damien Le Moal]

On 2020/01/08 22:49, Bob Liu wrote:
> On 1/8/20 3:40 PM, Damien Le Moal wrote:
>> On 2020/01/08 16:13, Nobody wrote:
>>> From: Bob Liu <bob.liu at oracle.com>
>>>
>>> Motivation:
>>> Now the dm-zoned device mapper target exposes a zoned block device(ZBC) as a
>>> regular block device by storing metadata and buffering random writes in
>>> conventional zones.
>>> This way is not very flexible, there must be enough conventional zones and the
>>> performance may be constrained.
>>> By putting metadata(also buffering random writes) in separated device we can get
>>> more flexibility and potential performance improvement e.g by storing metadata
>>> in faster device like persistent memory.
>>>
>>> This patch try to split the metadata of dm-zoned to an extra block
>>> device instead of zoned block device itself.
>>> (Buffering random writes also in the todo list.)
>>>
>>> Patch is at the very early stage, just want to receive some feedback about
>>> this extension.
>>> Another option is to create an new md-zoned device with separated metadata
>>> device based on md framework.
>>
>> For metadata only, it should not be hard at all to move to another
>> conventional zone device. It will however be a little more tricky for
>> conventional zones used for data since dm-zoned assumes that this random
>> write space is also zoned. Moving this space to a conventional device
>> requires implementing a zone emulation (fake zones) for the regular
>> drive, using a zone size that matches the size of sequential zones.
>>
> 
> Indeed.
> I'll try to implement zone emulation next version.
> 
>> Beyond this, dm-zoned also needs to be changed to accept partial drives
>> and the dm core code to accept mixing of regular and zoned disks (that
>> is forbidden now).
>>
> 
> Do you mean the check in device_area_is_invalid()? 
> 
>  320         /*
>  321          * If the target is mapped to zoned block device(s), check
>  322          * that the zones are not partially mapped.
>  323          */
>  324         if (bdev_zoned_model(bdev) != BLK_ZONED_NONE) {

This is only to check that the mapping are zone aligned for zoned block
devices. I was referring to the checks done using the
device_is_zoned_model() callback in dm_table_supports_zoned_model()
which restricts mappings to be *all* on top of zoned disks for targets
that have the DM_TARGET_ZONED_HM feature set. That code will prevent
using a regular SSD and an SMR disk for dm-zoned. A new feature (e.g.
DM_TARGET_MIXED_ZONED_HM or something) will be needed.

Best regards.


-- 
Damien Le Moal
Western Digital Research