ZFS에 대한 오류 보고 이해(Linux)

일반적인 개요는 다음을 참조하세요.ZFS 문제 해결, 가장 흥미로운 부분은 다음과 같습니다.

구성 출력의 두 번째 부분에는 오류 통계가 표시됩니다. 이러한 오류는 세 가지 범주로 분류됩니다.

• READ – 읽기 요청을 발행할 때 발생한 I/O 오류
• WRITE – 쓰기 요청을 발행하는 동안 발생한 I/O 오류
• CKSUM – 체크섬 오류. 읽기 요청으로 인해 장치가 손상된 데이터를 반환했음을 의미합니다.

이러한 오류는 손상이 영구적인지 확인하는 데 사용될 수 있습니다. I/O 오류 수가 적으면 일시적인 중단을 나타낼 수 있지만 오류 수가 많으면 장치에 영구적인 문제가 있음을 나타낼 수 있습니다. 이러한 오류는 애플리케이션에서 해석한 데이터 손상과 반드시 ​​일치하는 것은 아닙니다. 장치가 중복 구성인 경우 미러 또는 RAID-Z 장치 수준에서는 오류가 발생하지 않지만 장치는 수정할 수 없는 오류를 표시할 수 있습니다. 이 경우 ZFS는 올바른 데이터를 성공적으로 검색하고 기존 복사본에서 손상된 데이터를 복구하려고 시도합니다.

---

이제 귀하의 질문에 대해 :

첫째, 이 맥락에서 "장치"는 무엇을 의미합니까? 물리적 장치, vdev 또는 다른 것에 대해 이야기하고 있습니까? 내 가정은 그들이 계층 구조의 각 "장치"에 대해 이야기하고 있다는 것입니다. 그런 다음 vdev의 오류 수는 물리적 장치 오류 수의 합계일 수 있고 풀의 오류 수는 vdev 오류 수의 합계일 수 있습니다. 맞습니까?

각 장치는 자체적으로 모든 오류를 독립적으로 검사하고 요약합니다. 이러한 오류가 두 미러 모두에 존재하거나 vdev 자체가 중복되지 않으면 위쪽으로 전파됩니다. 즉, vdev 자체에 영향을 미치는 오류의 양입니다(각 줄을 개별적으로 표시하는 논리에도 적합합니다).

하지만 제가 정말로 관심을 갖는 것은 ZFS 수준(하드웨어 수준이 아님)에 체크섬 오류가 있는지 여부입니다. 나는 현재 CKSUM이 후자를 보여주고 있다고 확신하지만(그렇지 않으면 별 의미가 없을 것임) 확신하고 싶습니다.

예, 하드웨어 측면입니다(케이블 결함, 갑자기 제거된 디스크, 정전 등과 같은 비영구적인 문제). 나는 이것이 또한 요점이라고 생각합니다. "소프트웨어 측" 오류는 ZFS 자체에 버그가 있음을 의미하므로 확인되지 않은(모든 일반적인 사용자 상호 작용이 올바른 것으로 간주된다는 가정 하에) 잘못된 동작이 ZFS 자체에서 인식되지 않는다는 의미입니다. 다행히 요즘에는 그런 일이 거의 없습니다. 불행히도, 그들은 또한 대부분의 경우 매우 심각합니다.

셋째, 그들이 말하는 체크섬 오류가 실제로 하드웨어 수준이 아닌 ZFS 수준 체크섬 오류라고 가정하면 도대체 왜 수정할 수 없는 오류 수만 표시합니까? 이것은 말이 되지 않습니다. 우리는 수정 가능 여부에 상관없이 모든 체크섬 오류를 확인하고 싶습니다. 그렇지 않습니까? 결국, 체크섬 오류는 하드웨어가 아직 감지하지 못한 디스크의 데이터 손상이 있음을 의미하므로 오류가 발생하기 직전에 이를 변경하고 싶을 것입니다(미러링된 디스크가 여전히 작동할 수 있는 경우에도). "백업"). 그래서 아마도 "수정 불가능"이 실제로 무엇을 의미하는지 아직도 이해하지 못할 수도 있습니다.

