[7.1.2] SSD Trim Being Added Regardless of Settings

I am using an old HP Blade Server to host one of my UnRaid servers, however there are two drives in a pool which are enterprise SSD's that do not support TRIM. (Mostly due to the HBA in IT Mode not supporting Trim). I have Trim disabled on the pool "Autotrim off" and disabled in the scheduler.

When running grep on the btrfs pool, I can confirm "discard=async" is provided in the mount point.

root@DreamRuby:~# mount | grep btrfs
/dev/sdb1 on /mnt/data type btrfs (rw,noatime,ssd,discard=async,space_cache=v2,subvolid=5,subvol=/)

Because of this my console is spammed with a bunch of trim errors that are causing an I/O issue with my system:

May 28 19:30:30 DreamRuby kernel: I/O error, dev sdf, sector 2365448 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#159 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#159 Sense Key : 0xb [current] 
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#159 ASC=0x4b ASCQ=0x6 
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#159 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
May 28 19:30:32 DreamRuby kernel: I/O error, dev sdf, sector 132780032 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#165 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#165 Sense Key : 0xb [current] 
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#165 ASC=0x4b ASCQ=0x6 
May 28 19:30:32 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#165 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
May 28 19:30:32 DreamRuby kernel: I/O error, dev sdf, sector 134352896 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#171 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#171 Sense Key : 0xb [current] 
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#171 ASC=0x4b ASCQ=0x6 
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#171 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
May 28 19:30:33 DreamRuby kernel: I/O error, dev sdf, sector 136450048 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#177 UNKNOWN(0x2003) Result: hostbyte=0x0b driverbyte=DRIVER_OK cmd_age=0s
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#177 Sense Key : 0xb [current] 
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#177 ASC=0x4b ASCQ=0x6 
May 28 19:30:33 DreamRuby kernel: sd 1:0:5:0: [sdf] tag#177 CDB: opcode=0x42 42 00 00 00 00 00 00 00 18 00
May 28 19:30:33 DreamRuby kernel: I/O error, dev sdf, sector 138547200 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0

To suppress these messages, once the system is booted, I have to run the following command after stopping Docker:

umount /mnt/data
mount -o noatime,ssd,nodiscard,space_cache=v2,subvolid=5,subvol=/ UUID=88ed66b2-0ecd-4092-87e2-1cfd597d8f30 /mnt/data

This suppresses the kernel messages and prevents my I/O from locking up due to hundreds of messages being fired in a row; These enterprise drives do not need to be trimmed as per the manufacturer specifications as they are designed for write intensive environments and have robust internal garbage collection and over-provisioning; In most cases, a lot of environments choose to disable trimming due to compatibility issues anyways.

As a work around, I've modified my /boot/config/go file to do the following on boot:

#!/bin/bash
# Start the Management Utility
/usr/local/sbin/emhttp &

# Wait for array to mount completely
echo "Waiting for array to start..."
sleep 20
while ! mountpoint -q /mnt/data; do
  sleep 1
done

# Stop Docker (if auto-start triggered it early)
echo "Stopping Docker..."
/etc/rc.d/rc.docker stop

# Remount /mnt/data without discard=async
echo "Remounting /mnt/data without discard..."
umount /mnt/data
mount -o noatime,ssd,nodiscard,space_cache=v2,subvolid=5,subvol=/ UUID=88ed66b2-0ecd-4092-87e2-1cfd597d8f30 /mnt/data

# Start Docker again
echo "Starting Docker..."
/etc/rc.d/rc.docker start

This ensures my docker containers are stopped before the umount/mount are triggered, then starts docker after. I am targeting the pool UUID as this does not require me to define a /dev/sd*1 endpoint which will likely change between boots.

Hoping we can get a fix in place that allows the user to disable trim and prevent the discard flags being passed to the mount.

Attached Diagnostics as requested.

dreamruby-diagnostics-20250528-1948.zip

Unraid 7.1.2