[dm-devel] [PATCH 1/2] dm-zoned: cache device for zones

[Bob Liu]

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 at suse.de>
>> ---
>>  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 ?
>