On 3/24/20 11:52 AM, Damien Le Moal wrote:
> +Bob who had proposed a similar change a last month.
>
Thanks!
> On 2020/03/24 0:04, Hannes Reinecke wrote:
>> Implement 'cache' zones which reside on a different device.
>> The device is logically split into zones, which then will be
>> used as 'cache' zones, similar to the existing randow write
>> zones.
>
> It does look like the new "cahce" zones are really used exactly as conventional
> zones of the SMR drive. So I wonder: why even define this new zone type ? We
> could have the "cache" device split into random (conventional) zones added to a
> single pool of random zones. We can simply add device awareness to the zone
> allocator to avoid as much as possible using a random zone from the same drive
> as the sequential zone it buffers. That would avoid repeating most of the code
> for cache & random.
>
> Furthermore, this work is really great to support SMR drives with no
> conventional zones (a lot of ask for these). And considering that the new FORMAT
> WITH PRESET command is coming soon, a user will be able to reformat an SMR drive
> with sequential zones only to maximize capacity. For these, the cache device
> would need to hold the random zones, at which point the difference between cache
> and rando goes away.
>
>>
>> Signed-off-by: Hannes Reinecke <hare@xxxxxxx>
>> ---
>> drivers/md/dm-zoned-metadata.c | 174 ++++++++++++++++++++++++++++-----
>> drivers/md/dm-zoned-reclaim.c | 76 +++++++++++---
>> drivers/md/dm-zoned-target.c | 109 ++++++++++++++++++---
>> drivers/md/dm-zoned.h | 31 +++++-
>> 4 files changed, 339 insertions(+), 51 deletions(-)
>>
>> diff --git a/drivers/md/dm-zoned-metadata.c b/drivers/md/dm-zoned-metadata.c
>> index 369de15c4e80..41cc3a29db0b 100644
>> --- a/drivers/md/dm-zoned-metadata.c
>> +++ b/drivers/md/dm-zoned-metadata.c
>> @@ -132,6 +132,8 @@ struct dmz_sb {
>> struct dmz_metadata {
>> struct dmz_dev *dev;
>>
>> + struct dmz_cdev *cdev;
>
> Given the point above, we could have this generalized as an array of devices,
> with the first one meeting the constraints:
> * It contains the metadata
> * It has random/conventional zones, or is a regular device (with all its
> capacity used through emulated random zones)
>
Yes, I was working my v2 patches as this.
Will send out this week.
Regards,
Bob
> I do not think that complicates the changes you did a lot. The reclaim part will
> need some more love I guess to be efficient, but it may be as simple as defining
> one work struct for each drive beside the first one.
>
> Thoughts ?
>
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
