Date: Sat, 27 Apr 2024 18:36:38 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277992] mpr and possible trim issues Message-ID: <bug-277992-227-gbR7SchWnG@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277992-227@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=277992 --- Comment #9 from mike@sentex.net --- 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.home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277992-227-gbR7SchWnG>