intensive HDD read freezes OS at random time

English Applications
1

Hi,

I have a serious problem on my new LEAP 15 that I never had on previous opensuse version and that I can’t solve.

once or twice a day, at random time it seems, HDD start to work very hard and may be 20 seconds later, OS is not responsive anymore because of that. Mouse pointer is still alive and I can switch to console by alt+ctl+F1 but can’t log for “delay is over” as the whole system is so slow.

I could run iotop as root on console “before” the bug start and noticed that almost all apps are hdd consuming : firefox, dolphin, soffice, akonadi, etc… Just like if at one time, all apps need to read an extraordinary amount of data on HDD ! iotop indicates that hdd is essentially “read”, and very little “write”.

I tried to let it run for half an hour but the problem stills. After hard reboot, everything goes well until next time…

I made jounalctl persistent but “journalctl --boot=-1” does not show particular matter at the date and time of the bug.
/var/log/messages does not give any clue either…

I unchecked the system search tool (baloo) but the bug still happens.

I’m not that familiar with archeology in the log files and I miss ideas to find out what happens and why…

If anyone could give me some magic shell commands or some log files to explore, that would be precious !

Thank for any help,
Marc

2

PS : the system is not swapping and really few apps are running so it is not a RAM problem.

3

Please help us with a little bit more information about the disk partitions:

  • With the user “root”, please supply the output of “fdisk --list”
  • If you’re using a Btrfs system partition, please also supply the output of “btrfs filesystem usage /” – also with the user “root” …
  • Please supply the output of " systemctl list-unit-files | grep -iE ‘fsck|fstrim|btrfs’ " – please note the single quotes: " ’ " …
4

Hi, thanks for your reply !
Here is the fdisk result :

linux-derumaux:/var/log # fdisk --list
Disque /dev/sda : 465,8 GiB, 500107862016 octets, 976773168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d’E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d’étiquette de disque : dos
Identifiant de disque : 0x000c038d

Périphérique Amorçage Début Fin Secteurs Taille Id Type
/dev/sda1 63 48234495 48234433 23G 83 Linux
/dev/sda3 * 51458046 976752639 925294594 441,2G f Étendue W95 (LBA)
/dev/sda5 51458048 59842559 8384512 4G 82 partition d’échange Linux / Solaris
/dev/sda6 59844608 122759167 62914560 30G 83 Linux
/dev/sda7 122761216 123772927 1011712 494M 83 Linux
/dev/sda8 123774976 185679871 61904896 29,5G 83 Linux
/dev/sda9 185681920 976752639 791070720 377,2G 83 Linux

La partition 1 ne commence pas sur une frontière de cylindre physique.
La partition 3 ne commence pas sur une frontière de cylindre physique.

All partitions are ext4 fs. When I installed 42.3 last year with btrfs fs, I experienced first troubles with snapshots that full filled my / part, then crashes and the last crash ended with a computer I couldn’t boot anymore ! Even GRUB was crashed and I was quit worry to set up back… Since then, I choose good old ext4 fs…

linux-derumaux:/var/log # cat /etc/fstab
UUID=ce1f7326-550f-4532-a3eb-acb80595522f / ext4 acl,user_xattr 0 1
UUID=61824984-91ed-413f-9e83-b6630e245b12 /fichiers ext4 defaults 0 2
UUID=07525971-1554-49ea-ad97-a04a15aef20a /linux42.3 ext4 defaults 0 2

For the last command :

linux-derumaux:/var/log # systemctl list-unit-files | grep -iE ‘fsck|fstrim|btrfs’
btrfsmaintenance-refresh.path enabled
btrfs-balance.service static
btrfs-defrag.service static
btrfs-scrub.service static
btrfs-trim.service static
btrfsmaintenance-refresh.service enabled
fstrim.service static
systemd-fsck-root.service enabled-runtime
systemd-fsck@.service static
btrfs-balance.timer enabled
btrfs-defrag.timer disabled
btrfs-scrub.timer enabled
btrfs-trim.timer disabled
fstrim.timer enabled

Looks like strange btrfs services are enable since it is installed on ext4 fs…

