Heads up
Alfred Perlstein
bright at mu.org
Fri Apr 15 03:21:13 UTC 2016
Warner thank you very much.
Sent from my iPhone
> On Apr 14, 2016, at 8:17 PM, Warner Losh <imp at bsdimp.com> wrote:
>
>> On Thu, Apr 14, 2016 at 8:01 PM, Warner Losh <imp at bsdimp.com> wrote:
>>
>>
>>
>>> On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein <bright at 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
>
> kern.cam.ada.X.quirks=0x2
>
> 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
> on.
>
> Warner
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list