명령 실패의 근본 원인: 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

이러한 현상은 하루에 약 20번 정도 규칙적으로 발생하는 반면, IO는 비교적 드물게 발생합니다. 지금까지 Btrfs 파일 시스템은 체크섬 오류에 대해 불평하지 않았습니다.

그렇다면 이는 단지 삼성이 품질 보증이 좋지 않은 SSD(케이블 손상 가능성 있음)를 판매하는 것일까요, 아니면 삼성이 표준을 준수하는 방식으로 펌웨어에 명령을 적용하지 않는 것처럼 보다 시스템적인 문제일까요?

---

업데이트 2020-01-09:

새로운 대체 삼성 SSD(동일 모델) 생산 가능같은 오류그 NUC에서. 이러한 오류가 발생할 때마다 CRC_ERROR_COUNT SMART 카운터가 1씩 증가합니다.

NUC를 열면 접힌 SATA 케이블이 표시됩니다(왼쪽 하단 모서리 참조).

아마도 이 날카로운 접힘은 인텔이 생산 과정에서 의도적으로 구현한 것일 수도 있습니다. 하지만 그럴 필요는 없을 것 같습니다. 그리고 의도한 것이라면 왜 10% 할인만 한 걸까요? 내 말은, 대칭보다 두 개가 더 의미가 있다는 뜻입니다(SSD가 마더보드 상단에 있기 때문에, 즉 상단 커버에 통합되어 있기 때문입니다). 그리고 접는 방향은 45도가 가장 좋나요? 저는 전기 기술자가 아니기 때문에 이 모든 내용은 이 질문과 전혀 관련이 없을 수도 있습니다.

이 오류를 재현하는 좋은 방법은 fio. 예:

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

이 명령을 연속적으로(예: 연속 두 번) 실행했는데 이 오류가 표시되지 않으면 하드웨어가 양호하고 이 문제가 없다는 의미입니다.