Hi Mark,
With Daves quick fixes, looks like tomorrow is still good for 3.9.7
- so I've cherry-picked the Makepkgs fix, & reckon the device mapper
changes (and RHEL5 fix & QA) are good 3.9.8 material - does that all
sound OK? I'll have some dmcache code too by then, so we can have a
release theme. :)
----- Original Message -----
> Also, re: RH BZ https://bugzilla.redhat.com/show_bug.cgi?id=1109539
> ("hinv.map.lvname instance IDs are not persistent"). I think the
> fix is to use the persistent dm name as the instance domain, with
> the metric value being the current dm-[0-9]* name (the current
> implementation has it the other way around). Since I've now done
> this with the new hinv.map.dmname metric, can hinv.map.lvname be
> deprecated? Or will we just keep it? Anything depend on it?
Yep, Stan's making use of it in pmatop so the existing indom will need
to be maintained. And also improved, if you could - from your commit
log description, a separate instance domain ID for your new code will
be needed (you probably did that already) but since the old names are
"dm-N" (where N is just an int), the internal instance ID could simply
be made to match "N", for more persistent naming right? This wouldn't
survive a reboot, but it'd at least persist through addition/removal
of new/old DM devices during the lifetime of pmcd. IOW, no pmdaCache*
use needed here - should be a simple extension to the way the indom is
updated now (same pmdaIndom data structure, just pushing that N into
the internal ID via it_set->i_inst ... thoughts?).
thanks!
--
Nathan
|