[collectd] Re: RESUBMIT: Patch: collectd 3.0.0 hddtemp support

[Florian Forster]

Hi,

On Mon, Oct 10, 2005 at 10:08:27PM +0200, Vincent Stehlé wrote:
> I just finished to merge 2.1.0-vs and 3.0.0 this week-end, and now
> 3.0.0-vs w/hddtemp support is ok, if I got your read/submit/write
> system correctly.

I'll have a closer look tomorrow (or maybe tonight, but I'm usually not
very motivated to do programming stuff when I come home from work ;) and
release a version with this patch as soon as possible ;) Thanks again
for your work :)

> I did not update the manpage, but would like to. How do you generate
> it, please?

I generate it from a POD file which isn't in the distribution since I
think a dependency on pod2man is unneccessary. You get all the
`development' stuff (which isn't much more than that POD and a TODO
file, iIrc) from the svn:
https://faui2k3.org/svn/octo/projects/collectd3

> Also, I think your multicast evolution is a good idea, but will come
> with its problems. For example, with hddtemp, let's say we have
> machine A and B submitting stats to machine C. They both have a
> /dev/hda.  Machine C will try to write statistic to
> hddtemp-%dev%hda.rrd twice :/

When running in multicast-server-mode the RRDs are created under
`/var/lib/collectd/<hostname>/', where `<hostname>' is the reverse-
lookup of the sending IP. So there shouldn't be any collisions, (as long
as maschines behind load balancers use their management-IP, but that
should be obvious)..

> What do you think? Shall we include the sender host name in the rrd
> filename, like hddtemp-A-%dev%hda.rrd?

The approach using directories has shown to be superior: We (here at
work) had one RRD file for each AS (autonomous system). Having 65k files
in one directory, which is mounted over NFS to top it all off, is no joy
;)

Best regards,
-octo

P.S.: I installed new harddrives in the maschine running verplant.org
and re-installed the OS in the process. That's why the mailinglist was
down. It should be up and working again. I've sent a CC to the ML and
we'll see if I did a reasonable job ;)
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20051011/3ab6e73b/attachment.pgp