btrfs and kde

This may not be the right forum… I installed a pair of identical Samsung 850 SSDs on a laptop, then installed 15.2 with Btrfs across both devices, with default “raid” (mirror metadata, stripe data; snapshots enabled). A more or less default install.
(This is a valid configuration for a pair of SSDs to provide FS error correction.)
fstab

UUID=2222222f-4861-8888-9509-81578864445f   /                       btrfs  compress=zlib                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=2222222g-69d8-4a50-ba80-81578864445f  swap                    swap   defaults                      0  0
UUID=2222222f-4861-8888-9509-81578864445f   /var                    btrfs  subvol=/@/var                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=2222222f-4861-8888-9509-81578864445f   /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /srv                    btrfs  subvol=/@/srv                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /root                   btrfs  subvol=/@/root                0  0
UUID=2222222f-4861-8888-9509-81578864445f   /opt                    btrfs  subvol=/@/opt                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /home                   btrfs  subvol=/@/home                0  0
UUID=2222222f-4861-8888-9509-81578864445f   /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=2222222f-4861-8888-9509-81578864445f   /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=E4DD-244E                             /boot/efi               vfat   defaults                      0  2

What I’ve noticed is that about once per day (usually on boot) kde freezes (partially or mostly), repeatedly, sometimes for a minute or two at a time. Gkrellm keeps running (as does the mouse pointer) and shows a single core at 100% utilization (as does htop) - which jumps occasionally between the cores (i7-4700MQ, 16GB). This behavior lasts 5 minutes or so, then everything goes back to normal.

Ksysguard shows these are using that core thread:

btrfs-cleaner
btrfs-group-rescan
btrfs-transacti

I am curious about whether this is expected behavior. I don’t have autodefrag set.

Possibly, the Btrfs Balance and/or Scrub and/or Fstrim services are running at every boot –

  • If you check the status of the “btrfs-balance.timer” and “btrfs-scrub.timer” and “btrfs-trim.timer” services, it should be possible to see if they triggered during the boot.

Do you also have the (not Btrfs) “fstrim.timer” service enabled?

  • Disable it for the Btrfs Use Case – Btrfs has it’s own Fstrim service …

AFAIK Samsung 850 have troubles with TRIM/FSTRIM.
And possibly troubles with NCQ.
Check that.

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/ata/libata-core.c

/* devices that don’t properly handle queued TRIM commands */

{ “Samsung SSD 850*”, NULL, ATA_HORKAGE_NO_NCQ_TRIM |
ATA_HORKAGE_ZERO_AFTER_TRIM, },

The YaST / System Services applet says “fstrim” is “dead” (i.e., starts only manually).

Oops - all of them are inactive/dead and listed as “manually” start in that Yast applet… btrfs-balance, btrfs-defrag, btrfs-scrub, btrfs-trim, and btrfsmaintenance-refresh.

But you asked about the timers…

