การตรวจสอบบิตเน่าและการแก้ไขด้วย mdadm

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

เนื่องจากฉันจะใช้ HDD อย่างน้อย 21TB ใน 8 ดิสก์ใน NAS และราคาต่าง ๆ เกี่ยวกับความน่าจะเป็นของความล้มเหลวบน HDD ฉันคิดว่าในระหว่างการสร้างใหม่จากความล้มเหลวของดิสก์เดียวฉันมีแนวโน้มที่จะพบ รูปแบบของบิตเน่าในดิสก์ที่เหลือ หากเป็นข้อผิดพลาดในการอ่านที่ไม่สามารถกู้คืนได้ใน 1 ไดรฟ์แสดงว่าไดรฟ์นั้นรายงานว่าเป็นข้อผิดพลาดจริง ๆ ฉันเชื่อว่าควรจะดีกับ raid6 (ใช่หรือไม่) อย่างไรก็ตามหากข้อมูลที่อ่านจากดิสก์ไม่ดี แต่ไม่มีการรายงานจากดิสก์ฉันไม่สามารถดูได้ว่าจะสามารถแก้ไขได้อย่างไรโดยอัตโนมัติแม้กับ raid6 นี่เป็นสิ่งที่เราต้องกังวลหรือไม่? รับบทความเป็น 2010 และ RAID5 ยังคงทำงานและประสบการณ์ที่ประสบความสำเร็จของฉันเองที่บ้านและที่ทำงานสิ่งต่าง ๆ ไม่จำเป็นต้องดูหมิ่นและเศร้าหมองเหมือนคำพูดและการตลาดที่จะทำให้เราเชื่อ แต่ฉันเกลียดที่จะต้องกู้คืนจากการสำรองข้อมูลเพียงเพราะ HDD ล้มเหลว

ระบุว่ารูปแบบการใช้จะเป็นเขียนเป็นอย่างมากไม่กี่ครั้งและอ่านบางครั้งฉันจะต้องดำเนินการข้อมูลที่ขัด ฉันเห็นใน archlinux wiki คำสั่ง mdadm สำหรับข้อมูลขัดอาเรย์เป็น

echo check > /sys/block/md0/md/sync_action

จากนั้นเพื่อติดตามความคืบหน้า

cat /proc/mdstat

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

ฉันควรเลือกระดับ mdadm RAID ใดเพื่อเพิ่มการป้องกันสูงสุดจากบิตเน่าและฉันควรจะทำอย่างไรในการบำรุงรักษาและขั้นตอนการป้องกันอื่น ๆ และสิ่งนี้จะไม่ปกป้องฉันจากอะไร

แก้ไข: ฉันไม่ต้องการเริ่ม RAID vs ZFS หรือ QA เทคโนโลยีอื่น ๆ ฉันต้องการทราบเฉพาะเกี่ยวกับการโจมตี mdadm นั่นคือเหตุผลที่ฉันขอบน Unix และ Linux และไม่ได้อยู่ในSuperUser

แก้ไข: คือคำตอบ: mdadm สามารถแก้ไข URE ที่รายงานโดยระบบดิสก์ในระหว่างการขัดข้อมูลและตรวจสอบบิตเนลเงียบในระหว่างการขัด แต่ไม่สามารถ / จะไม่สามารถแก้ไขได้?

ฉันคิดว่ามันค่อนข้างน่าแปลกใจที่คุณปฏิเสธ RAIDZ2 ZFS ดูเหมือนว่าจะเหมาะกับความต้องการของคุณเกือบจะสมบูรณ์แบบยกเว้นว่ามันไม่ใช่ Linux MD ฉันไม่ได้ในสงครามครูเสดที่จะนำ ZFS เพื่อมวลชน แต่ความเป็นจริงง่ายๆก็คือว่าคุณเป็นหนึ่งในชนิดของปัญหาที่ ZFS ได้รับการออกแบบจากพื้นดินขึ้นเพื่อแก้ปัญหา การใช้ RAID (RAID "ปกติ" ใด ๆ ) เพื่อให้การตรวจจับข้อผิดพลาดและการแก้ไขอาจเป็นไปได้ในสถานการณ์ที่ลดลงหรือไม่มีความซ้ำซ้อนดูเหมือนว่ามีความเสี่ยง แม้ในสถานการณ์ที่ ZFS ไม่สามารถแก้ไขข้อผิดพลาดข้อมูลได้อย่างน้อยก็สามารถตรวจพบข้อผิดพลาดและแจ้งให้คุณทราบว่ามีปัญหาทำให้คุณสามารถดำเนินการแก้ไขได้

