You are not logged in.
Some years before---30 July 2016 to be exact---I encountered a kernel problem where my hard disk was written to perpetually in short intervals of about five seconds. The culprit then turned out to be a program called JDB2, as I then found out using iotop to profile IO streams. The solution:
/etc/fstab:
# /dev/sda2
UUID=[myuuid] / ext3 rw,relatime,data=ordered,commit=60,noatime 0 1
solved the problem in that situation. However, the problem has now recurred. And the old remedy does not seem to work. The difference to the situation in 2016 is that now a program called kworker is using the disk every second---which is really annoying---and the old culprit JDB2 is less problematic with about 90 second intervals.
The issue has been documented before in kworker, jbd2 constantly writing to disk but without a definite workaround or solution. I wonder if the problem recurs because a specific kernel update. The kernel I'm using is 5.1.8-arch1-1-ARCH. Have others noted a similar problem?
Last edited by catnap (2020-04-07 20:39:56)
Offline
The kworker and jbd2 processes are just kernel workers servicing work for user-space (calls). Use powertop to determine the root of what's causing disk wakeups.
--
saint_abroad
Offline
The program powertop reports the following kWork activities. I wonder if this would help to resolve the issue.
Usage Events/s Category Description
15,4 µs/s 6,7 kWork intel_atomic_helper_free_state_
81,0 µs/s 6,6 kWork intel_atomic_cleanup_work
0,0 µs/s 6,4 kWork intel_atomic_commit_work
14,8 µs/s 2,2 kWork psi_update_work
0,0 µs/s 0,8 kWork disk_events_workfn
15,0 µs/s 4,0 kWork console_callback
6,1 µs/s 0,5 kWork i915_gem_retire_work_handler
53,2 µs/s 0,4 kWork i915_gem_idle_work_handler
Offline
The systemctl program reports the following problem with Kernel modules:
systemd-modules-load.service loaded failed failed Load Kernel Modules
I wonder if this might be causing the problem of disk wakeups.
Offline
Check out a program named "fatrace". There is an AUR package for it. Start it with "sudo fatrace" and then wait to see what it prints. It will print a line the following whenever any program accesses files:
steam(7798): RCO /home/user/.Xauthority
Offline
As per the disk wakeups link, try
Looking at the powertop.log you will see a section titled "Disc accesses:" and this will list processes that were writing to disk and the name of the file and device it was writing to.
Last edited by sabroad (2019-06-12 09:32:07)
--
saint_abroad
Offline
I'm using PowerTOP version v2.10 which does not seem to list "Disc access". I called the program with
# powertop --time=60 --debug -r powertop-2.html
However, with fatrace I was able to produce a list of write events. Somewhat peculiarly, kWork seems to perpetually jump to the top of the iotop list even when nothing new shows in the fatrace list. There seem to be ghost writes that do not leave a trace to any specific file.
Offline
Are you sure the worker is actually touching the HDD? "I/O" does not necessarily mean "Disk I/O".
Offline
Are you sure the worker is actually touching the HDD? "I/O" does not necessarily mean "Disk I/O".
It sounds like the hard drive is continuously quite active. It is not exactly the same kind of thunder as a hard drive makes when it is swapping although there seems to be some overlap. The noise is less pronounced but almost as continuous. It makes me wonder how long the poor thing can take this sort of a beating.
When I booted to the bootable Arch Linux image CD, the disk did not seem to be equally active anymore, suggesting that the problem might not lie in the disk itself. I worry there might be some sort of a virus in action. But I wonder if there are viruses that would act so conspicuously, given that most viruses attempt to conceal their presence on the disk.
Offline
Eleminate as many variables as possible. Boot into the rescue.target. If the behavior isn't present there, change to the multi-user.target
If the behavior isnt't present there, try a different graphical.target. KDE and gnome come w/ file indexers which will keep the disk busy. The disks response to this depends on its type. Server disks are designed to run (full I/O) 24/7.
Offline
Because it seems to be difficult to find a scenario that would eliminate the swapping-like sound, I'm starting to suspect that it's origin is not in the HDD but elsewhere in the hardware. If it gets worse, I'll just take my computer to a repair service.
Offline
The disk might do some internal stuff for the SMART features.
If you can deactivate the HDD in the BIOS and boot from cd/usb you could maybe figure whether the sound stems from it. If you can't, you can still pull the power supply from the HDD…)
Offline
You can check if it's interrupt-related, and if yes, possibly disable the interrupt causing problems.
See this article at Unix & Linux Stack Exchange.
Offline
After a few months of absence, during which time I've been working on another computer, I have returned to my previous computer which still suffers from something like disk wakeups. Fortunately, there has been some progress in resolving the issue.
The disk might do some internal stuff for the SMART features.
If you can deactivate the HDD in the BIOS and boot from cd/usb you could maybe figure whether the sound stems from it. If you can't, you can still pull the power supply from the HDD…)
I turned the S.M.A.R.T. feature off using
# smartctl -s off /dev/sdb
Although the command was successful, it failed to solve the problem.
However, I did try physically unplugging the power from the problematic hard drive. The sounds subsided and the computer is pleasantly silent now! If I just manage to migrate my home folder to my SSD hard disk or to an external hard disk, I can continue using the computer as usual but without the nuisance of disk wakeups. Perhaps, I will open another thread for this.
Offline