결함이 있는 디스크는 읽기/쓰기 오류(예: 디스크의 URE)로 표시되었습니다. 체크섬 오류는 설명하는 것입니다. 블록을 읽고 트리에서 그 위에 있는 블록의 체크섬은 반환 값이 올바르지 않다고 생각하여 반환하는 대신 삭제되고 오류로 표시됩니다. "수정 불가능"은 대략적인 정의입니다. 왜냐하면 쓰레기가 발생하고 그것이 쓰레기라는 것을 알면 수정할 수 없지만 무시하고 사용하지 않을(또는 다시 시도할) 수 있기 때문입니다. 그러나 이러한 표현은 불필요한 혼란을 야기할 수 있습니다.

이 단락에 따르면 데이터 손상 오류와 장치 오류라는 두 가지 유형의 오류가 발생할 수 있습니다. 두 디스크의 미러링 구성은 의심할 여지 없이 중복되므로 해당 단락에 따라 ZFS가 디스크 중 하나(하드웨어 수준이 아닌 ZFS 체크섬 수준에서)에서 체크섬 오류가 발생하는 경우 이는 데이터 손상 오류가 아닙니다. 이는 해당 단락에 따라 오류가 지속적인 오류 로그의 일부로 기록되지 않음을 의미합니다.

데이터 손상이 단락의 내용은 일부 파일이 부분적으로 또는 완전히 손상되어 읽을 수 없으므로 마지막 백업을 가져와 가능한 한 빨리 교체해야 함을 의미합니다. ZFS의 모든 예방 조치가 실패하여 더 이상 도움이 될 수 없는 경우(그러나 다음번에 디스크 검사가 실행될 때 서버가 시작될 때보다는 지금 알림을 받게 됩니다).

나에게 ZFS로 전환하는 주된 이유는 자동 비트 감쇠를 자체 감지하는 기능, 즉 하드웨어/드라이버 수준에서 I/O 오류를 일으키지 않는 경우에도 장치의 오류를 감지하고 보고하는 기능입니다. 그러나 영구 로그에 이러한 오류를 포함하지 않으면 재부팅 시 해당 오류가 손실되어 치명적일 수 있습니다(IMHO).

ZFS 시스템의 기본 개념은 파일 시스템을 온라인으로 확인할 수 있기 때문에 이러한 오류를 감지하기 위해 시스템을 종료할 필요가 없다는 것입니다. 10년 전, 이는 당시 대부분의 소규모 시스템에는 없었던 기능이었습니다. 따라서 (물론 중복 구성에서) 하드웨어의 읽기 및 쓰기 오류를 확인하고 잘 알려진 복제본을 사용하여 수정할 수 있다는 아이디어입니다. 또한 매월 스크러빙을 수행하여 모든 데이터를 읽고(읽지 않은 데이터가 좋은지 알 수 있는 방법이 없으므로) 발견된 오류를 수정할 수 있습니다.

그것은 커다란 오래된 책 보관소/도서관과 같습니다. 귀중한 책이 있고 덜 가치 있는 책이 있고, 일부는 시간이 지남에 따라 썩을 수 있으므로 매주 또는 매월 확인하려면 한 사람이 필요합니다. 책의 모든 페이지는 다음과 같습니다. 곰팡이, 오류 등을 발견하면 그는 당신에게 말할 것입니다. 동일한 도서관이 두 개 있는 경우 다른 건물로 가서 같은 페이지에서 같은 책을 보고 첫 번째 도서관의 손상된 페이지를 복사본으로 바꿀 수 있습니다. 만일 그가 책을 확인하지 않았다면 20년 후에 끔찍한 사고를 당했을지도 모릅니다.

이 주제에 대해 더 많이 생각하고 user121391의 답변을 여러 번 읽은 후 user121391의 진술을 더 명확히하기 위해 내 질문에 답변하고 싶습니다. 잘못된 점이 있으면 바로잡아주세요.

첫 번째 질문: "장치"는 무엇을 의미합니까?

이것은 user121391에 의해 명확해졌습니다. 의미 있는 내용을 추가할 수 없습니다.

