From: Mike Snitzer <snitzer@redhat.com>
To: Hannes Reinecke <hare@suse.de>
Cc: Damien LeMoal <damien.lemoal@wdc.com>,
Johannes Thumshirn <jth@kernel.org>,
dm-devel@redhat.com
Subject: Re: [PATCH RFC 0/2] dm-zoned: add cache device
Date: Mon, 23 Mar 2020 11:39:44 -0400 [thread overview]
Message-ID: <20200323153944.GA27615@redhat.com> (raw)
In-Reply-To: <69ce4dd2-81d3-0ac6-933b-a1f781836597@suse.de>
On Mon, Mar 23 2020 at 11:26am -0400,
Hannes Reinecke <hare@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@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.
next prev parent reply other threads:[~2020-03-23 15:39 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-23 15:03 [PATCH RFC 0/2] dm-zoned: add cache device Hannes Reinecke
2020-03-23 15:03 ` [PATCH 1/2] dm-zoned: cache device for zones Hannes Reinecke
2020-03-24 3:52 ` Damien Le Moal
2020-03-24 4:22 ` Bob Liu
2020-03-24 7:51 ` Hannes Reinecke
2020-03-24 9:03 ` Damien Le Moal
2020-03-23 15:03 ` [PATCH 2/2] dm-zoned: add 'status' and 'message' callbacks Hannes Reinecke
2020-03-24 3:54 ` Damien Le Moal
2020-03-24 3:59 ` Mike Snitzer
2020-03-24 4:01 ` Damien Le Moal
2020-03-23 15:15 ` [PATCH RFC 0/2] dm-zoned: add cache device Mike Snitzer
2020-03-23 15:26 ` Hannes Reinecke
2020-03-23 15:39 ` Mike Snitzer [this message]
2020-03-23 16:10 ` Hannes Reinecke
2020-03-23 16:52 ` Mike Snitzer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200323153944.GA27615@redhat.com \
--to=snitzer@redhat.com \
--cc=damien.lemoal@wdc.com \
--cc=dm-devel@redhat.com \
--cc=hare@suse.de \
--cc=jth@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.