On 1/7/19 8:41 AM, Sitsofe Wheeler wrote:
On Mon, 7 Jan 2019 at 07:17, Hannes Reinecke <hare@xxxxxxx> wrote:
On 1/4/19 8:33 AM, Sitsofe Wheeler wrote:
Blimey Laurence - you're really pushing the boat out on this one!
[ .. ]
I've yet to attach the disk directly to the mobo. It's a bit fiddly as
the most accessible port is meant for the DVD drive and I think it's
speed is slower than the others.
The speed of the ATA ports is lower than you might expect (this
machine is fairly old):
[ .. ]
[ 3.242623] ata2.00: FORCE: horkage modified (noncq)
[ 3.242683] ata2.00: supports DRM functions and may not be fully accessible
[ 3.242686] ata2.00: ATA-11: Samsung SSD 860 EVO 500GB, RVT01B6Q,
max UDMA/133
[ 3.242689] ata2.00: 976773168 sectors, multi 1: LBA48 NCQ (not used)
[ 3.245518] ata2.00: supports DRM functions and may not be fully accessible
[ 3.247611] ata2.00: configured for UDMA/133
'slower' is an understatement.
Are you surprised that there would be such a dramatic difference in
the speeds between the two SSDs (Samsung 860 EVO, Crucial MX500) on
that particular workload in that same machine?
Not at all.
That adapter can't do NCQ, hence 'WRITE FPDMA QUEUED' (which _is_ an NCQ
command) will never be issued.
So I'd be _very_ surprised if you still see this problem there ...
I'm curious, why would using the libata.force=2.00:noncq kernel
command line (only mentioned in my very first mail) make using that
drive more stable if the adapter could never accept that command
anyway? Shouldn't the sending of that command have been disabled if
anything along the way can't actually accept it?
'WRITE FPDMA QUEUED' will ever be issued if the drive _and_ adapter can
do NCQ. As this is the offending command it's not surprising that
switching off NCQ (and hence the use of that command) will make the
machine more stable.
Although I'd be curious about the 'more' bit in 'more stable'.
I would have thought that the machine would be stable after disabling
NCQ; do you still see issues after disabling NCQ?
As for the NCQ issues: it might be that the adapter has issues with NCQ
(quite some older adapters do).
It might also be a problem with the _previous_ command which failed; can
you enable libata tracing to figure out the command flow?
Cheers,
Hannes
--
Dr. Hannes Reinecke Teamlead Storage & Networking
hare@xxxxxxx +49 911 74053 688
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton
HRB 21284 (AG Nürnberg)
