From: Mike Snitzer <snitzer@redhat.com>
To: Johannes Bauer <dfnsonfsduifb@gmx.de>
Cc: dm-devel@redhat.com, thornber@redhat.com
Subject: Re: dm-cache coherence issue
Date: Mon, 26 Jun 2017 15:56:17 -0400 [thread overview]
Message-ID: <20170626195617.GA599@redhat.com> (raw)
In-Reply-To: <745c64ba-a5ec-363b-bc6f-2abd0d242b38@gmx.de>
On Mon, Jun 26 2017 at 3:08pm -0400,
Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
> Hi Joe,
>
> On 26.06.2017 17:58, Joe Thornber wrote:
> > On Mon, Jun 26, 2017 at 12:33:42PM +0100, Joe Thornber wrote:
> >> On Sat, Jun 24, 2017 at 03:56:54PM +0200, Johannes Bauer wrote:
> >>> So I seem to have a very basic misunderstanding of what the cleaner
> >>> policy/dirty pages mean. Is there a way to force the cache to flush
> >>> entirely? Apparently, "dmsetup wait" and/or "sync" don't do the job.
> >>
> >> I'll try and reproduce your scenario and get back to you.
> >
> > Here's a similar scenario that I've added to the dm test suite:
> >
> > https://github.com/jthornber/device-mapper-test-suite/commit/457e889b0c4d510609c0d7464af07f2ebee20768
> >
> > It goes through all the steps you need to use to decommission a cache
> > with dirty blocks. Namely:
> >
> > - switch to writethrough mode (so new io can't create new dirty blocks)
> > - switch to the cleaner policy
> > - wait for clean
> > - remove the cache device before accessing the origin directly
>
> Interesting, I did *not* change to writethrough. However, there
> shouldn't have been any I/O on the device (it was not accessed by
> anything after I switched to the cleaner policy).
>
> On the advice of Zdenek Kabelac, who messaged me off-list, I therefore
> have indeed been convinced that using dm-cache "by hand" maybe is too
> dangerous (i.e., I had not accounted for "repairing" of a cache and am
> really still unsure what LVM does that) and that lvmcache is a better
> choice -- even though Ubuntu supports it really crappily for root devices:
> https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1423796 a shame,
> it's been like this for over two years.
>
> Anyways, I'll try to replicate my scenario again because I'm actually
> quite sure that I did everything correctly (I did it a few times).
Except you didn't first switch to writethrough -- which is _not_
correct.
next prev parent reply other threads:[~2017-06-26 19:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-24 13:56 dm-cache coherence issue Johannes Bauer
2017-06-24 18:21 ` Johannes Bauer
2017-06-26 11:33 ` Joe Thornber
2017-06-26 15:58 ` Joe Thornber
2017-06-26 19:08 ` Johannes Bauer
2017-06-26 19:56 ` Mike Snitzer [this message]
2017-06-26 20:36 ` Johannes Bauer
2017-06-26 21:34 ` Mike Snitzer
2017-06-27 9:44 ` Joe Thornber
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=20170626195617.GA599@redhat.com \
--to=snitzer@redhat.com \
--cc=dfnsonfsduifb@gmx.de \
--cc=dm-devel@redhat.com \
--cc=thornber@redhat.com \
/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.