Florian Forster writes ("Re: Bug#588153: collectd disk plugin needs indirection 
ability"):
> if I understand you correctly, you would like to have a new way to
> specify which information to collect. Rather than simply reading
> /proc/diskstats and working with what's there, you would like to specify
> a list of "interesting" device paths, for example the path to an LVM
> volume. The plugin should then look up the major and minor number of
> that device (may be a symbolic link to a device file, too) and look for
> the correct line in /proc/diskstats using that information.
> 
> Did I get that correctly?

Thanks for your quick response.

Yes, that was my suggestion, because it would be (I thought) fairly
straightforward to implement.

The alternative would be to have the collectd disk plugin somehow try
to find a stable identifier for each disk which it's monitoring, and
record the data under that stable identifier.  Consumers of the data
would then have to find out these identifiers for whatever devices
they think are relevant.

I guess you could try to use /dev/disk/by-id for this, but entries
there aren't unique (that is, a single block device may have multiple
symlinks in /dev/disk/by-id) - although you could just decree the use
of the lexically first.  And of course it doesn't work on systems
without udev.


I'm not sure I entirely agree with the classification of this bug as
"wishlist"; I think the current behaviour is fundamentally wrong on
many modern systems.  For example, on chiark's current hardware, there
are three SCSI disks /dev/sd[abc]: two SATA hard disks and one USB
stick.  The USB stick shows up as sda or sdb or sdc apparently at
random, ie it has a different name each boot.  Nevertheless collectd
indexes its data by the device name, so that data from the USB stick
on one boot ends up in the same RRD as data from a SATA disk in the
next.

Likewise, collectd effectively uses the minor numbers of lvm devices
as the index, since it uses the "dm-<number>" name for the name of the
RRD.  But lvm device minor numbers - devmapper minor numbers - are not
stable at all.  Any LV which is deactivated will get whatever minor
number is free whenever it is next activated.

So I think the current behaviour is wrong in many if not most system
setups, and in those setups there is no way to configure collectd's
disk plugin to collects the correct data, since it insists on using
the raw device name and only the raw device name.

But of course that's not saying that I'm demanding that you put in the
effort fix the bug :-).  If it bothers me enough I can always research
the code and write a patch myself.

Thanks,
Ian.



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to