Recently I’ve been experiencing heavy disk usage on my system, to the point where it becomes highly unresponsive and even completely unusable in some situations (it hangs for even some minutes before unfreezing).
I’ve tried to diagnose the cause with iotop (with and without -aoP options), and found that [btrfs-transacti] seems to be the worst offender, iotop shows that it has heavy IO and disk write (almost a GB in a couple of hours of regular usage). Like I said this makes the system highly unresponsive, especially when some swap usage is involved.
Yes, I have seen similar behavior. In my case, it was with Leap 15.1 running in a VM.
I have not seen this on real hardware, because I always use “ext4”. But I do test “btrfs” on VMs (currently testing Leap 15.2Alpha with “btrfs”, but no problems yet).
Are you using a SSD or hard drive? Are you using the default partitioning? RAID? What does “btrfs fi usage /” show?
If you search for btrfs-transacti on the forum you’ll see more threads about this. One person claims running defrag helped, another claims disabling quota worked.
It is unclear whether it was recurring event (and if yes, how often and at which intervals it happened) or just one off observation. If observed just once, it could well be related to deletion of large snapshot as example.
Yes, fully updated system here. I update it regularly.
I’m on a laptop, it is equipped with an hard drive (no SSD), and the partition is pretty standard, a btrfs for root and a, ext4 for /home (plus swap and ntfs for windows). No RAID, a simple laptop like I said.
You’re getting down to around only 10GB free on the system partition. I try to keep at least 20GB free: My btrfs headaches went away after starting that practice. The new default partition size is 80GB.
You could try purging old kernels and removing the oldest snapshots, then run disk maintenance.
Aside from the information you already found about fragmentation:
COW (copy-on-write) filesystems have many advantages, but they also have some disadvantages, for example fragmentation. Btrfs lays out the data sequentially when files are written to the disk for first time, but a COW design implies that any subsequent modification to the file must not be written on top of the old data, but be placed in a free block, which will cause fragmentation (RPM databases are a common case of this problem). Aditionally, it suffers the fragmentation problems common to all filesystems.
I’m not sure if you want to run it recursively or not. I’ve only used btrfs with a SSD.
Tried to free some space and perform some cleanup, but the problem persists.
Over an afternoon (5/6 hours use) monitored with “iotop -aoP”, btrfs-transacti had about 2GB of Disk Write. Another heavy disk usage was from systemd-journald.