Bug 191810 - some SSDs should use UNMAP instead of ATA_TRIM
Summary: some SSDs should use UNMAP instead of ATA_TRIM
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-RELEASE
Hardware: amd64 Any
: --- Affects Many People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-11 18:00 UTC by Michael Brown
Modified: 2024-04-15 21:15 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Brown 2014-07-11 18:00:48 UTC
System: FreeBSD fearless2 10.0-RELEASE-p7 FreeBSD 10.0-RELEASE-p7 #0: Wed Jul 9 12:19:19 EDT 2014 root@fearless2:/usr/obj/usr/src/sys/CAMDEBUG amd64

On my SSDs (IBM TX21B10400GE8IBM) UNMAP should be used instead of ATA_TRIM as UNMAP seems much more reliable.

Using TRIM, I get frequent timeouts:
http://pastie.org/pastes/9368423/text?key=i4gmruxdtjars9fduq8w

(da6:mps1:0:5:0): ATA COMMAND PASS THROUGH(16). CDB: 85 0d 06 00 01 00 03 00 00 00 00 00 00 40 06 00 
(da6:mps1:0:5:0): CAM status: Command timeout
(da6:mps1:0:5:0): Retrying command

Is it possible to default to using UNMAP, if not for everything than for whitelisted devices?
Comment 1 Xin LI freebsd_committer freebsd_triage 2024-04-15 21:10:01 UTC
delete method can now be selected by kern.cam.da.X.delete_method .

Since this is old hardware, we are closing this as overcome by events instead of pretending that this is still being worked on.  If it's still important to distinguish this on modern hardware, please file a new bug with a patch that creates a quirk to disable the use of ATA_TRIM (DA_Q_NO_UNMAP would disable ATA_TRIM too so we can't use that one).
Comment 2 Alexander Motin freebsd_committer freebsd_triage 2024-04-15 21:15:01 UTC
All this story with using ATA_TRIM instead of UNMAP goes to very early days of the technology, when it was faster to bypass HBA firmware translation rather than use it.  I have no idea whether it is still true.  If it is not and somebody (tm) has enough data saying so, it would be nice to remove this hack to simplify the code.