두 번째 및 세 번째 질문: 수정할 수 없는 오류가 무엇인가요?/왜 수정 불가능한 오류인가요?고칠 수 없는오류 카운터에 오류가 표시됩니까?

Sun/Oracle이 선택한 표현은 매우 불분명하고 오해의 소지가 있습니다. 일반적으로 디스크(또는 계층 구조의 하드웨어 구성 요소)에 데이터 무결성 오류가 발생하면 다음 두 가지 상황이 발생할 수 있습니다.

• 오류는 ECC와 같은 메커니즘을 통해 수정될 수 있으며 적절한 구성 요소는 수정 후 데이터를 전달합니다(따라서 관리자가 적절한 도구를 통해 읽을 수 있는 일부 오류 카운터가 증가할 수 있음).

• 실수는 가능하다아니요수정되다. 이 경우 일반적으로 I/O 오류가 발생하여 문제가 발생했음을 하드웨어/드라이버/응용 프로그램에 알립니다.

이제 드물지만 I/O 오류가 발생합니다.아니요있어도 그런 일은 일어날 것이다예전에는아직 수정되지 않은 데이터 무결성 오류입니다. 이는 소프트웨어 결함, 하드웨어 오류 등으로 인해 발생할 수 있습니다. 이것이 제가 개인적으로 "자동 비트 부패"를 의미하는 것이며 제가 ZFS로 전환한 이유입니다. 이러한 오류는 ZFS 자체의 "엔드 투 엔드" 체크섬에 의해 감지됩니다.

그래서,ZFS 체크섬 오류정확히는 데이터(무결성) 오류입니다.하드웨어 수준에서는 I/O 오류가 발생하지 않습니다., 따라서 ZFS 자체 체크섬 이외의 메커니즘으로는 감지할 수 없으며 그 반대의 경우도 마찬가지입니다. 이러한 의미에서 명령의 CKSUM 열에 있는 오류 수는 zpool status -vZFS 체크섬 오류 수와 감지되지 않은 하드웨어 오류 수입니다. 두 숫자가 완전히 동일하기 때문입니다.

즉, 장치가 자체적으로 무결성 오류를 수정하거나(오류를 수정할 수 없는 경우) I/O 오류를 설정하는 경우 ZFS는아니요CKSUM 오류 카운터를 늘렸습니다.

나는 Sun 문서의 이 부분에 대해 매우 우려해 왔습니다. 왜냐하면 "수정할 수 없는 오류"라는 용어가 전혀 설명되지 않아 매우 오해의 소지가 있기 때문입니다. "I/O 오류를 일으키지 않은 수정 불가능한 하드웨어 오류"라고 쓰여 있었다면보통 그래야 하듯이", 문서의 이 부분에는 아무런 문제가 없습니다.

따라서 다시 요약하면 이 경우 "수정 불가능"은 "하드웨어 수준에서 수정 불가능하고 감지되지 않음"(감지되지 않았지만 데이터(무결성) 오류가 있었지만 I/O 발생 오류가 발생하지 않음)을 의미합니다. ZFS 수준"(실제로 내가 아는 한 ZFS는 일종의 오류 수정 체크섬 메커니즘을 통해 개별 디스크의 잘못된 데이터를 수정하려고 시도하지 않지만 체크섬을 사용하여 잘못된 데이터를 식별한 다음 시도합니다. 데이터의 올바른 사본이 있는 경우 데이터를 수정하기 위해다른디스크(미러) 또는 데이터를 디스크(미러)의 데이터로부터 재구성할 수 있는지 여부다른디스크(RAIDZ)).

마지막 질문(영구 로그 관련)

여기서도 Sun의 문서가 잘못되었습니다(또는 적어도 무슨 일이 일어나고 있는지 이해하기 위해 읽어볼 사람이 없을 정도로 오해의 소지가 있음).

분명히 적어도둘영구 로그.

