From owner-freebsd-current@freebsd.org Fri Apr 15 03:21:13 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A8951AECCA5 for ; Fri, 15 Apr 2016 03:21:13 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (elvis.mu.org [IPv6:2001:470:1f05:b76::196]) by mx1.freebsd.org (Postfix) with ESMTP id 9AD291E55 for ; Fri, 15 Apr 2016 03:21:13 +0000 (UTC) (envelope-from bright@mu.org) Received: from [IPv6:2600:1010:b040:7794:6d50:ded9:5128:da7a] (unknown [IPv6:2600:1010:b040:7794:6d50:ded9:5128:da7a]) by elvis.mu.org (Postfix) with ESMTPSA id EFA13346DE30; Thu, 14 Apr 2016 20:21:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: Heads up From: Alfred Perlstein X-Mailer: iPhone Mail (13E238) In-Reply-To: Date: Thu, 14 Apr 2016 20:21:11 -0700 Cc: FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <57104251.5080102@mu.org> To: Warner Losh X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 03:21:13 -0000 Warner thank you very much.=20 Sent from my iPhone > On Apr 14, 2016, at 8:17 PM, Warner Losh wrote: >=20 >> On Thu, Apr 14, 2016 at 8:01 PM, Warner Losh wrote: >>=20 >>=20 >>=20 >>> On Thu, Apr 14, 2016 at 7:22 PM, Alfred Perlstein wrote:= >>>=20 >>>=20 >>>=20 >>>> On 4/14/16 3:42 PM, Warner Losh wrote: >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>>=20 >>>> Yowch... >>>=20 >>> With data at stake wouldn't a whitelist be better along with a tool for >>> testing it? >>>=20 >>> 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" t= he >>> controller and report back the findings? >>=20 >>=20 >> 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 th= at >> are drive model specific. >>=20 >> Did I mention that the black list matches Linux's black list and that onl= y >> a tiny number of drive models lie. I guess I didn't. >=20 > I just sync it back up to the Linux list. This list has been stable for th= e > 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. >=20 >=20 >> I am thinking of adding a tunable to turn it off though for people that >> are paranoid. >=20 > Actually, since it is already a quirk, you can use the tunable >=20 > kern.cam.ada.X.quirks=3D0x2 >=20 > 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. Give= n > 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 i= t > on. >=20 > Warner > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= >=20