thanks for your help,
Marc

5

Looks like some how btrfs utility cron jobs are running. Since you have ext4 that may explain the lockups when those crons trigger.

6

That may be the point…

But I can’t find those triggers in cron :
linux-derumaux:/home/marc # crontab -l
no crontab for root
linux-derumaux:/home/marc # crontab -u marc -l
no crontab for marc

Crontab file only have one line that I hardly understand :
linux-derumaux:/home/marc # cat /etc/crontab
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
MAILTO=root

check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly

-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1

-*/15 would it say a check runs every 15 min ?

Daily crons are those but I have no idea how to check at what time they are launched : I have no /var/log/cron.log and no /var/log/syslog…

linux-derumaux:/home/marc # ls /etc/cron.daily/
google-chrome mdadm mlocate.cron packagekit-background.cron suse-clean_catman suse-do_mandb suse-texlive

/var/log/messages shows little about cron events :
linux-derumaux:/home/marc # cat /var/log/messages | grep cron
2018-08-16T01:21:04.352354+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1185]: Refresh timer btrfs-scrub for monthly
2018-08-16T01:21:04.353028+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1185]: Refresh timer btrfs-defrag for none
2018-08-16T01:21:04.353206+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1185]: Refresh timer btrfs-balance for weekly
2018-08-16T01:21:04.353363+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1185]: Refresh timer btrfs-trim for none
2018-08-16T01:21:04.523670+02:00 linux-derumaux systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.
2018-08-16T01:21:14.373683+02:00 linux-derumaux cron[1744]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 37% if used.)
2018-08-16T01:21:14.396986+02:00 linux-derumaux cron[1744]: (CRON) INFO (running with inotify support)
2018-08-16T16:34:29.693391+02:00 linux-derumaux systemd[1]: Starting Update cron periods from /etc/sysconfig/btrfsmaintenance…
2018-08-16T16:34:29.693444+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh script btrfs-scrub.sh for uninstall
2018-08-16T16:34:29.693495+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh script btrfs-defrag.sh for uninstall
2018-08-16T16:34:29.693506+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh script btrfs-balance.sh for uninstall
2018-08-16T16:34:29.693517+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh script btrfs-trim.sh for uninstall
2018-08-16T16:34:29.693534+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh timer btrfs-scrub for monthly
2018-08-16T16:34:29.694542+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh timer btrfs-defrag for none
2018-08-16T16:34:29.694700+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh timer btrfs-balance for weekly
2018-08-16T16:34:29.694737+02:00 linux-derumaux btrfsmaintenance-refresh-cron.sh[1203]: Refresh timer btrfs-trim for none
2018-08-16T16:34:29.694837+02:00 linux-derumaux systemd[1]: Started Update cron periods from /etc/sysconfig/btrfsmaintenance.
2018-08-16T16:34:37.965677+02:00 linux-derumaux cron[1730]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 46% if used.)
2018-08-16T16:34:37.990399+02:00 linux-derumaux cron[1730]: (CRON) INFO (running with inotify support)
2018-08-17T11:41:57.846686+02:00 linux-derumaux systemd[1]: is_symlink_with_known_name(cron.service, cron.service) → 1
2018-08-17T15:39:25.398001+02:00 linux-derumaux crontab[11845]: (root) LIST (root)
2018-08-17T15:39:41.010978+02:00 linux-derumaux crontab[11848]: (root) LIST (marc)

Thanks for advice !
Marc

7

If I happen to be using the computer at 3am, I notice that, though I don’t know about the “unresponsive” part since it didn’t affect what I was doing:


2018-08-17T03:11:26.399734-05:00 nwr2 smartd[1433]: Device: /dev/sda [SAT], starting scheduled Short Self-Test.
2018-08-17T03:11:26.453041-05:00 nwr2 smartd[1433]: Device: /dev/sdb [SAT], starting scheduled Short Self-Test.
2018-08-17T03:11:26.515086-05:00 nwr2 smartd[1433]: Device: /dev/sdc [SAT], starting scheduled Short Self-Test.

I have no idea whether that’s what you are seeing.

8

