After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 788923 - Disk read / Disk write are backwards in the Processes page
Disk read / Disk write are backwards in the Processes page
Status: RESOLVED FIXED
Product: system-monitor
Classification: Core
Component: process list
3.26.x
Other Linux
: Normal normal
: ---
Assigned To: System-monitor maintainers
System-monitor maintainers
: 792517 794954 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2017-10-13 09:34 UTC by Daniel van Vugt
Modified: 2018-04-04 05:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Disk writes in system-monitor and iotop (128.04 KB, image/png)
2017-10-25 18:03 UTC, joshas
  Details
Screenshot comparing iotop and gnome system monitor (40.77 KB, image/png)
2017-11-12 23:43 UTC, mark.z.harrison
  Details
Fix #780644 (3.03 KB, patch)
2017-12-15 15:48 UTC, Shiv Dhar
none Details | Review
Fix bgo#780644 (3.03 KB, patch)
2017-12-15 15:50 UTC, Shiv Dhar
committed Details | Review

Description Daniel van Vugt 2017-10-13 09:34:26 UTC
Disk read / Disk write are backwards in the Processes page of gnome-system-monitor.

For a process that is only reading from disk it shows values under "Disk write". And for a process that is only writing to disk, it shows values under "Disk read".

Running iotop or monitoring /proc/PID/io shows no such bug anywhere else. Only in gnome-system-monitor.
Comment 1 Benoît Dejean 2017-10-14 15:25:39 UTC
Hello Daniel,

can you produce screenshots showing the discrepencies betweent system-monitor and iotop ?
Comment 2 joshas 2017-10-25 18:02:28 UTC
Running gnome-system-monitor 3.26.0 on Ubuntu 17.10. Tested while downloading 700MB file with Firefox. gnome-system-monitor and "iotop -aoP " were used to measure disk writes.
iotop correctly shows disk writes over 700MB, but gnome-system-monitor has similar number in "Disk read totals".
During download gnome-system-monitor was reporting disk read speed, not disk write, that I suppose is mixed up too.
Comment 3 joshas 2017-10-25 18:03:17 UTC
Created attachment 362282 [details]
Disk writes in system-monitor and iotop
Comment 4 mark.z.harrison 2017-11-12 23:42:04 UTC
This bug also occurs for the same version of system monitor (3.26.0) on Manjaro Linux (Arch variant).
Comment 5 mark.z.harrison 2017-11-12 23:43:03 UTC
Created attachment 363460 [details]
Screenshot comparing iotop and gnome system monitor
Comment 6 Shiv Dhar 2017-12-15 15:48:49 UTC
Created attachment 365591 [details] [review]
Fix #780644

This patch fixes the order of columns vis-a-vis the enum in which the process data is stored. It seems to be fine, but someone should test it too. (First-time contributer here, please forgive -- and point out -- mistakes.

Also, shouldn't the severity be upgraded to major or higher? A process monitor which shows incorrect data is worse than nothing at all -- I lost a fair amount of time trying to save my SSD from being eaten by "disk writes" which were actually disk reads.
Comment 7 Shiv Dhar 2017-12-15 15:50:38 UTC
Created attachment 365592 [details] [review]
Fix bgo#780644

This patch fixes the order of columns vis-à-vis the enum in which the process data is stored. It seems to be fine, but someone should test it too. (First-time contributor, please forgive -- and point out -- mistakes.)

Also, shouldn't the severity be upgraded to major or higher? A process monitor which shows incorrect data is worse than nothing at all -- I lost a fair amount of time trying to save my SSD from being eaten by "disk writes" which were actually disk reads.
Comment 8 Robert Roth 2017-12-15 16:45:29 UTC
Review of attachment 365592 [details] [review]:

Thanks for your contribution. You seem to have no mistakes, I only found one thing to comment, namely the application.h changes are not necessary, as that is the initialization only, so it works regardless of the order of the fields.
Comment 9 Robert Roth 2017-12-15 16:47:42 UTC
I'm sorry I haven't fixed this until now. I once had tried to understand how the two are flipped, given that their order should be correct, but I could not find out and gave up. Your suggested fix is the easy and fast fix, let's go with that. Marking as fixed.

This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.
Comment 10 Robert Roth 2018-01-14 18:27:27 UTC
*** Bug 792517 has been marked as a duplicate of this bug. ***
Comment 11 Robert Roth 2018-04-04 05:27:37 UTC
*** Bug 794954 has been marked as a duplicate of this bug. ***