[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
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.
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/
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