Arch Linux

fib_nm

Member

Registered: 2024-02-27

Posts: 23

All disk related operations are unusably slow after update

After running 'paru -Syu' today, all disk related operations started taking second or even dozens of seconds, instead of being instant as previously. To be more accurate, they can take from 0 seconds to a minute with approximately 50% chance. For example:
- Deleting a file in obsidian took 50 seconds
- Deleting a file via gio trash in a terminal took 30 seconds
- Deleting a file via rm in a terminal took 47 seconds
- Opening a file in obsidian took 40 seconds (only name of the file is seen after clicking on it for around 40 seconds, without showing the contents. After that time, contents appear)
- Renaming a file in obsidian took 10 seconds
- Going back to ranger from terminal via Ctrl+D took 11 seconds
- Searching for a file by keywords in obsidian took 10 seconds (usually it's instant)
- Renaming a file in obsidian took 10 seconds
- Creating a kitty terminal took 41 seconds
- Closing a kitty terminal took 11 seconds
- When I turned my pc off last time, it went to 'watchdog did not stop!', the paused there for around a minute, then printed 'watchdog did not stop!' twice and turned off.

I use hyprland, sddm, with btrfs filesystem on encrypted with luks partition. I use snapper to take snapshots (I have 90 at the moment).

seth

Member

From: Don't DM me only for attention

Registered: 2012-09-03

Posts: 71,586

Re: All disk related operations are unusably slow after update

btrfs filesystem on encrypted with luks

Tried to downgrade the kernel or the LTS one?
Any IO/BTRFS/encryption related errors in the system journal?

---

How to upload text · How to boot w/o GUI · Disable Windows Fast-Start! · Fix your xinitrc

fib_nm

Member

Registered: 2024-02-27

Posts: 23

Re: All disk related operations are unusably slow after update

btrfs filesystem on encrypted with luks

Tried to downgrade the kernel or the LTS one?
Any IO/BTRFS/encryption related errors in the system journal?

I don't see any errors related to these things:

[fib_nm@archlaptop ~]$ sudo journalctl -k -p warning..emerg
Jul 10 14:50:07 archlaptop kernel: x86/cpu: SGX disabled or unsupported by BIOS.
Jul 10 14:50:07 archlaptop kernel: MMIO Stale Data CPU bug present and SMT on, data leak possible. See https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/processor_mmio_stale_data.html for more deta>
Jul 10 14:50:07 archlaptop kernel: ACPI BIOS Error (bug): Failure creating named object [\_GPE._L12], AE_ALREADY_EXISTS (20240827/dswload2-326)
Jul 10 14:50:07 archlaptop kernel: ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20240827/psobject-220)
Jul 10 14:50:07 archlaptop kernel: ACPI Error: For GPE 0x08, found both _L08 and _E08 methods (20240827/evgpeinit-398)
Jul 10 14:50:07 archlaptop kernel: ENERGY_PERF_BIAS: Set to 'normal', was 'performance'
Jul 10 14:50:07 archlaptop kernel: hid-generic 0003:1532:0099.0004: No inputs registered, leaving
Jul 10 14:50:07 archlaptop kernel: nvidia: loading out-of-tree module taints kernel.
Jul 10 14:50:08 archlaptop kernel: 
Jul 10 14:50:08 archlaptop kernel: NVRM: loading NVIDIA UNIX Open Kernel Module for x86_64  575.64.03  Release Build  (root@)  
Jul 10 14:50:08 archlaptop kernel: VBoxNetAdp: Successfully started.
Jul 10 14:50:08 archlaptop kernel: VBoxNetFlt: Successfully started.
Jul 10 14:50:08 archlaptop kernel: spi-nor spi0.0: supply vcc not found, using dummy regulator
Jul 10 14:50:08 archlaptop kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
Jul 10 14:50:08 archlaptop kernel: asus_wmi: ASUS Management GUID not found
Jul 10 14:50:09 archlaptop kernel: Bluetooth: hci0: HCI LE Coded PHY feature bit is set, but its usage is not supported.
Jul 10 14:50:49 archlaptop kernel: warning: `ThreadPoolForeg' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211

[fib_nm@archlaptop ~]$ sudo journalctl -b | grep -i luks
Jul 10 14:50:07 archlaptop kernel: Command line: initrd=\initramfs-linux.img cryptdevice=UUID=0f815306-8395-411e-a032-3d7931770145:luks root=/dev/mapper/luks rootflags=subvol=@ rw
Jul 10 14:50:07 archlaptop kernel: Kernel command line: initrd=\initramfs-linux.img cryptdevice=UUID=0f815306-8395-411e-a032-3d7931770145:luks root=/dev/mapper/luks rootflags=subvol=@ rw
Jul 10 14:50:07 archlaptop kernel: Unknown kernel command line parameters "cryptdevice=UUID=0f815306-8395-411e-a032-3d7931770145:luks", will be passed to user space.
Jul 10 14:50:07 archlaptop kernel:     cryptdevice=UUID=0f815306-8395-411e-a032-3d7931770145:luks
Jul 10 14:50:07 archlaptop kernel: BTRFS: device label arch devid 1 transid 61595 /dev/mapper/luks (253:0) scanned by mount (523)

[fib_nm@archlaptop ~]$ sudo journalctl -b | grep -i btrfs
Jul 10 14:50:07 archlaptop kernel: Btrfs loaded, zoned=yes, fsverity=yes
Jul 10 14:50:07 archlaptop kernel: BTRFS: device label arch devid 1 transid 61595 /dev/mapper/luks (253:0) scanned by mount (523)
Jul 10 14:50:07 archlaptop kernel: BTRFS info (device dm-0): first mount of filesystem 8cf272ea-1dc7-4671-bd0a-ea41c9dc9fec
Jul 10 14:50:07 archlaptop kernel: BTRFS info (device dm-0): using crc32c (crc32c-x86) checksum algorithm
Jul 10 14:50:07 archlaptop kernel: BTRFS info (device dm-0): using free-space-tree
Jul 10 14:50:08 archlaptop kernel: BTRFS info (device dm-0 state M): use zstd compression, level 3
Jul 10 15:00:23 archlaptop systemd-helper[14934]: Running 'btrfs qgroup clear-stale /.snapshots'.
Jul 10 15:22:03 archlaptop kernel: BTRFS info (device dm-0): qgroup scan completed (inconsistency flag cleared)
Jul 10 16:00:23 archlaptop systemd-helper[90842]: Running 'btrfs qgroup clear-stale /.snapshots'.
Jul 10 17:00:23 archlaptop systemd-helper[166350]: Running 'btrfs qgroup clear-stale /.snapshots'.
Jul 10 17:35:33 archlaptop sudo[210033]:   fib_nm : TTY=pts/3 ; PWD=/home/fib_nm ; USER=root ; COMMAND=/usr/bin/btrfs quota show /

But there are lines that indicate 'qgroup scan' maybe that was the reason of slow down. I wonder what triggered it though.

fib_nm

Member

Registered: 2024-02-27

Posts: 23

Re: All disk related operations are unusably slow after update

Forgot to mention that after I left pc for several hours and came back to it, it began working normally again. So maybe the problem was in having too much snapshots, which made qgroup scan too long. I reduced their number to 25. I hope this will help.