คุณไม่จำเป็นต้องทำการขัดแบบเต็มรูปแบบด้วย ZFS แม้ว่าจะเป็นวิธีปฏิบัติที่แนะนำก็ตาม ZFS จะตรวจสอบว่าข้อมูลที่อ่านจากดิสก์ตรงกับสิ่งที่เขียนในขณะที่ข้อมูลกำลังอ่านและในกรณีที่ข้อมูลไม่ตรงกันอย่างใดอย่างหนึ่ง (a) ใช้ความซ้ำซ้อนเพื่อสร้างข้อมูลต้นฉบับใหม่หรือ (b) รายงานข้อผิดพลาด I / O แอปพลิเคชัน นอกจากนี้การขัดถูยังเป็นการดำเนินการออนไลน์ที่มีลำดับความสำคัญต่ำซึ่งค่อนข้างแตกต่างจากการตรวจสอบระบบไฟล์ในระบบไฟล์ส่วนใหญ่ซึ่งอาจมีทั้งลำดับความสำคัญสูงและออฟไลน์ หากคุณกำลังใช้งานสครับและสิ่งอื่นที่ไม่ใช่สครับต้องการทำ I / O สครับจะใช้เบาะหลังเป็นระยะเวลาหนึ่ง การขัด ZFS เกิดขึ้นทั้งการขัดแบบ RAID และข้อมูลเมตาของระบบไฟล์และข้อมูล การตรวจสอบความถูกต้องสมบูรณ์นั้นมีความละเอียดมากกว่าการขัดอาเรย์ RAID เพื่อตรวจสอบบิตเนทใด ๆ (ซึ่งไม่ได้บอกคุณว่าข้อมูลมีความหมายอะไรก็ตาม

ZFS redundancy (RAIDZ, mirroring, ... ) มีข้อได้เปรียบที่ไม่จำเป็นต้องตรวจสอบตำแหน่งดิสก์ที่ไม่ได้ใช้เพื่อความสม่ำเสมอในระหว่างการขัด มีการตรวจสอบข้อมูลจริงในระหว่างการขัดเกลาเนื่องจากเครื่องมือดำเนินการตามห่วงโซ่การจัดสรรบล็อก นี่เป็นเช่นเดียวกับสระว่ายน้ำที่ไม่ซ้ำซ้อน สำหรับ RAID "ปกติ" ข้อมูลทั้งหมด (รวมถึงตำแหน่งที่ไม่ได้ใช้งานบนดิสก์) จะต้องตรวจสอบเพราะคอนโทรลเลอร์ RAID (ไม่ว่าจะเป็นฮาร์ดแวร์หรือซอฟต์แวร์) ไม่รู้ว่าข้อมูลใดที่เกี่ยวข้องจริง ๆ

ด้วยการใช้ RAIDZ2 vdevs ไดรฟ์ที่เป็นส่วนประกอบสองตัวสามารถล้มเหลวก่อนที่คุณจะเสี่ยงต่อการสูญเสียข้อมูลจริงจากความล้มเหลวของไดรฟ์อื่นเนื่องจากคุณมีความซ้ำซ้อนของไดรฟ์สองตัว นี่เป็นหลักเหมือนกับ RAID6

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

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

ข้อเสียเดียวที่แท้จริงคือคุณไม่สามารถเพิ่ม RAIDZ vdev ได้อย่างง่ายดายโดยการเพิ่มอุปกรณ์ลงไป มีวิธีแก้ไขเฉพาะหน้าซึ่งมักเกี่ยวข้องกับสิ่งต่าง ๆ เช่นไฟล์กระจัดกระจายเป็นอุปกรณ์ใน vdevและมักเรียกว่า "ฉันจะไม่ทำสิ่งนี้หากเป็นข้อมูลของฉัน" ดังนั้นถ้าคุณไปเส้นทาง RAIDZ (ไม่ว่าคุณจะใช้ RAIDZ, RAIDZ2 หรือ RAIDZ3) คุณต้องตัดสินใจล่วงหน้าว่าคุณต้องการไดรฟ์จำนวนเท่าใดในแต่ละ vdev แม้ว่าจำนวนของไดรฟ์ใน vdev ได้รับการแก้ไขแล้วคุณสามารถเพิ่มจำนวน vdev ได้โดยค่อย ๆ (ตรวจสอบให้แน่ใจว่าอยู่ในเกณฑ์ความซ้ำซ้อนของ vdev) แทนที่ไดรฟ์ที่มีความจุขนาดใหญ่กว่า

คำตอบนี้เป็นผลผลิตของการใช้เหตุผลตามหลักฐานต่าง ๆ ที่ฉันได้พบ ฉันไม่รู้ว่าการใช้งานเคอร์เนลของ Linux ทำงานอย่างไรเพราะฉันไม่ใช่เคอร์เนล dev และดูเหมือนว่าจะมีข้อมูลที่ผิดที่ผิดเพี้ยนไปจากที่นั่น ฉันคิดว่าเคอร์เนลลินุกซ์เป็นตัวเลือกที่มีสติ คำตอบของฉันควรใช้ยกเว้นว่าฉันเข้าใจผิด

ไดรฟ์จำนวนมากใช้ ECC (รหัสแก้ไขข้อผิดพลาด) เพื่อตรวจหาข้อผิดพลาดในการอ่าน หากข้อมูลเสียหายเคอร์เนลควรได้รับ URE (ข้อผิดพลาดในการอ่านที่ไม่สามารถกู้คืนได้) สำหรับบล็อกนั้นจากไดรฟ์ ECC ที่รองรับ ภายใต้สถานการณ์เหล่านี้ (และมีข้อยกเว้นด้านล่าง) การคัดลอกข้อมูลที่เสียหายหรือว่างเปล่าข้อมูลที่ดีจะทำให้เสียสติ ในสถานการณ์นี้เคอร์เนลควรรู้ว่าเป็นข้อมูลที่ดีและเป็นข้อมูลที่ไม่ดี ตามที่เป็น 2010 และ RAID5 ยังคงทำงาน ...บทความ:

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

อย่างไรก็ตามในตอนนี้สำหรับข้อยกเว้น: ถ้าไดรฟ์ไม่รองรับ ECC, ไดรฟ์อยู่ที่ข้อมูลเสียหายหรือเฟิร์มแวร์ไม่ทำงานโดยเฉพาะอย่างยิ่งดังนั้น URE อาจไม่ถูกรายงานและข้อมูลที่เสียหายจะถูกส่งไปยังเคอร์เนล ในกรณีของข้อมูลที่ไม่ตรงกัน: ดูเหมือนว่าถ้าคุณใช้ 2 ดิสก์ RAID1 หรือ RAID5 เคอร์เนลจะไม่สามารถรู้ได้ว่าข้อมูลใดถูกต้องแม้ในสภาวะที่ไม่เสื่อมโทรมเพราะมีเพียงพาริตี้เดียวเท่านั้น บล็อกและไม่มีรายงาน URE ในดิสก์ RAID1 3 ตัวหรือ RAID6 บล็อกที่ไม่ใช่แฟล็ก URE ที่เสียหายเพียงอันเดียวจะไม่ตรงกับพาริตีที่ซ้ำซ้อน (ร่วมกับบล็อกอื่น ๆ ที่เกี่ยวข้อง) ดังนั้นการกู้คืนอัตโนมัติที่เหมาะสมควรเป็นไปได้

คุณธรรมของเรื่องราวคือใช้ไดรฟ์กับ ECC น่าเสียดายที่ไดรฟ์ทั้งหมดที่สนับสนุน ECC โฆษณาคุณลักษณะนี้ไม่ได้ ในทางกลับกันโปรดระวัง: ฉันรู้จักใครที่ใช้ SSD ราคาถูกใน RAID2 2 แผ่น (หรือ RAID10 2 อัน) หนึ่งในไดรฟ์ส่งคืนข้อมูลที่เสียหายแบบสุ่มในแต่ละส่วนของการอ่าน ข้อมูลที่เสียหายจะถูกคัดลอกไปยังข้อมูลที่ถูกต้องโดยอัตโนมัติ หาก SSD ใช้ ECC และทำงานได้อย่างถูกต้องเคอร์เนลควรดำเนินการแก้ไขอย่างเหมาะสม

สำหรับการป้องกันที่คุณต้องการฉันจะไปกับ RAID6 + การสำรองข้อมูลนอกสถานที่ปกติใน 2 ตำแหน่ง

ฉันขัดตัวเองสัปดาห์ละครั้งและสำรองคืนทุกสัปดาห์และรายเดือนขึ้นอยู่กับความสำคัญของข้อมูลและความเร็วในการเปลี่ยนแปลง

ฉันไม่มีตัวแทนเพียงพอที่จะแสดงความคิดเห็น แต่ฉันต้องการชี้ให้เห็นว่าระบบ mdadm ใน Linux ไม่ได้แก้ไขข้อผิดพลาดใด ๆ ถ้าคุณบอกให้ "แก้ไข" ข้อผิดพลาดในระหว่างการหยุดพูด RAID6 ถ้ามีความไม่สอดคล้องกันมันจะ "แก้ไข" โดยสมมติว่าส่วนข้อมูลนั้นถูกต้องและคำนวณความเท่าเทียมกันใหม่

fud เน่าบิต? แน่ใจ ...

ฉันเดาว่าคุณต้องคุยกับ SEAGATE (ลืม? นั่นเป็นข้อแก้ตัว)? ตอนนี้ไดรฟ์ทั้งหมดมีการแก้ไข ECC 100 บิตคุณต้องพิสูจน์การหมุนก่อน
ฉันพนันได้เลยว่าคุณทำไม่ได้ (มันเป็นสิ่งที่ FUD ต้องกังวลใช่มั้ย) เช่นกลัวผีหรือ # 13? และไม่ทำที่นี่ ไม่มีข้อพิสูจน์เกิดขึ้น และแย่กว่านั้นไม่มีข้อพิสูจน์สาเหตุ

ก่อนอื่นให้นิยามความหมายของ bit rot? อุ๊ปส์ ... HDD: ECC ตรวจสอบข้อมูล (แม้แต่ 1 บิต) กับที่เก็บข้อมูล ECC 100 บิต ถ้ามันผิดมันจะแก้ไขหากมันทำให้เอ็นจิ้น SMART ล้มเหลวอย่างแน่นอนสำหรับไดรฟ์ SAS มันจะแทนที่คลัสเตอร์หรือเซกเตอร์ด้วยเหตุผลที่ดี ใช้อะไหล่สำรอง เป็นการซ่อมแซมความเสียหาย ใช่ไดรฟ์ทั้งหมดเติบโตบิตที่ไม่ดีตั้งแต่วันแรกจนถึงสิ้นสุดจากไดรฟ์แรกของไอบีเอ็มถึงตอนนี้ แต่ตอนนี้เราทำการซ่อมแซมตัวเองแล้วอ่านเอกสารของ Seagate ฉบับเต็ม ไม่มีที่สิ้นสุดและเรียนรู้วิธีการทำงานของไดรฟ์ ตกลง?

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

ฉันเรียก BOGUS และ FUD บนเน่าบิต

ฉันเดาว่าพีซี someones toy เขียนข้อมูลผิดด้วยเหตุผลอะไร ไม่ใช้หน่วยความจำ ECC อ๊ะเซิร์ฟเวอร์จริงมี ECC RAM ติดเชื้อไวรัส หรือไฟฟ้าดับระหว่างการเขียน (ไม่มี UPS>?) หรือมีหน่วยความจำไม่ดี หรือ ESD เสียหาย หรือ PSU ทำเสียงดังมากมาย (ไม่ดี)

ฉันเรียก FUD ที่นี่ ขอโทษ