B0nes

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