https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992
--- Comment #9 from [email protected] --- I decided to try the same tests on the exact same hardware but booting truenas scale to see if the problem persists. If I do a manual trim between zfs send | zfs recv, the performance seems fairly consistent and there are no crashes/resets of the drives in the pool on linux (6.6.20-production+truenas). Not a linux person so hard to say if there are some quirks for these disks on linux. root@truenas[/var/log]# hdparm -I /dev/sda | grep -i tri * Data Set Management TRIM supported (limit 8 blocks) * Deterministic read data after TRIM root@truenas[/var/log]# If I dont do the manual TRIM between send|recv (ie zpool trim -w pool), I get the same pattern as when I do a manual trim -f /dev/da[x] on each disk one by one on FreeBSD. I get 3 full speed loops and after that, super slow until a proper trim is done. On FreeBSD I do this to the raidz1 pool by doing a trim -f /dev/da[1-4] one by one and resilver. So it does seem to point to TRIM via zfs (be that manual or autotrim) somehow broken with this drive on FreeBSD via the mpr driver or via the ATA driver. -- You are receiving this mail because: You are the assignee for the bug.
