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. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