Thanks for the idea. But in my case, this event occurs at arround 10 AM and it does not seems correlated to HDD bug…

2018-08-15T10:00:51.060152+02:00 linux-derumaux smartd[1155]: Device: /dev/sda [SAT], starting scheduled Short Self-Test.
2018-08-16T10:47:44.831624+02:00 linux-derumaux smartd[1184]: Device: /dev/sda [SAT], starting scheduled Short Self-Test.
2018-08-17T10:05:05.119682+02:00 linux-derumaux smartd[1208]: Device: /dev/sda [SAT], starting scheduled Short Self-Test.

Marc

9

You are well advised to apply “systemctl disable” and then “systemctl mask” to all the systemd Btrfs ‘.timer’ services.

If the disk is a HDD and not a SSD then, “disable” and “mask” the systemd “fstrim.timer” service as well – if it’s a SSHD then, ‘fstrim’ usually also doesn’t work – “disable” and “mask” the systemd service for this case as well …

Check for any Btrfs related entries in ‘/etc/cron.d/’, ‘/etc/cron.hourly/’, ‘/etc/cron.daily/’, ‘/etc/cron.weekly/’ and ‘/etc/cron.monthly/’ – remove them if there’s anything there – with systemd there’s no need for cron jobs being executing in parallel to what systemd is doing …

With no Btrfs present, you should also, at least, ‘disable’ all the systemd Btrfs related services which are not ‘static’ – ‘masked’ is better …


 > systemctl list-unit-files | grep -iE 'fsck|fstrim|btrfs'
btrfsmaintenance-refresh.path                                    masked
btrfs-balance.service                                            static
btrfs-defrag.service                                             static
btrfs-scrub.service                                              static
btrfs-trim.service                                               static
btrfsmaintenance-refresh.service                                 masked
fstrim.service                                                   static
systemd-fsck-root.service                                        enabled-runtime
systemd-fsck@.service                                            static
btrfs-balance.timer                                              masked
btrfs-defrag.timer                                               masked
btrfs-scrub.timer                                                masked
btrfs-trim.timer                                                 masked
fstrim.timer                                                     enabled
 >
10

thanks for the advice. I’ve done all disable and mask :

 
linux-derumaux:/home/marc # systemctl list-unit-files | grep -iE 'fsck|fstrim|btrfs' 
btrfsmaintenance-refresh.path                masked         
btrfs-balance.service                        static         
btrfs-defrag.service                         static         
btrfs-scrub.service                          static         
btrfs-trim.service                           static         
btrfsmaintenance-refresh.service             masked         
fstrim.service                               static         
systemd-fsck-root.service                    enabled-runtime
systemd-fsck@.service                        static         
btrfs-balance.timer                          masked         
btrfs-defrag.timer                           masked         
btrfs-scrub.timer                            masked         
btrfs-trim.timer                             masked         
fstrim.timer                                 masked

I’ll tell you how it works since then !
Thanks, Marc

11

Hi,

Well, so far, the btrfs services disable seems to have solved the problem on my ext4 install.

At first, since modif and reboot, the desktop seems more reactive when launching apps and working, just as it was on opensuse 42.3.
Also, when suspending to ram, the wake-up is much faster. That’s already great new !

I did not had any total freeze due to HDD over usage since then (second great new) and I hope the issue is solved.

Thanks all for advices !
Marc

12

I’m back after a few days…

Unfortunately, I still have HDD over-run at some times…

After a bit more experience, it seems that Firefox is responsible. When trouble occurs, I kill Firefox and HDD slows after a few seconds. I tried Chrome but it has same problem as firefox.

I also tried to get an iotop.log file to catch the io thing and investigate. Iotop fills a log file every 10 sec (iotop -b -t -o -d 10 >> /tmp/iotop.log &) and here is an example of the situation when HDD is over :


