Linux - HardwareThis forum is for Hardware issues.
Having trouble installing a piece of hardware? Want to know if that peripheral is compatible with Linux?
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Currently: OpenMandriva. Previously: openSUSE, PCLinuxOS, CentOS, among others over the years.
Posts: 3,881
Rep:
Quote:
Originally Posted by JZL240I-U
The system has no errors (I know of) and runs as it should.
But I can hear that one hard disk is briefly accessed about 88 times / minute -- sounds like a quietly beating heart. "top" and "ps ax" don't show anything suspicious (for me, that is). I stopped "akonadi" and its helpers. "iostat" gives
sdd is not mounted, sdc is "/" on a SSD, sda and sdb are magnetic disks (for details see my signature).
How can I find out what is causing this and how to make it stop or finish faster if it is really needed?
It sounds (based soley on what info you have given us) to me like, a process/service is 'checking' your HDD at regular points for whatever reason(s).
As frankbell has suggested, smartmontools can give you an idea about your HDD's health.
But as other posters have suggested, you need to narrow down which piece of software is causing it.
There are a number of tools that can help you try and figure it out, such as (sorry if other posters have already suggested said command(s));
Code:
lsof
Displays a list of all open files on your PC. (you may need superuser rights to see ALL of them)
Code:
top
Will give you a list of currently running processes (and services running).
It may also be the case that this is something (as others have suggested) to do with the file system itself. I know that the one your using has the ability to take "snapshots" of it's state. So I would make sure that this is not the reason for your issue.
If it is the file system itself and your not having any issues stopping your PC from working correctly, I would not worry about it too much.
88 times per minute sounds like a badly written script.
Reread the thread. Full info, & acting on all advice usually gives answers in less than 8 p[osts. This is 33 posts. You probably have the answer, but haven't tried it (enough).
Distribution: openSuSE Tumbleweed-KDE, Mint 21, MX-21, Manjaro
Posts: 4,629
Original Poster
Rep:
Quote:
Originally Posted by business_kid
... acting on all advice usually gives answers in less than 8 posts. This is 33 posts. You probably have the answer, but haven't tried it (enough).
This is assuming the answer is there and I understand it. Not to mention the fact that some of this exchange happened while the error(?) wasn't there. Or in short, I do try. So. Starting from the beginning:
This is nearly unreadable, sorry. I searched on console for my disks in this spaghetti-output, results follow.
Anything you can see?
I can't copy the results from iotop but in the two uppermost lines I find "systemd --switch-root --system --deserialize 23" and "kworker/3:0" most often by far.
Okay, lsof in combination with "sudo cat /proc/962/io |grep write" looks at my /home. There was a steady write activity but at every fourth heart beat or so -- writing has stopped now, "heart" still beating (and resumed, sigh). Not in sync with the ticking.
"sudo cat /proc/954/io |grep write" looks at my backup partition, no write activities. Both have no bytes read either.
Diagnostics and smartmontools show no problems.
/tmp is mounted on the SSD, so no mechanical noise expected.
akonadiserver is sleeping and has a PID of 2560. So is mysql with PID 2595.
sync doesn't stop it.
I didn't try lazytime for /home . Changed it right now and did a "sudo mount -o remount /dev/sda6". No change. Same for noatime.
Did I overlook anything business_kid?
It just stopped all of a sudden. *sigh* (I cut away som 4500 characters in the output - too long)
Maybe it's not software at all, but the hard drive's firmware. I'm not sure how to confirm that. Hard drives do some automatic tasks in the background, like scanning for bad sectors and maybe other maintenance. They might start and stop such processes on some kind of schedule. Could this make a periodic ticking noise that comes and goes? Maybe.
I once noticed one of my hard drives making a clock-like ticking sound for hours, like the sound you describe. I didn't investigate it to the extent that you have, but SMART said everything was okay, and the drive worked fine, plus it's a drive which I only turn on occasionally for backup, so I didn't think further about it. The next time I power up that drive, I'll leave it on and see when the ticking begins again and when it stops.
... I didn't investigate it to the extent that you have, but SMART said everything was okay, and the drive worked fine, plus it's a drive which I only turn on occasionally for backup, so I didn't think further about it...
I could do that too, but I simply want to know too much what is causing this.
echo 1 > /proc/sys/vm/block_dump #BEWARE: may 'blow-up' logging!
dmesg|tail
BUT, may need to first turn off 'logging'! (klogd to /var/log/messages?) Here's info, from search of that cmd, which was found here,
from this search: linux determine|tell which process "disk activity"
When you studied iotop, could you isolate the disk i/o counts per process?
kill -STOP ... can 'freeze' a process (-CONT to resume).
Consider SysRqpidstat dstat iosnoop audit atop htop iostat sar
Insanely dangerous idea: unplug drive, to see if some process complains!
diff <(grep '_bytes: [1-9]' /proc/*/io) <(sleep 1;grep '_bytes: [1-9]' /proc/*/io)
(or use 2 tmp files for diff'ing. Concept: cat /proc/$$/io
Distribution: openSuSE Tumbleweed-KDE, Mint 21, MX-21, Manjaro
Posts: 4,629
Original Poster
Rep:
I'll take up your suggestions next time the disk starts "ticking", might be some weeks or even months hence. Thanks for trying to help in the meantime .
Distribution: openSuSE Tumbleweed-KDE, Mint 21, MX-21, Manjaro
Posts: 4,629
Original Poster
Rep:
Ahh. While
"echo 1 > /proc/sys/vm/block_dump"
did not change anything and
"diff <(grep '_bytes: [1-9]' /proc/*/io) <(sleep 1;grep '_bytes: [1-9]' /proc/*/io)"
came with empty result now
"dmesg|tail" showed something like this:
Code:
PC:/home/me # dmesg|tail
[ 4283.984763] jbd2/sda6-8(954): WRITE block 453324480 on sda6 (8 sectors)
[ 4283.985042] jbd2/sda6-8(954): WRITE block 453324488 on sda6 (8 sectors)
[ 4286.696612] kworker/u16:3(4218): WRITE block 3769248 on sdc2 (8 sectors)
[ 4289.512775] jbd2/sda6-8(954): WRITE block 453324496 on sda6 (8 sectors)
[ 4289.512802] jbd2/sda6-8(954): WRITE block 453324504 on sda6 (8 sectors)
[ 4289.513094] jbd2/sda6-8(954): WRITE block 453324512 on sda6 (8 sectors)
[ 4291.899308] bash(4579): READ block 49416608 on sdc2 (32 sectors)
[ 4291.899374] bash(4578): READ block 49542552 on sdc2 (32 sectors)
[ 4291.911403] dmesg(4578): READ block 49542584 on sdc2 (104 sectors)
[ 4291.911442] tail(4579): READ block 49416640 on sdc2 (104 sectors)
PC:/home/me # dmesg|tail
[ 5060.419810] jbd2/sda6-8(954): WRITE block 453330720 on sda6 (8 sectors)
[ 5060.419820] jbd2/sda6-8(954): WRITE block 453330728 on sda6 (8 sectors)
[ 5060.419826] jbd2/sda6-8(954): WRITE block 453330736 on sda6 (8 sectors)
[ 5060.419831] jbd2/sda6-8(954): WRITE block 453330744 on sda6 (8 sectors)
[ 5060.419835] jbd2/sda6-8(954): WRITE block 453330752 on sda6 (8 sectors)
[ 5060.419840] jbd2/sda6-8(954): WRITE block 453330760 on sda6 (8 sectors)
[ 5060.420458] jbd2/sda6-8(954): WRITE block 453330768 on sda6 (8 sectors)
[ 5060.928177] DOM Worker(3327): dirtied inode 9437485 (recovery.js.tmp) on sda6
[ 5060.928184] DOM Worker(3327): dirtied inode 9437485 (recovery.js.tmp) on sda6
[ 5060.928422] DOM Worker(3327): WRITE block 302497600 on sda6 (56 sectors)
PC:/home/me # dmesg|tail
[ 5629.575510] jbd2/sda6-8(954): WRITE block 453334584 on sda6 (8 sectors)
[ 5629.575514] jbd2/sda6-8(954): WRITE block 453334592 on sda6 (8 sectors)
[ 5629.575995] jbd2/sda6-8(954): WRITE block 453334600 on sda6 (8 sectors)
[ 5633.927869] kworker/u16:1(4479): WRITE block 301989896 on sda6 (8 sectors)
[ 5633.927887] kworker/u16:1(4479): WRITE block 301990016 on sda6 (8 sectors)
[ 5633.927892] kworker/u16:1(4479): WRITE block 301990288 on sda6 (8 sectors)
[ 5633.927897] kworker/u16:1(4479): WRITE block 302066264 on sda6 (8 sectors)
[ 5633.927908] kworker/u16:1(4479): WRITE block 0 on sda6 (8 sectors)
[ 5633.927915] kworker/u16:1(4479): WRITE block 80 on sda6 (8 sectors)
[ 5633.927939] kworker/u16:1(4479): WRITE block 300813888 on sda6 (8 sectors)
So (assuming jbd2 is the culprit) I googled and found that jbd2 is the journalling daemon of ext4. What I did not find is why it might want to write so often and so regularly to my disk (defaults,noatime is set in /etc/fstab). By the way, I observed a short period of massive head moving on the hard disk prior to the beginning of this ticking.
Did you notice how old these posts are? And quite often they refer to a solution coming with a new kernel. That's what Google produces too. But I'm running kernel 4.11 *sigh*. But thanks for the pointer anyways. Will carry on.
There's been 44 posts to this thread, and you are evidently moving, but not sorted.
It would be helpful if you could summarize problems, progress, and remaining issues while eliminating what didn't work. That way, the many (like myself) who have commented but are not going to reread 44 posts can get up to speed, and may solve it for you. It's also a good exercise for yourself, as pennies drop when you do this. I have often started that sort of post, but rarely finished one as my reviewing an issue resolves the problem.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.