ฉันจะตรวจสอบบล็อกที่ไม่ดีในฟิสิคัลวอลุ่ม LVM ได้อย่างไร

เมื่อคุณกำลังใช้ ext4 คุณสามารถตรวจสอบ badblocks e2fsck -c /dev/sda1 # or whateverกับคำสั่ง นี่จะ "บัญชีดำ" บล็อกโดยการเพิ่มลงในไอดีบล็อก

อะไรคือสิ่งที่เทียบเท่าสำหรับปริมาณทางกายภาพ LVM2? ระบบไฟล์ที่อยู่ในนั้น ext4 แต่น่าจะเป็นบล็อกที่ตรวจพบจะไม่ถูกต้องเนื่องจากการตั้งค่า LVM พื้นฐานย้ายข้อมูลไปรอบ ๆ บนดิสก์ทางกายภาพ

กล่าวอีกนัยหนึ่งฉันจะตรวจสอบบล็อกที่ไม่ดีที่จะไม่ใช้ใน LVM ได้อย่างไร

เมื่อคุณใช้ ext4 คุณสามารถตรวจสอบ badblocks ด้วยคำสั่งe2fsck -c /dev/sda1หรืออะไรก็ตาม นี่จะ "บัญชีดำ" บล็อกโดยการเพิ่มลงในไอดีบล็อก

e2fsck -cทำงานbadblocksบนฮาร์ดดิสก์ต้นแบบ คุณสามารถใช้badblocksคำสั่งโดยตรงบนฟิสิคัลวอลุ่ม LVM (สมมติว่า PV เป็นฮาร์ดดิสก์จริงและไม่ใช่อุปกรณ์เสมือนชนิดอื่นเช่นอุปกรณ์ RAID ซอฟต์แวร์ MD) เช่นเดียวกับที่คุณใช้คำสั่งนั้นบนฮาร์ดดิสก์ ที่มีระบบไฟล์ ext

นั่นจะไม่เพิ่มข้อมูลบล็อกที่ไม่ดีใด ๆ ลงในระบบไฟล์ แต่ฉันไม่คิดว่ามันเป็นคุณสมบัติที่มีประโยชน์ของระบบไฟล์ ฮาร์ดดิสก์ควรจะจัดการกับบล็อกที่ไม่ดี

ดียิ่งขึ้นกว่าที่badblocksใช้งานสมาร์ท selftest บนดิสก์ (แทนที่/dev/sdXด้วยชื่ออุปกรณ์ของฮาร์ดดิสก์ของคุณ):

smartctl -t long /dev/sdX
smartctl -a /dev/sdX | less

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

กล่าวอีกนัยหนึ่งฉันจะตรวจสอบบล็อกที่ไม่ดีที่จะไม่ใช้ใน LVM ได้อย่างไร

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

ฉันค่อนข้างแน่ใจว่า LVM ไม่จัดการบล็อกที่ไม่ดี มันคาดว่าการจัดเก็บข้อมูลพื้นฐานที่จะ และที่สำคัญที่สุดถ้าไม่ใช่ทั้งหมดฮาร์ดดิสก์รุ่นใหม่ทำได้ คุณอาจต้องทำการเขียนไปยังเซกเตอร์ แต่ดิสก์ควรทำการแมปใหม่ (คุณอาจต้องทำการสแกนพื้นผิวออฟไลน์ก่อนด้วยเช่น, smartctl /dev/sda -t offline)

ที่กล่าวว่า LVM ไม่ได้ย้ายข้อมูลไปรอบ ๆ เว้นแต่คุณจะถามเช่นpvmoveด้วย ดังนั้นคุณสามารถใช้คุณสมบัติ ext4 badblocks pvmoveคุณก็จะต้องตรวจสอบอีกครั้งสำหรับบล็อกเสียถ้าวิ่ง ไม่มีการดำเนินการทั่วไป (เช่นlvextend) ย้ายข้อมูล

