multiload_applet harddisk functionality broken/not documented enough

[AmenophisIII]

Binary package hint: gnome-applets

i added the harddisk monitor thingy and it stays black and shows "0% in use" althouth my first hd is under heavy load. (i have two disks connected atm, /dev/sda and /dev/sdb)
i guess it does not work with device mapper: i have lvm over dm-crypt. but it should be able to detect disk usage anyway... but since neither manpage nor gnome docu say exactly what it should do, i can't comment further.
can you elaborate what it should exactly monitor please?

btw the multiload_applet manpage does not mention the harddisk monitor at all.

im using ubuntu 8.10 amd64 and gnome-applets 2.24.1-0ubuntu1

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[AmenophisIII (amenophisiii)]

im not sure about that.
i dont understand your comment in the other report fully.
regarding https://bugs.launchpad.net/ubuntu/+source/gnome-applets/+bug/275604/comments/9 you said:

"the read stat seems to not be updated which suggests that's not an applet bug"
which field(s) do you mean?
the "merge" fields 2 and 6 seem to be ok at 0 (i guess they dont get merged before issued to physical disks?).
9 (current i/os) is ok too.
agreed?

4 and the rest at the end are bogus, i agree.
but... mine arent 0 :) (except 2, 6 and 9) and get updated e.g.:

 254 0 dm-0 5565862 0 747547424 38254648 85392788 0 683142304 4076472404 0 17259000 4114740636
5mins later (low load)
 254 0 dm-0 5567422 0 747646320 38269368 85393184 0 683145472 4076473516 0 17270840 4114756468

and beside that, it should really be documented WHAT is meassured. at least tell me pls :)
i still dont know.. which field? and which lines get checked? sdX get updated even if they are raided/lvmed/crypted. but if the applet would look at sdX/hdY only, there wouldnt be a problem to begin with(?)
are only mounted drives watched, only the one with / etc.
thanks

[Sebastien Bacher (seb128)]

the issue is not exactly clear, somebody having the configuration to trigger the bug should open a bug on bugzilla.gnome.org where the people writting the code will read it, it's not likely a bug triager on launchpad will debug this one otherwise without having a configuration which has the issue