09:17:15 Total DISK READ :      14.32 M/s | Total DISK WRITE :      13.48 K/s
09:17:15 Actual DISK READ:      15.22 M/s | Actual DISK WRITE:      12.44 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
09:17:15  1936 be/4 marc      849.40 K/s    0.00 B/s  0.00 % 99.99 % kwin_x11 -session 10154101a4d7000153121386200000033960003_1535117510_119066
09:17:15 17850 be/4 marc      954.63 K/s    0.00 B/s  0.00 % 99.99 % firefox
09:17:15 17887 be/4 marc      855.10 K/s    0.00 B/s  0.00 % 99.99 % firefox [Compositor]
09:17:15 18323 be/4 root      488.07 K/s    0.00 B/s  0.00 % 99.99 % python3 /usr/sbin/iotop -d 10
09:17:15   373 be/4 root     1092.01 K/s    4.67 K/s  0.00 % 99.99 % systemd-journald
09:17:15  4963 be/4 marc     1943.74 K/s    0.00 B/s  0.00 % 99.89 % soffice.bin --writer /home/marc/marc/Prepa/Eleve/Eleves_1819/organisation_rentrée.odt --splash-pipe=5
09:17:15  2018 be/4 marc      732.76 K/s    0.00 B/s  0.00 % 98.65 % owncloud -session 101cb18313f13b000153467441400000020410010_1535117509_679834
09:17:15 18000 be/4 marc     1093.82 K/s    0.00 B/s  0.00 % 98.52 % firefox -contentproc -childID 3 -isForBrowser -intPrefs 246:0| -boolPrefs 260:1|300:0|310:0| -stringPrefs 286:36;024b8b72-900f-4bee-9f28-9fdfdfc58da6| -schedulerPrefs 0001,2 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 17850 true tab
09:17:15 18326 be/4 marc      877.65 K/s    0.00 B/s  0.00 % 98.45 % file.so [kdeinit5] file local:/run/user/1000/klauncherTJ1897.1.slave-socket local:/run/user/1000/dolphineD4252.10.slave-socket
09:17:15  1945 be/4 marc      167.96 K/s    0.00 B/s  0.00 % 97.92 % plasmashell
09:17:15 18070 be/4 marc      786.15 K/s    0.00 B/s  0.00 % 97.70 % firefox -contentproc -childID 4 -isForBrowser -intPrefs 246:0| -boolPrefs 260:1|300:0|310:0| -stringPrefs 286:36;024b8b72-900f-4bee-9f28-9fdfdfc58da6| -schedulerPrefs 0001,2 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 17850 true tab
09:17:15 17946 be/4 marc      893.20 K/s    0.00 B/s  0.00 % 96.44 % firefox -contentproc -childID 2 -isForBrowser -intPrefs 246:0| -boolPrefs 260:1|300:0|310:0| -stringPrefs 286:36;024b8b72-900f-4bee-9f28-9fdfdfc58da6| -schedulerPrefs 0001,2 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 17850 true tab
09:17:15 15066 be/4 marc      851.73 K/s    0.00 B/s  0.00 % 95.99 % owncloud -session 101cb18313f13b000153467441400000020410010_1535117509_679834 [QNetworkAccessM]
09:17:15  9711 be/4 marc      269.83 K/s  265.42 B/s  0.00 % 55.06 % dolphin
09:17:15  1339 be/4 root      362.10 K/s    0.00 B/s  0.00 % 38.93 % NetworkManager --no-daemon
09:17:15  4252 be/4 marc       67.91 K/s    0.00 B/s  0.00 % 33.76 % dolphin
09:17:15 17805 be/4 root      109.64 K/s  530.84 B/s  0.00 % 33.33 % python3 /usr/sbin/iotop -b -t -o -d 10
09:17:15  1905 be/4 marc      174.96 K/s    0.00 B/s  0.00 % 26.78 % kded5 [kdeinit5] [QDBusConnection]
09:17:15  1956 be/4 marc        0.00 B/s    0.00 B/s  0.00 % 24.87 % plasmashell [QDBusConnection]
09:17:15  1900 be/4 marc      276.31 K/s    0.00 B/s  0.00 % 23.65 % kded5 [kdeinit5]

As you can see, all applications seems to have a heavy io read activity, but Firefox takes the biggest part with several processes.

Same problem with chrome :