# systemctl status btrfs-balance.timer
● btrfs-balance.timer - Balance block groups on a btrfs filesystem
   Loaded: loaded (/usr/lib/systemd/system/btrfs-balance.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2021-04-20 13:54:44 MST; 2 days ago
  Trigger: Sat 2021-05-01 00:00:00 MST; 1 weeks 1 days left
     Docs: man:btrfs-balance

Apr 20 13:54:44 systemd[1]: Started Balance block groups on a btrfs filesystem.
# systemctl status btrfs-scrub.timer
● btrfs-scrub.timer - Scrub btrfs filesystem, verify block checksums
   Loaded: loaded (/usr/lib/systemd/system/btrfs-scrub.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2021-04-20 13:54:44 MST; 2 days ago
  Trigger: Sat 2021-05-01 00:00:00 MST; 1 weeks 1 days left
     Docs: man:btrfs-scrub

Apr 20 13:54:44 systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
# systemctl status btrfs-trim.timer
● btrfs-trim.timer - Discard unused blocks on a mounted filesystem
   Loaded: loaded (/usr/lib/systemd/system/btrfs-trim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Tue 2021-04-20 13:54:44 MST; 2 days ago
  Trigger: Sat 2021-05-01 00:00:00 MST; 1 weeks 1 days left
     Docs: man:fstrim

Apr 20 13:54:44 systemd[1]: Started Discard unused blocks on a mounted filesystem.
 

These say ~2 days ago they ran? But the kde slowdown happened this morning (not during a boot) and also yesterday morning during a boot.

date

Thu Apr 22 14:26:38 MST 2021

Might have to search a system log or something?

Thanks for the links - apparently this is “being worked with Samsung” - so that’s good. I’m not sure what’s invoking anything related to a TRIM.

I’m on TW but i expect the following would still be relevant. You can check btrfs actions in the log by:

journalctl --since "1 day ago" --unit=btrfs*

However, if you only see lines similar to:

Apr 20 08:32:11 DOS1 systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 20 08:32:11 DOS1 systemd[1]: Started Scrub btrfs filesystem, verify block checksums.

these are just the timers kicking off on a boot.

On a shutdown the logs will show:

Apr 05 10:41:02 DOS1 systemd[1]: btrfs-balance.timer: Succeeded.
Apr 05 10:41:02 DOS1 systemd[1]: Stopped Balance block groups on a btrfs filesystem.
Apr 05 10:41:02 DOS1 systemd[1]: btrfs-scrub.timer: Succeeded.
Apr 05 10:41:02 DOS1 systemd[1]: Stopped Scrub btrfs filesystem, verify block checksums.

If an actual balance takes place you will see something like:

Apr 19 00:00:11 DOS1 systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: Before balance of /
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: Data, single: total=136.01GiB, used=102.27GiB
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: System, single: total=32.00MiB, used=16.00KiB
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: Metadata, single: total=4.01GiB, used=2.28GiB
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: GlobalReserve, single: total=190.66MiB, used=0.00B
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: Filesystem      Size  Used Avail Use% Mounted on
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: /dev/nvme0n1p2  998G  113G  884G  12% /
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: Done, had to relocate 0 out of 143 chunks
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: flock: getting lock took 0.000001 seconds
Apr 19 00:00:11 DOS1 btrfs-balance.sh[26797]: flock: executing btrfs
....

Hi
I would not hold your breath 5 years and no action :wink: there are a few still blacklisted in libata

Well, it’s my own fault for not knowing about the blacklisting (Ignorance Is No Excuse). lol! I would have bought different drives, maybe.

OOoooo… This looks like good stuff. Thanks! :slight_smile:

Hmmm…

# journalctl --since "1 day ago" --unit=btrfs*
-- Logs begin at Tue 2021-04-20 13:54:35 MST, end at Thu 2021-04-22 18:59:45 MST. --
-- No entries --
 #

Hmmm… curiouser and curiouser… I’m not actually sure what’s running here. I know something ran today (the 22nd).


#> journalctl --since "3 days ago" --unit=btrfs*
-- Logs begin at Tue 2021-04-20 13:54:35 MST, end at Thu 2021-04-22 19:09:40 MST. --
Apr 20 13:54:43 linux systemd[1]: Started Watch /etc/sysconfig/btrfsmaintenance.
Apr 20 13:54:44 linux systemd[1]: Started Scrub btrfs filesystem, verify block checksums.
Apr 20 13:54:44 linux systemd[1]: Started Defragment file data and/or directory metadata.
Apr 20 13:54:44 linux systemd[1]: Started Balance block groups on a btrfs filesystem.
Apr 20 13:54:44 linux systemd[1]: Started Discard unused blocks on a mounted filesystem.
#>

It may be a valid configuration. But I doubt whether it is a prudent one.

fstab

UUID=2222222f-4861-8888-9509-81578864445f   /                       btrfs  compress=zlib                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /.snapshots             btrfs  subvol=/@/.snapshots          0  0
UUID=2222222g-69d8-4a50-ba80-81578864445f  swap                    swap   defaults                      0  0
UUID=2222222f-4861-8888-9509-81578864445f   /var                    btrfs  subvol=/@/var                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /usr/local              btrfs  subvol=/@/usr/local           0  0
UUID=2222222f-4861-8888-9509-81578864445f   /tmp                    btrfs  subvol=/@/tmp                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /srv                    btrfs  subvol=/@/srv                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /root                   btrfs  subvol=/@/root                0  0
UUID=2222222f-4861-8888-9509-81578864445f   /opt                    btrfs  subvol=/@/opt                 0  0
UUID=2222222f-4861-8888-9509-81578864445f   /home                   btrfs  subvol=/@/home                0  0
UUID=2222222f-4861-8888-9509-81578864445f   /boot/grub2/x86_64-efi  btrfs  subvol=/@/boot/grub2/x86_64-efi  0  0
UUID=2222222f-4861-8888-9509-81578864445f   /boot/grub2/i386-pc     btrfs  subvol=/@/boot/grub2/i386-pc  0  0
UUID=E4DD-244E                             /boot/efi               vfat   defaults                      0  2

Compression can eat lots of resources. Thus I don’t use it.

What I’ve noticed is that about once per day (usually on boot) kde freezes (partially or mostly), repeatedly, sometimes for a minute or two at a time. Gkrellm keeps running (as does the mouse pointer) and shows a single core at 100% utilization (as does htop) - which jumps occasionally between the cores (i7-4700MQ, 16GB). This behavior lasts 5 minutes or so, then everything goes back to normal.
My systems have daily btrfs maintenance enabled. I never observed freezes due to maintenance tasks.


Apr 23 00:00:00 erlangen systemd[1]: Started Discard unused blocks on a mounted filesystem. 
Apr 23 00:00:00 erlangen systemd[1]: Started Scrub btrfs filesystem, verify block checksums. 
Apr 23 00:00:00 erlangen systemd[1]: Started Balance block groups on a btrfs filesystem. 
Apr 23 00:00:00 erlangen systemd[1]: Started Defragment file data on a mounted filesystem. 
Apr 23 00:00:00 erlangen btrfs-scrub.sh[20003]: Running scrub on / 
Apr 23 00:00:00 erlangen btrfs-trim.sh[20006]: Running fstrim on / 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: Before balance of / 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: Data, single: total=30.01GiB, used=24.75GiB 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: System, single: total=32.00MiB, used=16.00KiB 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: Metadata, single: total=3.00GiB, used=1.15GiB 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: GlobalReserve, single: total=75.17MiB, used=0.00B 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf 
Apr 23 00:00:00 erlangen btrfs-balance.sh[20011]: /dev/nvme0n1p3   56G     28G   26G   53% / 
Apr 23 00:00:35 erlangen systemd[1]: btrfs-defrag.service: Succeeded. 
Apr 23 00:00:35 erlangen systemd[1]: **btrfs-defrag.service: Consumed 9.143s CPU time.**
Apr 23 00:00:59 erlangen btrfs-trim.sh[20006]: /: 25,7 GiB (27635392512 Bytes) getrimmt 
Apr 23 00:00:59 erlangen btrfs-trim.sh[20006]: flock: es dauerte 0.000003 Sekunden, um die Sperre zu bekommen 
Apr 23 00:00:59 erlangen btrfs-trim.sh[20006]: flock: fstrim wird ausgeführt 
Apr 23 00:00:59 erlangen systemd[1]: btrfs-trim.service: Succeeded. 
Apr 23 00:00:59 erlangen systemd[1]: **btrfs-trim.service: Consumed 1.779s CPU time.**
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Scrub device /dev/nvme0n1p3 (id 1) done 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Scrub started:    Fri Apr 23 00:00:59 2021 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Status:           finished 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Duration:         0:00:14 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Total to scrub:   33.04GiB 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Rate:             1.85GiB/s 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: Error summary:    no errors found 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: flock: es dauerte 58.431279 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-scrub.sh[20003]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen systemd[1]: btrfs-scrub.service: Succeeded. 
Apr 23 00:01:13 erlangen systemd[1]: **btrfs-scrub.service: Consumed 4.990s CPU time.**
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Done, had to relocate 0 out of 35 chunks 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: es dauerte 72.750227 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Dumping filters: flags 0x1, state 0x0, force is off 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]:   DATA (flags 0x2): balancing, usage=5 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Done, had to relocate 0 out of 35 chunks 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: es dauerte 0.000002 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Dumping filters: flags 0x1, state 0x0, force is off 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]:   DATA (flags 0x2): balancing, usage=10 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Done, had to relocate 0 out of 35 chunks 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Done, had to relocate 0 out of 35 chunks 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Dumping filters: flags 0x6, state 0x0, force is off 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]:   METADATA (flags 0x2): balancing, usage=3 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]:   SYSTEM (flags 0x2): balancing, usage=3 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Done, had to relocate 1 out of 35 chunks 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: es dauerte 0.000006 Sekunden, um die Sperre zu bekommen 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: flock: btrfs wird ausgeführt 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: After balance of / 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Data, single: total=30.01GiB, used=24.69GiB 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: System, single: total=32.00MiB, used=16.00KiB 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Metadata, single: total=3.00GiB, used=1.22GiB 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: GlobalReserve, single: total=73.25MiB, used=0.00B 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf 
Apr 23 00:01:13 erlangen btrfs-balance.sh[20011]: /dev/nvme0n1p3   56G     28G   26G   53% / 
Apr 23 00:01:13 erlangen systemd[1]: btrfs-balance.service: Succeeded.

See item 2 in “Additional information”.
https://www.suse.com/support/kb/doc/?id=000019447

In my TW configuration it is set to the default

BTRFS_TRIM_PERIOD="none"

You can use

[FONT=monospace]sudo journalctl --since "1 month ago" --unit=fstrim*

to see if trim is related to those problem times. If so, from section 1 of the article above you can stop/disable the fstrim timer and see if thins improve for you.

[/FONT]
systemctl stop fstrim.timer
systemctl disable fstrim.timer

Hi
Well you did post about it back in 2015 about the 8* series :slight_smile:
https://forums.opensuse.org/showthread.php/509012-migrating-to-an-SSD?p=2726349#post2726349