BTRFS 파일 시스템을 모니터링하여 오류를 확인하는 방법은 무엇입니까?

다양한 BTRFS 이벤트에 대해 프로그램 / 스크립트를 실행할 수있는 데몬에 대한 문서를 보았지만 더 이상 찾을 수 없습니다.

BTRFS raid1 어레이의 드라이브 오류에서 스크립트 / 프로그램을 실행하려면 어떻게해야합니까? 잠재적으로 고장난 드라이브에 대한 조기 경고로 작동하기 위해 오류에 대해 스크립트를 실행하고 싶지만 실제 드라이브 고장이 가장 중요합니다. 그 시점에서 파일 시스템을 마운트 해제하고 (BTRFS가 수행하지 않는 경우) 알람을 설정하고 싶습니다.

일반 로깅 시스템 외에도 BTRFS에는 stats 명령 이있어 드라이브 당 오류 (읽기, 쓰기 및 손상 / 체크섬 오류 포함)를 추적합니다.

# 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

따라서 간단한 루트 크론 작업을 만들 수 있습니다.

MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'

이렇게하면 매시간 긍정적 인 오류 수를 확인하고 이메일을 보냅니다. 전자 메일 알림이 작동하는지 확인하기 위해 이러한 시나리오 (예 : 손상 또는 grep 제거)를 테스트해야합니다.

또한 BTRFS (체크섬 기능이있는)와 같은 고급 파일 시스템의 경우 불량 드라이브로 인한 자동 손상을 감지하기 위해 2 주마다 스크럽을 예약하는 것이 좋습니다.

@monthly /sbin/btrfs scrub start -Bq /data

이 -B옵션은 스크럽을 포 그라운드로 유지하므로 전자 메일 cron이 보내는 결과를 볼 수 있습니다. 그렇지 않으면 백그라운드에서 실행되며 결과가 전자 메일에없는 것처럼 수동으로 확인해야합니다.

업데이트 : Michael Kjörling이 제안한 grep이 향상되었습니다.

업데이트 2 : 스크러빙 및 일반 읽기 작업에 대한 추가 참고 사항 (BTRFS에만 적용되는 것은 아님) :
Ioan이 지적한 것처럼, 스크럽은 어레이의 크기와 유형 (및 기타 요인)에 따라 경우에 따라 하루 이상이 소요될 수 있습니다. 그리고 그것은 능동 스캔이며 향후 오류를 감지하지 못합니다. 스크럽의 목표는 해당 시점에서 드라이브의 오류를 찾아 수정하는 것입니다. 그러나 다른 RAID 시스템과 마찬가지로 주기적 스크럽을 예약하는 것이 좋습니다. 파일 읽기와 같은 일반적인 I / O 작업이 읽은 데이터가 실제로 올바른지 확인하는 것은 사실입니다. 그러나 간단한 미러를 고려하십시오-파일의 첫 번째 사본이 손상 될 드라이브로 인해 손상되었지만 정확한 두 번째 사본이 실제로 BTRFS에서 읽 히면 BTRFS는 손상이 있음을 알 수 없습니다 드라이브 중 하나에. 요청 된 데이터가 수신 되었기 때문입니다.즉, 한 드라이브에서 손상된 것으로 알고있는 파일을 특별히 읽더라도이 읽기 작업으로 손상이 감지 될 것이라는 보장은 없습니다.
이제 BTRFS가 정상 드라이브에서만 읽은 것으로 간주하고 불량 드라이브의 손상을 감지하는 스크럽이 실행되지 않으며 양호한 드라이브도 불량으로 간주됩니다. 결과는 데이터 손실입니다 (적어도 BTRFS는 어떤 파일이 여전히 올바른지 여전히 읽을 수 있습니다). 물론 이것은 간단한 예입니다. 실제로 BTRFS는 항상 한 드라이브에서 읽고 다른 드라이브를 무시하지는 않습니다.
그러나 요점은 정기적 인 스크럽은 정기적 인 읽기 작업이 반드시 감지 할 수없는 오류를 찾아서 수정하기 때문에 중요하다는 것입니다.

고장난 드라이브 :이 질문은 매우 인기가 있기 때문에이 "모니터링 솔루션"은 불량 드라이브의 문제를 감지하기위한 것입니다 (예 : 드라이브를 죽이면 오류가 발생하지만 여전히 액세스 할 수 있음).

반면에 드라이브가 갑자기 사라지면 (죽어 가거나 오류가 발생하지 않고 연결이 끊어 지거나 완전히 죽었을 경우) 드라이브에 결함이있는 것입니다 (ZFS는 해당 드라이브를 FAULTED로 표시합니다). 불행히도 BTRFS는 파일 시스템이 마운트되는 동안 드라이브가 사라 졌다는 것을 인식하지 못할 수 있습니다.이 메일 링리스트 항목에서 09/2015에서 지적했듯이 (패치되었을 가능성이 있음) :