10:37:20 Total DISK READ :      13.88 M/s | Total DISK WRITE :       6.70 K/s
10:37:20 Actual DISK READ:      14.43 M/s | Actual DISK WRITE:       8.19 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
10:37:20 18475 be/4 marc        2.87 M/s    2.98 K/s  0.00 % 89.10 % chrome [Chrome_IOThread]
10:37:20 20489 be/4 marc      817.53 K/s    0.00 B/s  0.00 % 42.03 % chrome --type=renderer --field-trial-handle=9704019150486262565,10537814510321655361,131072 --disable-gpu-compositing --service-pipe-token=FED35CA1C05A3AB4DAD3162736C3A077 --lang=fr --enable-crash-reporter=3febad08-8228-432e-b85b-c58b829ebe0a, --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --num-raster-threads=1 --service-request-channel-token=FED35CA1C05A3AB4DAD3162736C3A077 --renderer-client-id=82 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101
10:37:20  2018 be/4 marc     1404.98 K/s    0.00 B/s  0.00 % 38.08 % owncloud -session 101cb18313f13b000153467441400000020410010_1535117509_679834
10:37:20 20474 be/4 marc     1343.19 K/s    0.00 B/s  0.00 % 35.72 % chrome --type=renderer --field-trial-handle=9704019150486262565,10537814510321655361,131072 --disable-gpu-compositing --service-pipe-token=73BC6B76165AE1E0E136AEFEB7E13E06 --lang=fr --enable-crash-reporter=3febad08-8228-432e-b85b-c58b829ebe0a, --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --num-raster-threads=1 --service-request-channel-token=73BC6B76165AE1E0E136AEFEB7E13E06 --renderer-client-id=81 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101
10:37:20 18453 be/4 marc     1224.06 K/s  381.21 B/s  0.00 % 34.60 % chrome
10:37:20 20272 be/4 marc      856.24 K/s    0.00 B/s  0.00 % 29.45 % chrome --type=renderer --field-trial-handle=9704019150486262565,10537814510321655361,131072 --disable-gpu-compositing --service-pipe-token=1793231B0E26BF85E5AB68CB2CCF808A --lang=fr --enable-crash-reporter=3febad08-8228-432e-b85b-c58b829ebe0a, --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --num-raster-threads=1 --service-request-channel-token=1793231B0E26BF85E5AB68CB2CCF808A --renderer-client-id=67 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101
10:37:20  1339 be/4 root      698.02 K/s    0.00 B/s  0.00 % 29.19 % NetworkManager --no-daemon
10:37:20 18352 be/4 marc      429.98 K/s    0.00 B/s  0.00 % 19.32 % owncloud -session 101cb18313f13b000153467441400000020410010_1535117509_679834 [QNetworkAccessM]
10:37:20   373 be/4 root      194.70 K/s    0.00 B/s  0.00 % 15.22 % systemd-journald
10:37:20  1905 be/4 marc      142.96 K/s    0.00 B/s  0.00 % 14.99 % kded5 [kdeinit5] [QDBusConnection]
10:37:20  9711 be/4 marc      509.65 K/s    0.00 B/s  0.00 % 14.41 % dolphin
10:37:20 18709 be/4 marc      223.00 K/s    0.00 B/s  0.00 % 13.67 % chrome [Chrome_SyncThre]
10:37:20 20498 be/4 marc      258.73 K/s    0.00 B/s  0.00 % 12.84 % chrome --type=renderer --field-trial-handle=9704019150486262565,10537814510321655361,131072 --disable-gpu-compositing --service-pipe-token=FED35CA1C05A3AB4DAD3162736C3A077 --lang=fr --enable-crash-reporter=3febad08-8228-432e-b85b-c58b829ebe0a, --enable-offline-auto-reload --enable-offline-auto-reload-visible-only --num-raster-threads=1 --service-request-channel-token=FED35CA1C05A3AB4DAD3162736C3A077 --renderer-client-id=82 --shared-files=v8_context_snapshot_data:100,v8_natives_data:101 [Compositor]
10:37:20  2097 be/4 marc       49.51 K/s    0.00 B/s  0.00 % 11.23 % kgpg -session 101cb18313f13b000153134409500000019950016_1535117509_679205 [Qt bearer threa]

