[dm-devel] [PATCH RFC 0/2] dm-zoned: add cache device

[Hannes Reinecke]

On 3/23/20 4:39 PM, Mike Snitzer wrote:
> On Mon, Mar 23 2020 at 11:26am -0400,
> Hannes Reinecke <hare at suse.de> wrote:
> 
>> On 3/23/20 4:15 PM, Mike Snitzer wrote:
>>> On Mon, Mar 23 2020 at 11:03am -0400,
>>> Hannes Reinecke <hare at suse.de> wrote:
>>>
>>>> Hi Damien,
>>>>
>>>> as my original plan to upgrade bcache to work for SMR devices
>>>> turned out to be more complex than anticipated I went for the
>>>> simpler approach and added a 'cache' device for dm-zoned.
>>>> It is using a normal device (eg '/dev/pmem0' :-), split it
>>>> into zones of the same size of the original SMR device, and
>>>> makes those 'virtual' zones avialable to dm-zoned in a similar
>>>> manner than the existing 'random write' zoned.
>>>>
>>>> The implementation is still a bit rough (one would need to add
>>>> metadata to the cache device, too), but so far it seems to work
>>>> quite well; still running after copying 300GB of data back and forth.
>>>>
>>>> As usual, comments and reviews are welcome.
>>>
>>> Not seeing why this needs to be so specialized (natively implemented in
>>> dm-zoned).  Did you try stacking dm-writecache on dm-zoned?
>>>
>> dm-zoned is using the random-write zones internally to stage writes
>> to the sequential zones, so in effect it already has an internal
>> caching.
>> All this patch does is to use a different device for the already present
>> mechanism.
>> Using dm-writecache would be ignorant of that mechanism, leading to
>> double caching and detrimental results.
> 
> If dm-writecache were effective at submitting larger IO then dm-zoned
> shouldn't be resorting to caching in random-write zones at all -- that
> is a big if, so not saying it'll "just work".  But if both layers are
> working then it should.
> 
Well, by the looks of it dm-writecache suffers from the same problem 
bcache has; it allows for blocks up to 64k sectors to be submitted.
Sadly for SMR drives I would need to submit block of 256M...
But before discussing any further I'll give it a go and see where I end up.

Cheers,

Hannes
-- 
Dr. Hannes Reinecke            Teamlead Storage & Networking
hare at suse.de                               +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer