[ricklinux@kde-plasma ~]$ cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
UUID=E671-E04A /boot/efi vfat defaults,noatime 0 2
UUID=ca774ba7-cf83-4f2a-971f-9b03a4d5f094 / btrfs subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=ca774ba7-cf83-4f2a-971f-9b03a4d5f094 /home btrfs subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=ca774ba7-cf83-4f2a-971f-9b03a4d5f094 /var/cache btrfs subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=ca774ba7-cf83-4f2a-971f-9b03a4d5f094 /var/log btrfs subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=ca774ba7-cf83-4f2a-971f-9b03a4d5f094 /swap btrfs subvol=/@swap,defaults,noatime 0 0
/swap/swapfile swap swap defaults 0 0
[ricklinux@kde-plasma ~]$
We have a few differences but its due to the fact that I’m using dracut and not grub, everything else is pretty the same…
I’ll test the discard=async option as based on what Google engineers said, it has a better reading latency and is likely to be the default for kernel 6.2…
I suppose that all its required is to enable it in fstab, disable fstrim.timer service…
If this is correct, should I add this option to my swap mountpoint too? Not sure…
See, according to that link in my first post, this will likely be the default once kernel 6.2 is released.
Also, Facebook/Meta engineers found that asynchronously (discard=async) is more efficient and help reduce read latencies.
Its not clear at this moment if this will be the default or not, so I’m just testing for now…
If this becomes indeed the default, we would have to check again because I’m not sure if you can run periodic trim (fstrim.timer) and asynchronously trim at the same time.
It seems so, I just recorded a 2 minutes video while watching Youtube video through Firefox, and it feels the same as it was before enabling discard=async option…
10 minutes running #iotop -a
Edit:
Definitely this option increased the amount of writes…
COW means that modifications are made on new “blocks”, keeping the old ones, but in the end the writing of modified blocks would be executed anyway, even in a non COW filesystem… so the number of writings is the same… at least, that’s my understanding from https://fedoramagazine.org/working-with-btrfs-general-concepts/
Have you done some experiments with some data to share? I’d be interested. The output of iotop above is related to enabling async discard if I understand correctly.
Yeah, but unfortunately i did it some time ago only for myself, so no real data was saved sorry…You can repeat experiment, maybe they’ve changed some stuff on BTRFS, but i doubt it because that’s kinda COW’s motto.
I remember it was more writes than ext4, not like gigabytes more, but still much more.
I just came for conclusion that for various reasons from stability, to more writes BTRFS was not for me.
Yes, but iotop can be used to test stuff without this setting between exactly same disks with different filesystems as well
As far as my own settings, i’ve always:
For SSDs Removed continuous trim, which is discard in /etc/fstab
Enabled periodic trim via fstrim.timer service
Set udev rules as: bfq scheduler for normal SSDs, No scheduler for NVMEs, mq-deadline for HDDs