Interesting thing but I still have no clue to catch the bug…

My laptop is a bit old (2007) and I wonder if some graphic enhancement that my graphic card can’t handle may be emulated and so drive to heavy processes… But a top command show almost no CPU activity…

During iotop archeology, a process with funny option found :
09:17:33 18342 be/4 marc 376.54 K/s 0.00 B/s 0.00 % 96.47 % kdeinit5 --suicide

Thanks for any help if someone find a clue !
Marc

13

I see that, you’re using KDE Plasma – please install the “kdebugsettings” package from the main openSUSE repository – call it from the user’s CLI in a Konsole window (the package usually doesn’t add an entry to the KDE starter): ‘kdebugsettings’ – and then select the button “Turn Off Debug” …

On this Leap 15.0 system running Firefox version 60.1.0, KDE Plasma version 5.12.5, KDE Frameworks 5 version 5.45.0 and Qt version 5.9.4, with all KDE debugging turned off, ‘iotop’ looks like this:


 > cat /tmp/iotop.log
11:14:51 Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
11:14:51 Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       0.00 B/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
11:15:01 Total DISK READ :       0.00 B/s | Total DISK WRITE :       2.38 K/s
11:15:01 Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       7.54 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
11:15:01   746 be/3 root        0.00 B/s 2032.22 B/s  0.00 %  0.40 % [jbd2/sdc1-8]
11:15:01   739 be/3 root        0.00 B/s    0.00 B/s  0.00 %  0.29 % [jbd2/sdb1-8]
11:15:01    34 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.13 % [kworker/0:1]
11:15:01    50 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/3:1]
11:15:01 11422 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/3:4]
11:15:01    29 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.07 % [kworker/3:0]
11:15:01   382 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.07 % [kworker/3:3]
11:15:01 13299 be/4 root        0.00 B/s  406.44 B/s  0.00 %  0.00 % python3 /usr/sbin/iotop -b -t -o -d 10
11:15:01 13297 be/4 xxx         0.00 B/s    0.00 B/s  0.00 %  0.00 % firefox [IndexedDB #15]
11:15:11 Total DISK READ :       0.00 B/s | Total DISK WRITE :       3.97 K/s
11:15:11 Actual DISK READ:       0.00 B/s | Actual DISK WRITE:      49.97 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
11:15:11   739 be/3 root        0.00 B/s  406.07 B/s  0.00 %  0.24 % [jbd2/sdb1-8]
11:15:11   746 be/3 root        0.00 B/s 2030.36 B/s  0.00 %  0.21 % [jbd2/sdc1-8]
11:15:11    34 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.13 % [kworker/0:1]
11:15:11   382 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/3:3]
11:15:11    29 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/3:0]
11:15:11 11422 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.08 % [kworker/3:4]
11:15:11    50 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.07 % [kworker/3:1]
11:15:11 13304 be/4 xxx         0.00 B/s 1624.29 B/s  0.00 %  0.00 % plasmashell [Thread (pooled)]
 >
14

Thanks for your help ! I installed kdebugsettings and at launch, it seems that all options where already set to “INFO”. I clicked anyway on “Turn off debug” with no obvious change.

I have to wait until a new bug occurs or not. I’ll keep you informed.

Actually, before HDD gets crasy, the OS works well and iotop returns something similar to yours :


