다양한 BTRFS 이벤트에 대한 프로그램/스크립트를 실행할 수 있는 데몬에 대한 일부 문서를 보았지만 더 이상 찾을 수 없습니다.
BTRFS raid1 어레이의 드라이브 오류 시 스크립트/프로그램을 실행하려면 어떻게 해야 합니까? 잠재적인 드라이브 오류에 대한 조기 경고 역할을 하기 위해 모든 오류에 대해 스크립트를 실행하고 싶지만 실제 드라이브 오류가 가장 중요합니다. 그 시점에서 파일 시스템을 마운트 해제하고(BTRFS가 수행하는 작업이 아닌 경우) 경보를 설정하고 싶습니다.
답변1
BTRFS에는 일반 로깅 시스템 외에도 다음이 있습니다.통계드라이브당 오류(읽기, 쓰기 및 손상/체크섬 오류 포함)를 추적하는 명령:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
따라서 간단한 루트 cronjob을 만들 수 있습니다.
[email protected]
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
매 시간마다 긍정적인 오류 수를 확인하고 이메일을 보냅니다. 물론 이러한 시나리오(예: 손상을 유발하거나 grep을 제거하는 등)를 테스트하여 이메일 알림이 작동하는지 확인해야 합니다.
또한 BTRFS(체크섬 기능 포함)와 같은 고급 파일 시스템을 사용하면 불량 드라이브로 인한 자동 손상을 감지하기 위해 2주에 한 번씩 스크럽을 예약하는 것이 좋습니다.
@monthly /sbin/btrfs scrub start -Bq /data
이 -B옵션은 스크럽을 전경에 유지하므로 크론이 보내는 이메일에서 결과를 볼 수 있습니다. 그렇지 않으면 백그라운드에서 실행되며 이메일에 결과가 포함되지 않으므로 수동으로 결과를 확인해야 합니다.
업데이트: Michael Kjörling이 제안한 grep이 개선되었습니다. 감사합니다.
업데이트 2: 스크러빙과 일반 읽기 작업에 대한 추가 참고 사항(BTRFS에만 적용되는 것은 아님):
Ioan이 지적한 대로 스크러빙은 배열의 크기와 유형(및 기타 요인)에 따라 많은 시간이 걸릴 수 있습니다. 어떤 경우에는 하루 이상 걸릴 수도 있습니다. 그리고 이는 활성 스캔이므로 향후 오류를 감지하지 않습니다. 스크럽의 목표는 해당 시점에 드라이브의 오류를 찾아서 수정하는 것입니다. 그러나 다른 RAID 시스템과 마찬가지로 정기적인 스크럽을 예약하는 것이 좋습니다. 파일 읽기와 같은 일반적인 I/O 작업에서는 읽은 데이터가 실제로 올바른지 확인하는 것이 사실입니다. 그러나 간단한 미러를 고려하십시오. 파일의 첫 번째 복사본이 곧 죽을 드라이브에 의해 손상되었지만 올바른 두 번째 복사본이 실제로 BTRFS에서 읽혀지면 BTRFS는 손상이 있음을 알 수 없습니다. 드라이브 중 하나에. 이는 요청된 데이터가 수신되었고 BTRFS가 이 파일에 대해 저장한 체크섬과 일치하므로 BTRFS가 다른 복사본을 읽을 필요가 없기 때문입니다.즉, 한 드라이브에서 손상된 것으로 알고 있는 파일을 구체적으로 읽는 경우에도 이 읽기 작업으로 손상이 감지된다는 보장이 없습니다.
이제 BTRFS가 양호한 드라이브에서만 읽고, 불량 드라이브의 손상을 감지하는 스크럽이 실행되지 않고, 그러면 양호한 드라이브도 불량해진다고 가정해 보겠습니다. 결과는 데이터 손실이 될 것입니다(적어도 BTRFS는 알고 있을 것입니다) 어떤 파일이 여전히 정확하고 해당 파일을 계속 읽을 수 있는지 확인하세요.) 물론 이는 단순화된 예입니다. 실제로 BTRFS는 항상 한 드라이브에서 읽고 다른 드라이브를 무시하지는 않습니다.
그러나 중요한 점은 정기적인 스크러빙을 통해 일반 읽기 작업에서는 반드시 감지할 수 없는 오류를 찾아서 수정하기 때문에 정기적인 스크러빙이 중요하다는 것입니다.
결함이 있는 드라이브: 이 질문은 꽤 인기가 있기 때문에 이 "모니터링 솔루션"은 불량 드라이브의 문제(예: 죽어가는 드라이브가 오류를 일으키지만 여전히 액세스 가능)를 감지하기 위한 것임을 지적하고 싶습니다.
반면에 드라이브가 갑자기 사라진 경우(죽어 오류가 발생하는 것이 아니라 연결이 끊기거나 완전히 작동하지 않는 경우) 드라이브에 결함이 있는 것입니다(ZFS는 해당 드라이브를 FAULTED로 표시함). 불행하게도 BTRFS는 2015년 9월의 메일링 리스트 항목에서 지적한 것처럼 파일 시스템이 마운트되는 동안 드라이브가 사라진 것을 인식하지 못할 수 있습니다(패치되었을 수 있음).
차이점은 마운트 시 장치가 존재하지 않는 것을 감지하는 코드가 있지만 마운트된 파일 시스템에 장치가 떨어지는 것을 감지하는 코드가 (아직) 없다는 것입니다. 장치가 사라지는 것을 적절하게 감지하는 것이 우선순위가 아닌 것처럼 보이는 이유는 잘 모르겠습니다. 하지만 이는 마운트 동작과는 별개의 문제입니다.
https://www.mail-archive.com/[이메일 보호됨]/msg46598.html
그 당시에는 dmesg에 수많은 오류 메시지가 있었으므로 dmesg를 grepping하는 것이 안정적이지 않을 수 있습니다.
BTRFS를 사용하는 서버의 경우 RAID 배열의 드라이브 중 하나 이상이 없어진 경우, 즉 더 이상 액세스할 수 없는 경우 경고를 보내는 사용자 정의 검사(cron 작업)를 갖는 것이 좋습니다.
답변2
btrfs-progs v4.11.1부터 stats에는 값 중 하나라도 0이 아닌 경우 0이 아닌 값을 반환하는 --check 옵션이 있어 정규 표현식이 필요하지 않습니다.
device stats -c /
답변3
오류 알림을 위해 stats 명령을 사용하지 않을 것입니다. 드라이브가 갑자기 사라져도 이 명령은 오류를 반환하지 않기 때문입니다. SATA 케이블을 분리하거나 드라이브를 당겨서 테스트할 수 있습니다. 중요한 파일 시스템에는 권장되지 않습니다.
btrfs device stats /
재부팅 후 btrfs는 누락된 드라이브를 표시하지만 너무 늦을 수 있습니다.
btrfs fi show
답변4
시스템 모니터링 작업인 것 같습니다. 다음과 같은 Nagios Plugin API를 구현하는 검사가 있습니다.check_btrfs. 소스 코드에서 볼 수 있듯이 check_dev_stats장치 상태를 확인하고 값 중 하나라도 0이 아닌 경우 중요한 기능을 수행하는 함수가 있습니다. 또한 할당 문제도 확인합니다. 아직 불분명한 것은하나의 디스크가 없거나 오프라인 상태가 되는 경우 검사 작동 방식.
추신: 플러그인은 Debian에 패키지되어 있습니다:모니터링 플러그인-btrfs