コマンド失敗の根本原因：WRITE FPDMA QUEUED

新しいSamsung SSD 860 EVO 250GB RVT04B6Qを搭載した新しいIntel NUC（10世代）では、SSDは次のようにいくつかのWRITE FPDMA QUEUEDコマンドエラーを発生させます。

Nov 28 21:25:26  ata3.00: exception Emask 0x10 SAct 0x60 SErr 0x400100 action 0x6 frozen
Nov 28 21:25:26  ata3.00: irq_stat 0x08000000, interface fatal error
Nov 28 21:25:26  ata3: SError: { UnrecovData Handshk }
Nov 28 21:25:26  ata3.00: failed command: WRITE FPDMA QUEUED
Nov 28 21:25:26  ata3.00: cmd 61/40:28:00:d7:31/00:00:00:00:00/40 tag 5 ncq dma 32768 out 
                          res 40/00:28:00:d7:31/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
Nov 28 21:25:26  ata3.00: status: { DRDY }
Nov 28 21:25:26  ata3.00: failed command: WRITE FPDMA QUEUED
Nov 28 21:25:26  ata3.00: cmd 61/20:30:40:d7:31/00:00:00:00:00/40 tag 6 ncq dma 16384 out 
                          res 40/00:28:00:d7:31/00:00:00:00:00/40 Emask 0x10 (ATA bus error)
Nov 28 21:25:26  ata3.00: status: { DRDY }
Nov 28 21:25:26  ata3: hard resetting link
Nov 28 21:25:27  ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300) 
Nov 28 21:25:27  ata3.00: supports DRM functions and may not be fully accessible
Nov 28 21:25:27  ata3.00: supports DRM functions and may not be fully accessible
Nov 28 21:25:27  ata3.00: configured for UDMA/133
Nov 28 21:25:27  ata3: EH complete
Nov 28 21:25:27  ata3.00: Enabling discard_zeroes_data

これらの現象は1日に約20回定期的に発生しますが、IOは比較的まれです。これまで、Btrfsファイルシステムはチェックサムエラーについて文句を言っていませんでした。

それでは、これはサムスンが品質保証の悪いSSD（ケーブル破損の可能性がある）を販売するのでしょうか、それともサムスンが標準に準拠する方法でファームウェアにコマンドを適用しないかのように、よりシステム的な問題でしょうか？

更新 2020-01-09:

新しい代替サムスンSSD（同一モデル）生産可能同じエラーそのNUCで。これらのエラーが発生するたびに、CRC_ERROR_COUNT SMARTカウンタが1ずつインクリメントされます。

NUCを開くと、折りたたまれたSATAケーブルが表示されます（左下隅を参照）。

おそらく、この鋭い折りたたみは、Intelが生産プロセスで意図的に実装したものかもしれません。しかし、そうする必要はないようです。そして意図したのなら、なぜ10％割引だけしたのでしょうか？私の言葉は、対称性よりも2つの意味があります（SSDがマザーボードの上部にあるため、つまり上部カバーに組み込まれているため）。そして折りたたみ方向は45度が一番いいですか？私は電気技術者ではないので、これらの内容はすべてこの質問と全く関係がないかもしれません。

このエラーを再現する良い方法はfio。例:

fio --rw=randrw --name=lol --bs=128k --direct=1 --filename=/dev/nvme0n1 \
    --numjobs=1 --ioengine=libaio --iodepth=32 --refill_buffers

このコマンドを連続的に（たとえば、連続して2回）実行しましたが、このエラーが表示されない場合は、ハードウェアが良好でこの問題がないことを意味します。