On Fri, Nov 08, 2013 at 06:39:22AM -0500, Joe Thornber wrote:
> 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.
The use case I was concerned about is setting the initial era counter value
during cache creation. In this case no status request is possible. However
after more thought, this is not an issue (since the set_era_counter is
processed before the era counter value is recovered from the metadata), so
agreed, the old value should be required.