Created attachment 211142 [details]
Adding quirk to disable UNMAP/TRIM for Micron 5300 SSD
Quirks for a Micron 5300 pro sata ssd drive.
When truing to use it in zfs pool find terrible performance caused by zfs sending trim command to ssd. For example samsung PM863a worked in same pool have x 10 better performance. After disable trim via quirks for micron get
performance near or beatter then PM863a. So looks like Micron have troble with
trim/unmap on that type of devices.
In attachment I place quick patch adding quirks to scsi_da.c and ata_da.c
where simply adding quirk for 4k (looks like no needed ) and DA_Q_NO_UNMAP/ADA_Q_NO_TRIM for that's device's.
quirks tested on 12.1-STABLE and 11.2-STABLE
On 11.2 only for for scsi_da.c as quirk ADA_Q_NO_TRIM doesn't exist.
Its will be good if some body can confirm that fix is right and push changes to upstream
Patch again 12.1-STABLE FreeBSD 12.1-STABLE r357144
No, it doesn't need the no trim quirk. That is only for drives where it is broken.
Poor performance should disable it administratively, it might have great performance for other users...
When said "Bad performance" I mean realy bad. It's mean something like 500 random writes. Situation same for all 5300 series ssd we get and on any type of connection (via lsi hba or directly to onboard ahci ports). Does anybody else tested speed and confim that situation not same for then?
The TRIMs work, so we shouldn't proactively disable them. FreeBSD is about tools, not policy. Disabling trim administratively is easy enough. Your workload isn't everybody's work load. There may be some work loads where trims are the right thing, or where you want to TRIM the drive when you newfs or fsck but not operationally. We have knobs to do all those things.
Oh. I'm perfectly understand you logic. It's ok. setting quirks on loader.conf it's good for some corner case but not for bad implemented hardware features.
It's my logic ^).