pcp
[Top] [All Lists]

Re: [pcp] pcp updates: add disk.dm.* device-mapper metrics

To: Mark Goodwin <goodwinos@xxxxxxxxx>
Subject: Re: [pcp] pcp updates: add disk.dm.* device-mapper metrics
From: Nathan Scott <nathans@xxxxxxxxxx>
Date: Mon, 14 Jul 2014 23:41:17 -0400 (EDT)
Cc: pcp@xxxxxxxxxxx, Mark Goodwin <mgoodwin@xxxxxxxxxx>
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <53C49FB0.3000101@xxxxxxxxx>
References: <53C4898A.4020908@xxxxxxxxxx> <254822503.10153921.1405392442746.JavaMail.zimbra@xxxxxxxxxx> <53C49FB0.3000101@xxxxxxxxx>
Reply-to: Nathan Scott <nathans@xxxxxxxxxx>
Thread-index: tHgiXJcYvtC4G3mn8WmPu+GfEj9IpQ==
Thread-topic: pcp updates: add disk.dm.* device-mapper metrics

----- Original Message -----
> [...]
> Wont work (or I am confused). dm-N gets reused if it is deleted and
> then a new volume is created (with or without a reboot). Here's an
> example using snapshots:

Yep, understood - sorry, wasn't clear - I'm not proposing this as a "fix",
and agree your solution is the right thing to do.  I was trying to find a
way to make the existing indom (which we still need for hinv.map.lvname)
behave a bit more predictably.

So, even though the numbers recycle (even moreso than I thought, from your
example) - anyone interpreting the old indom could still get a little more
expected behaviour, with the internal and external IDs actually matching.
At the moment, the internal ID is just an internal array index with value
depending on readdir() order ... *shrug* ... maybe its not worth the effort
but it might save some end-user confusion.

cheers.

--
Nathan

<Prev in Thread] Current Thread [Next in Thread>