[Pkg-xfce-devel] Bug#319684: closed by Simon Huggins <huggie at earth.li> (Re: Bug#319684: Bug#319684: xfce4-diskperf-plugin: X4DP runs but never sees any traffic on busy disk)

A. Costa agcosta at gis.net
Sun Jun 3 02:55:03 UTC 2007


On Tue, 22 May 2007 10:24:21 +0000
owner at bugs.debian.org (Debian Bug Tracking System) wrote:

> On Sun, Jul 24, 2005 at 09:48:12AM +0200, Yves-Alexis Perez wrote:
> > Here, the plugin is pretty long to show anything. Can you try a
> > long dd in order to check if the plugin isnt working at all.
> 
> However it has worked for us and we've had no followup so I'm closing
> this bug.
> 
> Do reopen this if it's closed in error.

Sorry for the late reply; I notice in 7/05 Y-A. Perez replied to my
post, but he didn't 'cc:' me so I never saw his reply. :-(

I've just tested the diskperf plugin, while comparing it to a 'gkrellm'
graph of the same disk.  I had to thrash the drive as root to make it
obvious that diskperf worked:

	% cat /dev/hda3 > /dev/null

...but for ordinary activity the diskperf color bar is often small and
briefly displayed, so it's easy to miss.

Set to 'Properties>Monitor>busy time' is much easier to spot.
It's the 'i/o' mode that's easy to miss.

I'm not certain that I just missed the activity in 2005 when I reported
this bug, or whether the code itself has changed; yet lets assume I
missed it... 

Closing the bug seems appropriate, as phrased, "X4DP runs but never
sees any traffic on busy disk".  Certainly today it sees traffic.  But,
the close is less certain if the problem is a misdiagnosis of what
might better be named "X4DP shows most i/o traffic too quick or small to
see".

I wonder if logarithmic scale, (small stuff looks bigger), or a
persistence of vision option might help, where one could set in
milliseconds how long the color of the most recent instance of activity
should last.  

Another issue might be that the graph height as set by
'Properties>Monitor>max i/o' -- if that's too high, busy activity seems
to vanish.  For example, in an 'ext3' file system an uncached
invocation of 'ls -l /usr/share/doc' tends to be quite slow, as the OS
has to fetch all these widely scattered inodes -- the disk will be
very busy doing head seeks, yet the data transfer will be a few hundred
K at most, which would be invisible on the 'i/o' graph, unless the max
was set very low.





More information about the Pkg-xfce-devel mailing list