On Thu, Apr 14, 2016 at 8:01 PM, Warner Losh <i...@bsdimp.com> wrote:

> On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein <bri...@mu.org> wrote:
>> On 4/14/16 3:42 PM, Warner Losh wrote:
>>> The CAM I/O scheduler has been committed to current. This work is
>>> described
>>> in https://people.freebsd.org/~imp/bsdcan2015/iosched-v3.pdf though the
>>> default scheduler doesn't change the default (old) behavior.
>>> One possible issue, however, is that it also enables NCQ Trims on ada
>>> SSDs.
>>> There are a few rogue drives that claim support for this feature, but
>>> actually implement data corrupt instead of queued trims. The list of
>>> known
>>> rogues is believed to be complete, but some caution is in order.
>>> Yowch...
>> With data at stake wouldn't a whitelist be better along with a tool for
>> testing it?
>> Example, you have whitelist and blacklist, if the device isn't on either
>> list you output a kernel message and suggest they run a tool to "test" the
>> controller and report back the findings?
> The only way to test it is to enable it. Run it for a day or six. If your
> data goes away, the drive is a lying sack. There's no tool to detect this
> that I've seen. You run the NCQ trim, it works. You do it again, it works
> again. After a while, if you have a bad drive model, bad things happen that
> are drive model specific.
> Did I mention that the black list matches Linux's black list and that only
> a tiny number of drive models lie. I guess I didn't.

I just sync it back up to the Linux list. This list has been stable for the
past year or so, with only one entry added back in August. All the other
entries came early in Linux's tables. I did add a quirk to allow it on the
Micron/Crucial M500 with MU07 firmware, but only because I've personally
tested that on dozens of drives over the past 6 months under Netflix
streaming video loads after getting the new firmware.

> I am thinking of adding a tunable to turn it off though for people that
> are paranoid.

Actually, since it is already  a quirk, you can use the tunable


to disable NCQ trim. You can change it to 0x3 if you need 4k sectors as
well. So there's no need to change anything to be able to disable it. Given
how long Linux has been in the wild with NCQ enabled (approximately 18
months), I'm guessing their quirk list is going to be fairly complete. I
have no other systems to cross check this with, but would welcome pointers
if I've overlooked something. I did this bit of code about 15 months ago,
but it wasn't until 6 months ago that I had working SSD firmware to test it

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to