왜 NAS 스크럽 오류는 서로 다른 드라이브에서도 하나의 컨트롤러 포트를 따라 발생하나요?

서로 다른 드라이브에서 동일한 컨트롤러 포트를 따라 발생하는 스크럽 오류는 일반적으로 디스크의 기록 매체보다 공유 경로에 문제가 있음을 나타냅니다.

스크럽은 광범위한 블록을 읽기 때문에 일상적인 액세스에서는 나타나지 않는 결함을 드러낼 수 있습니다. 정상으로 확인된 서로 다른 드라이브를 동일한 포트에 연결했을 때만 오류가 발생한다면, 공통 구성 요소로는 컨트롤러 채널, 커넥터, 케이블, 백플레인 레인, 익스팬더 경로, 전원 경로, 펌웨어, 해당 경로 주변의 냉각이 포함됩니다. 진단 과정에서는 드라이브 식별 정보, 타임스탬프, 오류 유형을 유지하면서 오류가 포트를 따라 이동하는지 입증해야 합니다.

드라이브 이름이 아니라 포트를 따라 오류가 이동하는지 확인

다음 스크럽을 실행하기 전에 드라이브 일련 번호, 안정적인 장치 ID, 컨트롤러 포트 또는 HBA PHY, 케이블, 베이, 풀 구성원, 읽기·쓰기·체크섬 카운터를 기록하세요. 변경될 수 있는 /dev/sdX 이름만 사용하지 마세요.

TrueNAS의 드라이브 문제 해결 흐름은 오류를 초기화하거나 장치를 교체하기 전에 풀 및 SMART 증거를 수집할 것을 강조합니다.

전원을 끈 뒤 장치를 교체한 다음, 오류가 드라이브, 베이, 케이블 또는 컨트롤러 포트를 따라 이동하는지 확인하세요. 결과를 해석할 수 있도록 테스트마다 하나의 구성 요소만 변경하세요.

스크럽 체크섬 오류와 드라이브 읽기·쓰기 오류 구분

전체 스크럽 결과와 장치별 카운터를 저장하세요. 체크섬 불일치, 명령 시간 초과, 읽을 수 없는 섹터, 쓰기 실패는 서로 다른 장애 계층을 의미합니다.

Oracle은 ZFS 스크럽이 활성 데이터의 체크섬을 검증한다는 점을 설명하며, 풀 상태는 각 장치의 읽기·쓰기·체크섬 오류를 별도로 보고합니다.

매체 오류 없이 체크섬 오류만 증가하고 특정 물리적 경로를 따라 발생한다면, 메모리와 드라이브 사이의 데이터 손상 또는 불안정한 전송을 의심하세요. 읽기 오류가 포트를 바꿔도 드라이브를 따라 이동한다면 디스크 자체의 가능성이 높아집니다.

디스크를 정확한 컨트롤러와 링크에 매핑

호스트 컨트롤러, PCI 주소, SAS 익스팬더 또는 SATA 포트, 인클로저, 케이블, 베이를 거쳐 안정적인 디스크 경로를 추적하세요. 하드웨어를 이동하기 전에 매핑 정보를 저장하세요.

lspci 장치 보기는 파일 시스템 및 풀 이름과 별개로 PCI 스토리지 컨트롤러를 식별합니다. 이를 통해 새 장치 이름을 받은 디스크가 아니라 고장 난 컨트롤러 경로를 구분할 수 있습니다.

HBA를 사용하는 경우 가능한 한 PHY 및 익스팬더 정보도 포함하세요. 전면 베이 두 개가 서로 다른 슬롯으로 표시되더라도 하나의 미니 SAS 케이블이나 익스팬더 레인을 공유할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

스크럽 중 SATA 또는 SAS 링크 재설정 확인

스크럽이 시작되는 순간부터 커널 로그를 모니터링하세요. 영향을 받은 경로에서 강제 재설정, COMRESET 실패, 링크 다운 이벤트, 명령 시간 초과, 프로토콜 오류, 협상 속도 변경이 발생하는지 확인하세요.

Linux libATA 가이드는 포트별 링크 재설정 및 오류 복구를 설명하며, 특정 ATA 포트에 연결된 반복 메시지가 일반적인 풀 경고보다 더 강력한 증거인 이유를 보여줍니다.

첫 번째 전송 계층 메시지를 보존하세요. 이후의 파일 시스템 오류는 읽기 중 컨트롤러가 통신을 잃은 결과일 수 있습니다.

인터페이스 CRC 및 명령 시간 초과 카운터 비교

스크럽 한 번을 실행하기 전과 후에 각 드라이브의 SMART 속성과 로그를 캡처하세요. 영향을 받은 경로에서만 인터페이스 CRC 또는 명령 시간 초과 카운터가 증가하는지 추적하세요.

Unraid는 UDMA CRC 오류가 드라이브와 컨트롤러 사이에서 발생한다는 점을 설명하며, 일반적으로 플래터 손상보다는 케이블, 커넥터, 배선 또는 컨트롤러 링크가 원인일 가능성이 높습니다.

과거의 CRC 누적 수치만으로는 현재 문제가 있는 구성 요소를 식별할 수 없습니다. 원시 카운트를 기록하고, 범위를 제한한 테스트를 한 번 실행한 뒤 값이 증가했는지만 확인하세요.

스크럽 작업과 별도로 드라이브 테스트 실행

풀이 다른 작업을 거의 수행하지 않고 데이터가 보호된 상태에서 지원되는 SMART 단기 및 확장 테스트를 실행하세요. 다른 스크럽이나 재구축과 동시에 전체 SMART 테스트를 예약하지 마세요.

Debian의 smartctl 참조 문서는 드라이브 내부 자체 테스트 및 오류 로그를 호스트 측 파일 시스템 검증과 구분합니다.

드라이브가 내부 테스트를 통과했지만 특정 컨트롤러 포트에서만 오류를 생성한다면 경로 가설이 더욱 강해집니다. 그렇다고 디스크가 완벽하다는 뜻은 아니므로 포트를 변경한 후에도 계속 모니터링하세요.

공유 구성 요소 하나를 교체하고 범위를 제한한 스크럽 반복

백업이 최신 상태인지 확인하고 서버 전원을 끈 다음, 정상으로 확인된 드라이브를 의심되는 경로에서 이동하거나 다른 변수는 유지한 채 케이블 하나만 교체하세요. 모든 디스크를 동시에 섞어 연결하지 마세요.

ZimaSpace의 디스크 연결 끊김과 불량 베이 구분 가이드는 관련된 제어 교체 방법을 제공합니다. 이 글에서는 그 논리를 특정 컨트롤러 포트를 반복적으로 따라 이동하는 스크럽 오류에 적용합니다.

오류가 빠르게 증가하거나, 동일한 컨트롤러에 연결된 여러 드라이브가 재설정되거나, 풀이 성능 저하 상태가 되거나, 애플리케이션에서 파일 손상을 보고하면 스크럽을 중단하고 데이터 보호를 우선하세요. 동일한 포트 경로에서 새로운 오류 없이 반복적인 스크럽과 정상적인 I/O가 완료된 후에만 문제가 해결된 것으로 볼 수 있습니다.