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@xxxxxxxxxx>
>>>
>>> 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
