Date: Thu, 21 May 2015 14:42:09 -0400 From: Neffi <nefftd@gmail.com> To: hackers@freebsd.org Cc: mav@freebsd.org, imp@freebsd.org Subject: Botched NCQ on SSD - cannot disable? Message-ID: <CA%2BK1YHFrxHt5rVU%2BLsH9UN37dr_7or1C7rEB0eHfJisU7sPE0Q@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I was discussing this issue in freenode/#freebsd and I was recommended to shoot an email to you fellows about it. I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses Samsung's own controller from what I can gather. I had issues of mass data corruption when used under Linux, and several programs crashing unexpectedly when used under FreeBSD. I've gone through 2 drives under warranty with the same issue before customer service suggested to disable drive queuing. After some research it seems as though this drive (and several other common SSDs) report that they support NCQ, but in fact are botched and will have all sorts of problems with NCQ enabled ranging from poor performance, to I/O stalls to data corruption. Sure enough the logs on Linux spit out something along the lines of: > ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen > ata1.00: failed command: READ FPDMA QUEUED This happens several times when used on Linux, in the few hours leading up to total filesystem corruption. The recommendation in the Linux world is to disable NCQ on these drives, for which there is an easy boot-time tunable for it. This fixes the issue. No more data corruption. There doesn't seem to be a tunable for this anywhere on FreeBSD. camcontrol(8) mentions setting the tags used, but only between some hardcoded limits, with a default of 2 -- not sufficient to disable NCQ on the drive. It looks like presently the only option is to manually patch the quirks for this drive in the kernel and recompile before I can even install the system to the drive.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BK1YHFrxHt5rVU%2BLsH9UN37dr_7or1C7rEB0eHfJisU7sPE0Q>