On 3/23/20 4:39 PM, Mike Snitzer wrote:
On Mon, Mar 23 2020 at 11:26am -0400,
Hannes Reinecke <hare@xxxxxxx> wrote:
On 3/23/20 4:15 PM, Mike Snitzer wrote:
On Mon, Mar 23 2020 at 11:03am -0400,
Hannes Reinecke <hare@xxxxxxx> 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@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