차이점은 마운트 할 때 존재하지 않는 장치를 감지하는 코드가 있고 마운트 된 파일 시스템에서 떨어지는 장치를 감지하는 코드 (아직)가 없다는 것입니다. 장치가 제대로 감지되지 않는 것이 우선 순위가 아닌 것처럼 보이는 이유는 모르겠지만 마운트 동작과는 별개의 문제입니다.

https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html

그때까지 dmesg에 많은 오류 메시지가 있었으므로 dmesg를 grepping하는 것이 신뢰할 수 없습니다.
BTRFS를 사용하는 서버의 경우 RAID 어레이의 드라이브 중 하나 이상이 사라 졌을 때, 즉 더 이상 액세스 할 수없는 경우 경고를 보내는 사용자 정의 검사 (크론 작업)가있는 것이 좋습니다.

btrfs-progs v4.11.1부터 stats에는 --check 옵션이있어 값이 0이 아닌 경우 0이 아닌 값을 반환하므로 정규식이 필요하지 않습니다.

장치 통계 -c /

드라이브가 갑자기 사라지면 오류를 반환하지 않기 때문에 오류 알림에 stats 명령에 의존하지 않습니다. 중요한 파일 시스템에서는 권장하지 않는 sata 케이블을 분리하거나 드라이브를 당겨서 테스트 할 수 있습니다.

btrfs device stats /

재부팅 후 btrfs는 누락 된 드라이브를 표시하지만 너무 늦을 수 있습니다.

btrfs fi show

사용자 처리를 위해 BTRFS 이벤트를 공식적으로보고하는 데몬이나 유틸리티가없는 것 같습니다. 가장 가까운 대안은 BTRFS의 메시지에 대한 시스템 로그를 모니터하고 이에 따라 대응하는 것입니다.

http://marc.merlins.org/perso/btrfs/post_2014-03-19_Btrfs-Tips_-Btrfs-Scrub-and-Btrfs-Filesystem-Repair.html

위의 링크는 범용 로그 모니터링을 위해 설계된 스크립트 ( secDebian 또는 SEC의 패키지 )가 BTRFS와 관련하여 예기치 않은 로그 메시지에 작동 하도록 구성하는 데 대한 자세한 정보를 제공합니다 . 또한 비트 로트를 점검하고 로그 항목을 선점 적으로 측정하기 위해 정기적으로 파일 시스템을 예약하여 스크러빙해야합니다. 아래는 SEC 스크립트와 관련된 내용입니다.

btrfs 파일 시스템 오류 또는 경고를보고하도록 sec, 이벤트 상관기를 구성하는 방법

sec.pl (debian 또는 http://simple-evcorr.sourceforge.net/ 에 apt-get install sec )을 설치 한 후 아래 2 개의 구성 파일을 설치하십시오.

이것은 완벽하지 않으며 알려진 메시지의 정규식에 의존하며 알 수없는 모든 메시지를보고합니다. 필요에 따라 미래의 부정 정규 표현식을 확장 할 수 있습니다.

polgara:~\# cat /etc/default/sec  
\#Defaults for sec  
RUN_DAEMON="yes"  
DAEMON_ARGS="-conf=/etc/sec.conf -input=/var/log/syslog -pid=/var/run/sec.pid -detach -log=/var/log/sec.log"

polgara:~# cat /etc/sec.conf  
\# http://simple-evcorr.sourceforge.net/man.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article.html  
\# http://sixshooter.v6.thrupoint.net/SEC-examples/article-part2.html  
type=SingleWithSuppress  
ptype=RegExp  
pattern=(?i)kernel.*btrfs: (?!disk space caching is enabled|use ssd allocation|use .* compression|unlinked .* orphans|turning on discard|device label .* devid .* transid|detected SSD devices, enabling SSD mode|has skinny extents|device label|creating UUID tree|checking UUID tree|setting .* feature flag|bdev.* flush 0, corrupt 0, gen 0)  
window=60  
desc=Btrfs unexpected log  
action=pipe '%t: $0' /usr/bin/mail -s "sec: %s" root

시스템 모니터링 작업처럼 들립니다. check_btrfs 라는 Nagios 플러그인 API를 구현하는 검사가 있습니다 . 소스 코드에서 볼 수 있듯이 check_dev_stats장치 통계를 확인 하는 함수 가 있으며 값이 0이 아닌 경우 중요합니다. 또한 할당 문제를 확인합니다. 불분명 한 것은 한 디스크가 없거나 오프라인 상태 인 경우 검사 가 어떻게 작동하는지 입니다.

PS : 플러그인은 데비안에 패키지되어 있습니다 : monitoring-plugins-btrfs