Date: Fri, 15 Apr 2016 08:26:23 -0600 From: Warner Losh <imp@bsdimp.com> To: "O. Hartmann" <ohartman@zedat.fu-berlin.de> Cc: Warren Block <wblock@wonkity.com>, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: Heads up Message-ID: <CANCZdfrPu9Z4aC34Nsm9%2BbGh86Gn8vuaez84w=xWfjNjxu=ZwA@mail.gmail.com> In-Reply-To: <20160415155143.0faa8204@freyja.zeit4.iv.bundesimmobilien.de> References: <CANCZdfpnYnVrvhNagYUT9RhAuC1AMCrxh=GCt8RKT0bqxuJybw@mail.gmail.com> <alpine.BSF.2.20.1604142154240.8359@wonkity.com> <CANCZdfqEWDLrHndKf8ZND1mM7spK9cq%2BnfnA79EVEaSj-MJfFA@mail.gmail.com> <20160415155143.0faa8204@freyja.zeit4.iv.bundesimmobilien.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Apr 15, 2016 at 7:51 AM, O. Hartmann <ohartman@zedat.fu-berlin.de> wrote: > On Thu, 14 Apr 2016 22:19:23 -0600 > Warner Losh <imp@bsdimp.com> wrote: > > > On Thu, Apr 14, 2016 at 9:56 PM, Warren Block <wblock@wonkity.com> > wrote: > > > > > On Thu, 14 Apr 2016, 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. > > > > > > > > > > > Is the list of drives queryable? Is there an easy way to tell if the > > > currently-connected drives are on the list? > > > > > > > /usr/src/sys/cam/ata/ata_da.c has the list. > > > > dmesg will tell you if it detected a bad one since it prints the drive's > > quirks. > > But that's no big deal, because the bad one work just fine if you never > > issue > > a NCQ TRIM. This small group of drives were early adapters of this > > technology > > > > Here's the full list of known rogues: > > > > Crucial/Micron M500 (all firmware prior to MU07) > > Micron M510 MU01 firmware (newer firmware is good) > > Crucial/Micron M550 MU01 firmware (newer firmware is good) > > Crucial MX100 MU01 firmware (newer firmware is good) > > FCCT M500 all firmware > > Samsung 830 all firmware > > Samsung 840 all firmware > > Samsung 850 all firmware > > This is funny, > > ALL of our Fujitsu Workstations and those I use pprivate do have Micron SSD > drives (Fujitsu) and Samsung SSD (830 and 840). > Which Micron drives? I'm not familiar with the 'Fujitsu' model for that line. The newer ones are fine, the ones listed above with the MU01 firmware being bad have MU02 firmware (or newer) available that fixes the problem. The M500's firmware exists, but I don't know how available it is. So for Micron, solutions to the problem exist. The 830 and 840 apparently claim support, but are in the class of drives that simply fail to actually work in what may be a reasonable way to detect. There's code to do the fallback in there now, but I'm not so sure that it is working given some of the reports I've seen. Maybe I need to try to but a couple of these drives to see. So - they are the most popular/used drives in a more "professional" > environment these days and they get blacklisted :-( > At least for the micron drives, you don't want to use NCQ trim on the versions listed. It's data corruption roulette. For newer drives, it is fine. The performance will certainly be no worse than it was before my commit. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrPu9Z4aC34Nsm9%2BbGh86Gn8vuaez84w=xWfjNjxu=ZwA>