From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Snitzer Subject: Re: [PATCH RFC 0/2] dm-zoned: add cache device Date: Mon, 23 Mar 2020 11:39:44 -0400 Message-ID: <20200323153944.GA27615@redhat.com> References: <20200323150352.107826-1-hare@suse.de> <20200323151538.GA27573@redhat.com> <69ce4dd2-81d3-0ac6-933b-a1f781836597@suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <69ce4dd2-81d3-0ac6-933b-a1f781836597@suse.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com Content-Disposition: inline To: Hannes Reinecke Cc: Damien LeMoal , Johannes Thumshirn , dm-devel@redhat.com List-Id: dm-devel.ids On Mon, Mar 23 2020 at 11:26am -0400, Hannes Reinecke wrote: > On 3/23/20 4:15 PM, Mike Snitzer wrote: > >On Mon, Mar 23 2020 at 11:03am -0400, > >Hannes Reinecke 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.