설명서에서 논의된 것 중 하나는 응용 프로그램 I/O 오류(예: 중복 메커니즘을 통해서도 수정할 수 없는 I/O 오류 또는 ZFS의 ZFS 체크섬 오류)로 인해 읽을 수 없는 파일을 자세히 포함하는 로그입니다. 즉, 디스크 수준에서 I/O 오류가 발생했지만 ZFS가 중복 메커니즘(RAIDZ, 미러링)을 통해 오류를 복구할 수 있는 경우 오류는 다음과 같습니다.아니요이 영구 로그에 기록됩니다.

IMHO 이것은 의미가 있습니다. 이 로그의 도움으로 관리자는 백업에서 어떤 파일을 복원해야 하는지 한눈에 알 수 있습니다.

그러나 문서에는 두 번째 영구 "로그", 즉 오류 카운터의 "로그"에 대한 언급이 없습니다. 물론 오류 카운터는 정리 중에 오류가 감지되거나 정상 작동 중에 감지되는지 여부에 관계없이 재부팅 간에 유지됩니다. 그렇지 않으면 ZFS는 의미가 없습니다.

매일 밤 11시에 실행되어 결과를 메일로 보내는 스크립트가 있고 zpool status -v매일 아침 이메일을 확인하여 모든 것이 괜찮은지 확인한다고 상상해 보세요. 어느 날 정오쯤에 ZFS는 디스크 중 하나에서 오류를 감지하고 해당 장치의 I/O 또는 CKSUM 오류 카운터를 증가시키고 오류를 수정한 다음(예를 들어 미러링된 디스크에 올바른 데이터가 있기 때문에) 데이터를 전달합니다. 이 경우에는애플리케이션따라서 입력/출력 오류가 발생합니다.아니요설명서에 언급된 대로 지속적인 오류 로그에 기록합니다.

그때에,I/O 또는 CKSUM 오류 카운터가 유일한 단서입니다.해당 디스크에 문제가 있습니다. 그런 다음 2시간 후에 어떤 이유로 서버를 다시 시작해야 합니다. 시간적 압박이 크고 생산을 계속해야 합니다. 물론 zpool status -v이 경우 재부팅하기 전에 수동으로 실행하지 않을 것입니다(아마도 로그인할 수 없을 것입니다). 이제 ZFS가 별도의 "로그"에 오류 카운터를 기록하지 않으면 디스크 중 하나에 오류가 있다는 정보가 손실됩니다. ZFS의 상태를 확인하는 스크립트는 밤 11시에 실행될 예정인데, 다음날 아침 해당 이메일을 공부해 보면 문제가 없다는 것을 확인하게 되실 겁니다...

따라서 오류 카운터는 어딘가에 영구적으로 저장됩니다("로그"라고 불러야 하는지에 대해 논의할 수 있지만 중요한 점은 zpool status -v재부팅 후 재부팅 직후와 동일한 결과를 표시하도록 영구적으로 저장된다는 것입니다). 이전) . 사실, 제가 아는 한, zpool clear이것이 오류 카운터를 재설정하는 유일한 방법입니다.

나는 Sun/Oracle이 그렇게 불분명한 문서를 작성함으로써 자신들에게 이익을 주고 있다고 생각하지 않습니다. 저는 숙련된 사용자(실제로는 개발자)이고 형편없는 문서를 읽는 데 익숙합니다. 그러나 Sun의 문서는 정말 재앙적입니다. 그들은 무엇을 기대합니까? 실제로 내 디스크 중 하나를 속여 I/O 오류를 생성한 다음 서버를 다시 시작하여 오류 카운터가 보존되는지 확인해야 합니까? 아니면 이렇게 기본적이면서도 중요한 질문에 답하기 위해 소스 코드를 읽어야 할까요?

ZFS/Solaris에 대한 결정을 내려야 한다면 문서를 읽고 결정을 내릴 것입니다. 이 경우 문서를 보면 오류 카운터가 재부팅 후에도 유지되지 않는다는 인상을 받았기 때문에 분명히 반대하기로 결정했습니다. 물론 이는 전혀 받아들일 수 없는 일입니다.

다행히도 ZFS에 관한 다른 기사를 읽은 후 ZFS를 사용해 보았고앞으로Sun의 설명서를 읽어보십시오. 제품은 문서(IMHO)만큼만 우수합니다.