วิธีการตรวจสอบการโจมตีระบบไฟล์ 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

ดังนั้นคุณสามารถสร้าง cronjob รูตแบบง่าย:

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

การดำเนินการนี้จะตรวจสอบความผิดพลาดเชิงบวกที่มีค่าทุกชั่วโมงและส่งอีเมลถึงคุณ เห็นได้ชัดว่าคุณจะทดสอบสถานการณ์ดังกล่าว (ตัวอย่างเช่นก่อให้เกิดความเสียหายหรือลบ grep) เพื่อตรวจสอบว่าการแจ้งเตือนอีเมลทำงาน

นอกจากนี้ด้วยระบบไฟล์ขั้นสูงเช่น BTRFS (ที่มีการตรวจสอบ) มักจะแนะนำให้กำหนดเวลาการขัดทุกสองสามสัปดาห์เพื่อตรวจสอบความเสียหายเงียบที่เกิดจากไดรฟ์ที่ไม่ดี

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

-Bตัวเลือกที่จะทำให้ขัดในเบื้องหน้าเพื่อที่คุณจะเห็นผลใน cron อีเมลที่ส่งให้คุณ มิฉะนั้นจะทำงานในพื้นหลังและคุณจะต้องจำไว้ว่าให้ตรวจสอบผลลัพธ์ด้วยตนเองเนื่องจากไม่ได้อยู่ในอีเมล

ปรับปรุง : ปรับปรุง grep ตามคำแนะนำของ Michael Kjörlingขอบคุณ

อัปเดต 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

อาจมีข้อความแสดงข้อผิดพลาดเป็นจำนวนมากในช่วงเวลานั้นดังนั้นการ grepping dmesg จึงอาจไม่น่าเชื่อถือ
สำหรับเซิร์ฟเวอร์ที่ใช้ BTRFS อาจเป็นความคิดที่จะมีการตรวจสอบที่กำหนดเอง (งาน cron) ที่ส่งการแจ้งเตือนหากอย่างน้อยหนึ่งไดรฟ์ในอาร์เรย์ RAID หายไปนั่นคือไม่สามารถเข้าถึงได้อีกต่อไป ...

ในฐานะของสถิติ btrfs-progs v4.11.1 มีตัวเลือก --check ที่จะส่งคืนค่าที่ไม่ใช่ศูนย์หากค่าใด ๆ ไม่ใช่ศูนย์ทำให้ไม่จำเป็นต้องใช้ regex

สถิติอุปกรณ์ -c /

ฉันจะไม่พึ่งพาคำสั่ง stats สำหรับการแจ้งเตือนข้อผิดพลาดเนื่องจากคำสั่งนี้จะส่งคืนข้อผิดพลาดหากไดรฟ์หายไปทันที คุณสามารถทดสอบได้โดยถอดสายเคเบิล SATA หรือดึงไดรฟ์ - ไม่แนะนำให้ใช้กับระบบไฟล์ที่สำคัญ

btrfs device stats /

หลังจากรีบูต btrfs จะแสดงไดร์ฟที่หายไป แต่อาจจะสายเกินไป

btrfs fi show

ดูเหมือนจะไม่มี daemon หรือยูทิลิตี้ที่รายงานเหตุการณ์ BTRFS อย่างเป็นทางการสำหรับการจัดการผู้ใช้ ทางเลือกที่ใกล้เคียงที่สุดคือการตรวจสอบบันทึกระบบเพื่อดูข้อความจาก BTRFS และตอบสนองตามนั้น

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

ลิงค์ด้านบนให้รายละเอียดเพิ่มเติมสำหรับการกำหนดค่าสคริปต์ ( secแพ็คเกจบน Debian หรือSEC ) ที่ออกแบบมาสำหรับการตรวจสอบบันทึกการใช้งานทั่วไปเพื่อดำเนินการกับข้อความบันทึกที่ไม่คาดคิดเกี่ยวกับ BTRFS นอกจากนี้ยังขึ้นอยู่กับการขัดระบบไฟล์ตามกำหนดเวลาเป็นประจำเพื่อตรวจสอบบิต - เน่าและปล่อยรายการบันทึกเป็นมาตรการป้องกัน ด้านล่างนี้เป็นข้อความที่ตัดตอนมาเฉพาะสำหรับสคริปต์ SEC:

วิธีกำหนดค่าวินาที, ตัวเชื่อมโยงเหตุการณ์เพื่อรายงานข้อผิดพลาดหรือคำเตือนของระบบไฟล์ btrfs

หลังจากติดตั้ง sec.pl (apt-get install sec บน debian หรือhttp://simple-evcorr.sourceforge.net/ ) ให้ติดตั้งไฟล์กำหนดค่า 2 ไฟล์ด้านล่าง

สิ่งนี้ไม่สามารถป้องกันความผิดพลาดได้โดยอาศัยข้อความที่รู้จักเป็นปกติและรายงานข้อความที่ไม่รู้จักทั้งหมด คุณสามารถขยาย regex เชิงลบที่มองไปข้างหน้าได้ตามต้องการ

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

ฟังดูเหมือนเป็นภารกิจสำหรับการตรวจสอบระบบ มีการตรวจสอบซึ่งจะนำ API ของ Nagios ปลั๊กอินที่เรียกว่าที่มีอยู่: check_btrfs อย่างที่คุณเห็นในซอร์สโค้ดมันมีฟังก์ชั่นที่เรียกว่าการcheck_dev_statsตรวจสอบสถิติอุปกรณ์และจะไปสำคัญถ้ามีค่าใด ๆ ที่ไม่ใช่ศูนย์ นอกจากนี้ยังตรวจสอบปัญหาการจัดสรร สิ่งที่ยังคงไม่มีความชัดเจนเป็นวิธีการตรวจสอบพฤติกรรมหากดิสก์ไม่อยู่หรือไปแบบออฟไลน์

PS: ปลั๊กอินได้รับการบรรจุใน Debian: monitoring-plugins-btrfs