JeffDwork Posted December 15, 2020 Posted December 15, 2020 In both Buster and Focal 20.11.1 on helios64 commands directed to a disk increment fields in /proc/diskstats This is incorrect and does not occur in the x86 version of xubuntu Focal 20.04.1. Specifically (see https://www.kernel.org/doc/Documentation/iostats.txt for field descriptions.): Check Power Mode increments "number of reads completed" Smart Return Status, Smart Read Data, and Smart Read Log increment "number of reads completed" and "number of sectors read" The smartd disk monitor uses these commands which makes the disk appear to be active to programs like hd-idle. The work-around is to set the inactive interval in hd-idle to something shorter (20 min, for example) than the polling interval of smartd (30 min default). I would like to track this down but I need some help finding where these counters are incremented. Is there a better place to report bugs like this than in this forum? Thanks, Jeff
Igor Posted December 15, 2020 Posted December 15, 2020 3 hours ago, JeffDwork said: Is there a better place to report bugs like this than in this forum? We don't record general Linux kernel bugs and we don't record user space bugs. Why not? Because covered R&D budget is zero, nothing. Your contribution to this project is about 1000x too small that we (<10 people) could afford to cover problems that are discovered in the Linux kernel or in any out of several thousands of community made and maintained code. I am talking about this round the clock, things are improving but sadly remains on the same level. We are losing opportunity to get a better code, I know, but since this project is heavily attached to our scarce time and private pocket, you really not in a position to complain or ask for more. Because most of the people have no perception on the scale of this project or their (your) questions and the fact that we can't pay millions for working hours needed to solve bugs you find and code your wishes. We established a wishes section here: https://forum.armbian.com/forum/38-feature-requests/ but TBH, even reading them is not possible. Its always a trade - helping you or dealing with our families. Now think again and remember that public level of co-funding only mitigates the problem of download / infrastructure costs. Luckily we don't need to put disgusting ads to this website to cover those expenses. You cover them. But there your contribution ends. We can't pay for to hire 1, 10 or 50 full timers that would start dealing with what "you" want for free. We rely only on a few volunteers. Can you change this? You have a better idea? https://www.armbian.com/get-involved Bugs we decided to and are able to work on, are recorded in our Jira: https://armbian.atlassian.net/browse/AR Only contributors can open, close or comment there. 1
JeffDwork Posted December 23, 2020 Author Posted December 23, 2020 I am truly sorry to have implied that I was asking for my trivial bug to be fixed. I know that your time is precious and that this project is vast. The goals of my post: * Inform other users of a problem. I have edited my original post to include a work-around. * Determine where to post bug reports - I now understand why that's not possible for trivial issues. * Perhaps another user might know offhand where these counters are incremented and would reply with "look in file xyz". This would give me a start on fixing the problem myself. I had, and have, no expectation that the core team would fix this unless it happens to be related to a high-priority problem. * I only posted here because the bug appears to be in armbian kernel code as I do not observe it x86 ubuntu. Thank you for all that you do. Sincerely, Jeff
Recommended Posts