Fstrim disable to enable discard=async?

So, if I want to enable discard=async for my btrfs mountpoints, I should disable fstrim.timer service, right?

Edit: I’m using a swapfile, is it ok to enable discard=async for it too?

current fstab:
UUID=775C-8D5F                            /efi      vfat    defaults,noatime 0 2
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /              btrfs   subvol=/@,defaults,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /home          btrfs   subvol=/@home,defaults,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /var/cache     btrfs   subvol=/@cache,defaults,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /var/log       btrfs   subvol=/@log,defaults,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /swap          btrfs   subvol=/@swap,defaults,noatime 0 0
/swap/swapfile                            swap           swap    defaults   0 0
1 Like

This is my fstab currently.

[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 ~]$ 
1 Like

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…

Ya this new dracut i don’t know much about it. I have a hard enough time understanding btrfs. :rofl:

2 Likes

If it wasn’t for Dalto, I wouldn’t understand it either… :slight_smile:

Since that last grub problem, and also due to grub vulnerabilities, I decided to test dracut and so far, everything is working perfectly.

What I can’t do anymore is to boot into snapshots, but its okay, I can restore everything by booting into liveUSB…

You can disable it, yes.

I think you mean “systemd-boot”. dracut is an alternative to mkinitcpio.

1 Like

Exactly that, systemd-boot with dracut as you showed in a topic here a few months ago.

Done, left swapfile only with default options.

Thanks everyone for the answers.

UUID=775C-8D5F                            /efi      vfat    defaults,noatime 0 2
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /              btrfs   subvol=/@,defaults,discard=async,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /home          btrfs   subvol=/@home,defaults,discard=async,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /var/cache     btrfs   subvol=/@cache,defaults,discard=async,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /var/log       btrfs   subvol=/@log,defaults,discard=async,noatime,compress=zstd 0 0
UUID=87e2342f-eea1-4780-bd7a-65ebfc4c8aa1 /swap          btrfs   subvol=/@swap,defaults,discard=async,noatime 0 0
/swap/swapfile                            swap           swap    defaults   0 0

I’m using grub do i need to do this also?

No, its an optional step I decided to take.

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.

2 Likes

Without stressing an SSD?

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

image

Edit:

Definitely this option increased the amount of writes…

image

Increasing the amount of writings isn’t good for SSD health, is it?

Yes, it’s definitely not good for SSD, as well as using BTRFS which also increase writes…

honka_animated-128px-48

Because of COW, right? But it might be compensated by compression that decreases the writes, right?

1 Like

Yes

I’d say no (meaning yes, but not really enough to be compensated)

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/

Well, maybe it should be the same, but in reality you can prove it’s not with iotop :laughing:

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 :wink:

As far as my own settings, i’ve always:

  1. For SSDs Removed continuous trim, which is discard in /etc/fstab
  2. Enabled periodic trim via fstrim.timer service
  3. Set udev rules as: bfq scheduler for normal SSDs, No scheduler for NVMEs, mq-deadline for HDDs

Thanks anyway! I’ll see whether I can do some experiments myself. Of course I use fstrim timer myself.

1 Like