[linux-lvm] [PATCH 4/2] fs snapshot plugin: add LVM tag to allow tools to link pre and post snapshots

[Mike Snitzer]

On Tue, Mar 12 2013 at 12:41pm -0400,
James Antill <james at fedoraproject.org> wrote:

> On Tue, 2013-03-12 at 10:41 -0400, Mike Snitzer wrote:
> > On Tue, Mar 12 2013 at  9:46am -0400,
> > James Antill <james at fedoraproject.org> wrote:
> > 
> > > On Mon, 2013-03-11 at 17:25 -0400, Mike Snitzer wrote:
> > > > Add a "yum_fs_snapshot_<trans_id>_<origin_volume>" LVM tag to LVM-based
> > > > snapshots (old or thinp).  These tags will allow tools (e.g snapper) to
> > > > link the pre and post snapshot volumes together.
> > > > 
> > > > yum_fs_snapshot_trans_id() uses the first 16 digits of the hash() of the
> > > > rpm TransactionSet instance to establish a unique id that is common to
> > > > both the pretrans_hook() and posttrans_hook() -- this is quite the hack;
> > > > I'm open to using other (more future-proof) methods.
> > > 
> > >  Esp. as hash(ts.ts) is just the address of the pointer for that object
> > > in C.
> > >  It depends what you want, I guess.
> > 
> > I couldn't figure out how to store anything in pretrans_hook() and
> > retrieve it in posttrans_hook().  Use of a global caused the plugin to
> > fail silently.
> 
>  Using globals should work, the only real problem is if some python API
> creates multiple YumBase() instances (but although we've worried about
> that, nothing has ever really done it AFAIK).

Just adding a single global caused the plugin to fail: global foo = None

>  The common way is to just stuff something unique in the yum base object
> (base.__plugin_fssnap_whatever = blah).

OK.

> > I like the idea of using the actual future rpmDB version; but as you
> > note it won't be unique on its own if you undo a transaction.  SO this
> > is the incremental change I came up with.  I'll post v2 of the 4/2 patch
> > with these chnages folded in:
> [...] 
> > -def yum_fs_snapshot_trans_id(ts):
> > +def yum_fs_snapshot_trans_id(conduit):
> >      # return pseudo yum transaction id string
> >      # this string is identical for both {pre,post}trans_hook
> > -    yum_ts_hash = "%d" % abs(hash(ts.ts))
> > -    return "yum_fs_snapshot_" + yum_ts_hash[:16]
> > +    tsInfo = conduit.getTsInfo()
> > +    # using hash of tsInfo purely to get unique number that isn't tied to rpmDB
> > +    tsInfo_hash = "%d" % (abs(hash(tsInfo)))
> > +    frpmdbv = tsInfo.futureRpmDBVersion()
> > +    return "yum_fs_snapshot_%s_%s" % (tsInfo_hash[:8], frpmdbv)
> 
>  I still worry about how unique "abs(hash(ts.ts))" will be over multiple
> runs ... is the reason for not using a timestamp just that you don't
> know where to store it?

abs(hash(tsInfo)) should be sufficiently unique when coupled with
futureRpmDBVersion().  But yeah, I didn't know how to store the timestamp.

I'll send a simpler v3 now.. thanks for your help!