21:29:17 Total DISK READ :       0.00 B/s | Total DISK WRITE :       0.00 B/s
21:29:17 Actual DISK READ:       0.00 B/s | Actual DISK WRITE:       2.12 M/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
21:29:27 Total DISK READ :     807.44 B/s | Total DISK WRITE :       8.28 K/s
21:29:27 Actual DISK READ:     807.44 B/s | Actual DISK WRITE:       9.46 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
21:29:27   327 be/3 root        0.00 B/s    7.89 K/s  0.00 %  0.54 % [jbd2/sda8-8]
21:29:27 15846 be/4 root      807.44 B/s  403.72 B/s  0.00 %  0.42 % python3 /usr/sbin/iotop -b -t -o -d 10
21:29:27 14144 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/1:0]
21:29:38 Total DISK READ :      37.99 K/s | Total DISK WRITE :      21.77 K/s
21:29:38 Actual DISK READ:     679.15 K/s | Actual DISK WRITE:      32.85 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
21:29:38   327 be/3 root        0.00 B/s    7.52 K/s  0.00 %  1.00 % [jbd2/sda8-8]
21:29:38  2898 be/4 marc       20.58 K/s    0.00 B/s  0.00 %  0.38 % dolphin
21:29:38 15827 be/4 root       17.41 K/s    0.00 B/s  0.00 %  0.33 % bash
21:29:38 15615 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.14 % [kworker/u4:0]
21:29:38 14144 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/1:0]
21:29:38   385 be/4 root        0.00 B/s   12.27 K/s  0.00 %  0.00 % systemd-journald
21:29:38  1332 be/4 root        0.00 B/s  810.55 B/s  0.00 %  0.00 % rsyslogd -n -iNONE [rs:main Q:Reg]
21:29:38  3388 be/4 marc        0.00 B/s  810.55 B/s  0.00 %  0.00 % firefox [Cache2 I/O]
21:29:48 Total DISK READ :      11.87 K/s | Total DISK WRITE :    2026.27 B/s
21:29:48 Actual DISK READ:      11.87 K/s | Actual DISK WRITE:      17.02 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
21:29:48   327 be/3 root        0.00 B/s 1215.76 B/s  0.00 %  0.61 % [jbd2/sda8-8]
21:29:48  2898 be/4 marc       11.08 K/s    0.00 B/s  0.00 %  0.36 % dolphin
21:29:48  3437 be/4 marc      405.25 B/s    0.00 B/s  0.00 %  0.30 % firefox [FS Broker 3423]
21:29:48  3423 be/4 marc      405.25 B/s    0.00 B/s  0.00 %  0.14 % firefox -contentproc -childID 1 -isForBrowser -intPrefs 246:0| -boolPrefs 260:1|300:0|310:0| -stringPrefs 286:36;024b8b72-900f-4bee-9f28-9fdfdfc58da6| -schedulerPrefs 0001,2 -greomni /usr/lib64/firefox/omni.ja -appomni /usr/lib64/firefox/browser/omni.ja -appdir /usr/lib64/firefox/browser 3346 true tab
21:29:48 14144 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/1:0]
21:29:48 15846 be/4 root        0.00 B/s  810.51 B/s  0.00 %  0.00 % python3 /usr/sbin/iotop -b -t -o -d 10
21:29:58 Total DISK READ :     101.29 K/s | Total DISK WRITE :       3.96 K/s
21:29:58 Actual DISK READ:     101.29 K/s | Actual DISK WRITE:      15.04 K/s
    TIME  TID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO    COMMAND
21:29:58   327 be/3 root        0.00 B/s    3.17 K/s  0.00 %  1.88 % [jbd2/sda8-8]
21:29:58  2898 be/4 marc      101.29 K/s  810.35 B/s  0.00 %  1.63 % dolphin
21:29:58  1615 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.10 % X -nolisten tcp -auth /run/sddm/{e4bd890d-b369-4448-9668-005866d6af2c} -background none -noreset -displayfd 18 -seat seat0 vt7
21:29:58 14144 be/4 root        0.00 B/s    0.00 B/s  0.00 %  0.09 % [kworker/1:0]

But sometimes (at 17:30 this evening for example), system ask to read HDD at more than 14 Mo/s and system gets almost freeze (any action on desktop like changing window needs several minutes…). The only option is hard reboot.

I noticed at 17h30 this evening that a few minutes before HDD start running fast, the task bar was not responsive anymore. I could still work on Libreoffice and Kmail anyway, switch between apps by ctrl+tab… I don’t know if it is linked. After reboot, “sofware update” indicates 9465 updates so I feel “gloups” ! I’ll reboot tonight before updating : I wonder if OS is going crasy !

Is there any other activity command like iotop that I could catch in a log file and could get information about the processes start or waking up ?

Thanks for advices !
Marc