Bug 243683

Summary: Need to add quirk for Micron 5300 series of ssd drives
Product: Base System Reporter: Vitalij Satanivskij <satan>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Not Accepted    
Severity: Affects Only Me CC: imp, markj
Priority: --- Keywords: patch
Version: 12.1-STABLE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
Adding quirk to disable UNMAP/TRIM for Micron 5300 SSD none

Description Vitalij Satanivskij 2020-01-28 21:58:13 UTC
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
Comment 1 Warner Losh freebsd_committer freebsd_triage 2020-02-05 03:43:20 UTC
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...
Comment 2 Vitalij Satanivskij 2020-02-05 08:30:46 UTC
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?
Comment 3 Warner Losh freebsd_committer freebsd_triage 2020-02-06 01:01:44 UTC
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.
Comment 4 Vitalij Satanivskij 2020-02-06 09:06:14 UTC
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 ^).