From: Joe Thornber <thornber@redhat.com>
To: device-mapper development <dm-devel@redhat.com>
Subject: Re: [PATCH] Add a set_era_counter config key to the dm-cache era policy shim
Date: Fri, 8 Nov 2013 11:38:46 +0000 [thread overview]
Message-ID: <20131108113845.GA1894@debian> (raw)
In-Reply-To: <33A0129EBFD46748804DE81B354CA1B21C02AFF2@SACEXCMBX06-PRD.hq.netapp.com>
On Thu, Nov 07, 2013 at 09:24:44PM +0000, Mears, Morgan wrote:
> On Thurs, Nov 07, 2013 at 03:51PM +0000, Joe Thornber wrote:
> > On Wed, Nov 06, 2013 at 08:59:38PM +0000, Mears, Morgan wrote:
> > > Add the ability to set the era counter maintained by the dm-cache era
> > > policy shim to an arbitrary 32-bit value, to allow era rollback after
> > > the underlying device is restored from a snapshot.
> >
> > I wonder if we should pass in the old value, and have the call fail if the old
> > value is incorrect. This would allow applications to spot if they were
> > competing to set the era. Some thing like:
> >
> > set_era_counter <old value>:<new value>
>
> Yes, I like this. My inclination is to make the <old value>: portion optional so that the counter value can be forced if desired (for example, to set it to a saved value during a create); objections?
In this case userspace should make a status request to get the current
era, then send the message in the <old value>:<new value> format. If
it fails then clearly another process is interfering and you have big
issues.
> > In general alarm bells ring if you use one of smp_*() without the other. See
> > linux/Documentation/memory-barriers.txt for lots of discussion.
>
> Thanks Joe, will fix.
Already done in my cache-coherency-changes branch. I've changed the
current_era counter to be an atomic64_t.
- Joe
next prev parent reply other threads:[~2013-11-08 11:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-06 20:59 [PATCH] Add a set_era_counter config key to the dm-cache era policy shim Mears, Morgan
2013-11-07 15:51 ` Joe Thornber
2013-11-07 21:24 ` Mears, Morgan
2013-11-08 11:38 ` Joe Thornber [this message]
2013-11-08 15:00 ` Mears, Morgan
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=20131108113845.GA1894@debian \
--to=thornber@redhat.com \
--cc=dm-devel@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.