ส่วนขยายไม่ย้ายข้อมูลเนื่องจาก LVM เก็บแผนที่โดยบอกว่า "ส่วนขยายตรรกะ 0–99 เป็นส่วนขยายทางกายภาพ 200–299" และเมื่อคุณขยายมันจะเพิ่ม "ตรรกะส่วนขยาย 100–199 เป็นส่วนขยายทางกายภาพ 100–199" หรือแม้แต่ "ขอบเขตเชิงตรรกะ 100–149 เป็นขอบเขตทางกายภาพ 50–99; ขอบเขตเชิงตรรกะ 150–199 เป็นขอบเขตเชิงกายภาพ 140–189" LVM ไม่สนใจว่าขอบเขตทางกายภาพไม่เป็นไปตามคำสั่งหรือไม่ต่อเนื่องกัน

pvckสามารถตรวจสอบข้อมูลเมตา LVM หลังจากความสอดคล้องนั้นเป็นงานของระบบไฟล์ LVM นั้นเกี่ยวกับการจัดการระดับเสียงเท่านั้นดังนั้นจึงไม่จำเป็นต้องสนใจว่าพื้นที่ที่มีขอบเขตที่เฉพาะเจาะจงนั้นไม่ดีเนื่องจากซอฟต์แวร์ระดับสูงขึ้นมาตรวจจับปัญหาเหล่านั้น ข้อมูลเมตาของ LVM ใช้เวลาเพียงช่วงแรก (หรือเป็นทางเลือกภาคสุดท้าย) ของปริมาณฟิสิคัล

ถ้าเพียงแค่ส่วนแรกและส่วนสุดท้ายของ PV ที่มีขนาดใหญ่พอสมควร (เช่นที่คุณเห็นในการผลิต) เกิดขึ้นพร้อมกันล้มเหลวโดยทั่วไปคุณจะมีโชค sh * ttiest ในโลกเพราะมันไม่น่าเป็นไปได้ทางดาราศาสตร์ มิฉะนั้นหากผู้ดูแลระบบรู้ว่าหลาย ๆ ส่วนของไดรฟ์ล้มเหลวคนส่วนใหญ่ไม่เป็นไรเพียงแค่ยื่นสิ่งต่าง ๆ เช่นนี้ภายใต้ "ฮาร์ดไดรฟ์ล้มเหลวอย่างถาวรและจำเป็นต้องเปลี่ยนใหม่"

หากpvckส่งคืนข้อผิดพลาดคุณสามารถตรวจสอบเพื่อดูว่าข้อมูลเมตา LVM ของคุณสำรองไว้ที่/etc/lvmอื่นหรือไม่ หากเป็นเช่นนั้นคุณสามารถpvcreateระบุสำเนาสำรองได้--restorefile

ไวยากรณ์:

pvcreate --uuid "<UUID-of-target-PV>" --restorefile <Path-To-Metadata-Backup-File> <path-to-PV-block-device>

ตัวอย่าง:

pvcreate --uuid "2VydVW-TNiN-fz9Y-ElRu-D6ie-tXLp-GrwvHz" --restorefile /etc/lvm/archive/vg_raid_00000-1085667159.vg /dev/sda2 

หากการคืนค่าไม่ทำงาน (ตัวอย่างเช่นหากภาคแรกไม่ดี) คุณสามารถทำซ้ำได้ แต่ตั้งค่า--metadatacopies 2(หรือคุณอาจไปที่การทำเช่นนั้น) ซึ่งจะพยายามเขียนข้อมูลเมตาไปที่ส่วนแรกและ ภาคสุดท้ายของ PV เมื่อไหร่pvscanที่มันทำการบูทมันจะตรวจสอบทั้งสองที่และถ้าพบเมทาดาทามันจะตรวจสอบมันกับซัมมัน หากการตรวจสอบล้มเหลวในภาคแรก แต่ประสบความสำเร็จในภาคสุดท้ายคุณจะได้รับข้อความแสดงข้อผิดพลาดที่ไม่ร้ายแรง

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