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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
