ข้อผิดพลาดดิสก์เงียบและความน่าเชื่อถือของการแลกเปลี่ยน Linux

ความเข้าใจของฉันคือฮาร์ดไดรฟ์และ SSD ใช้การแก้ไขข้อผิดพลาดพื้นฐานภายในไดรฟ์และการกำหนดค่า RAID ส่วนใหญ่เช่น mdadm จะขึ้นอยู่กับสิ่งนี้เพื่อตัดสินใจว่าเมื่อใดที่ไดรฟ์ล้มเหลวในการแก้ไขข้อผิดพลาดและจำเป็นต้องออฟไลน์ อย่างไรก็ตามขึ้นอยู่กับการจัดเก็บที่ถูกต้อง 100% ในการวิเคราะห์ข้อผิดพลาด ไม่เช่นนั้นและการกำหนดค่าทั่วไปเช่นมิเรอร์ RAID-1 แบบสองไดรฟ์จะมีความเสี่ยง: สมมติว่าบิตบางส่วนบนไดรฟ์หนึ่งเสียหายอย่างเงียบ ๆ และไดรฟ์ไม่รายงานข้อผิดพลาดการอ่าน ดังนั้นระบบไฟล์เช่น btrfs และ ZFS จะใช้เช็คซัมของตัวเองเพื่อที่จะไม่ไว้วางใจเฟิร์มแวร์ของรถบั๊กกี้สายเคเบิลที่มีความผิดพลาดของสาย SATA และอื่น ๆ

ในทำนองเดียวกัน RAM ยังมีปัญหาความน่าเชื่อถือและทำให้เรามี ECC RAM เพื่อแก้ไขปัญหานี้

คำถามของฉันคือสิ่งที่เป็นวิธีที่บัญญัติในการป้องกันไฟล์ swap Linux จากความเสียหายเงียบ / บิตเน่าไม่ได้จับโดยเฟิร์มแวร์ไดรฟ์ในการกำหนดค่าสองดิสก์ (เช่นการใช้ไดรเวอร์เคอร์เนล mainline)? สำหรับฉันแล้วดูเหมือนว่าการกำหนดค่าที่ไม่มีการป้องกันแบบครบวงจรที่นี่ (เช่นที่จัดทำโดย btrfs) จะลบล้างความสงบของจิตใจที่นำมาจาก ECC RAM แต่ฉันไม่สามารถคิดวิธีที่ดี:

• btrfs ไม่รองรับ swapfiles เลย คุณสามารถตั้งค่าอุปกรณ์ลูปจากไฟล์ btrfs และทำการสลับในนั้น แต่นั่นมีปัญหา:
  • การเขียนแบบสุ่มทำงานได้ไม่ดี: https://btrfs.wiki.kernel.org/index.php/Gotchas#Fragmentation
  • คำแนะนำที่นั่นเพื่อปิดการใช้งาน copy-on-write จะปิดการใช้งานการตรวจสอบด้วย - ดังนั้นการเอาชนะจุดทั้งหมดของแบบฝึกหัดนี้ สมมติฐานของพวกเขาคือไฟล์ข้อมูลมีการป้องกันภายในของตัวเอง
• ZFS บน Linux อนุญาตให้ใช้ ZVOL เป็น swap ซึ่งฉันคิดว่าสามารถใช้งานได้: http://zfsonlinux.org/faq.html#CanIUseaZVOLforSwap - อย่างไรก็ตามจากการอ่านของฉัน ZFS มักจะเรียกใช้หน่วยความจำและทำให้มันทำงานได้ใน swap แอพพลิเคชั่นเพียงอย่างเดียวดูเหมือนว่าบางงานจะคิดออก ฉันคิดว่านี่ไม่ใช่ตัวเลือกแรกของฉัน ทำไมคุณต้องใช้โมดูลเคอร์เนลแบบ out-of-tree เพื่อให้การแลกเปลี่ยนที่เชื่อถือได้นั้นเกินกว่าฉัน - แน่นอนว่ามีวิธีที่จะทำให้สำเร็จด้วยการกระจาย / เคอร์เนล Linux ที่ทันสมัยที่สุดในยุคนี้?
• ที่จริงแล้วมีเธรดในรายการส่งเมลเคอร์เนล Linux ที่มีแพตช์เพื่อเปิดใช้งาน checksums ภายในตัวจัดการหน่วยความจำเองด้วยเหตุผลที่ฉันพูดถึงในคำถามนี้: http://thread.gmane.org/gmane.linux.kernel/989246 - โชคไม่ดีเท่าที่ฉันจะบอกได้ว่าแผ่นแปะนั้นตายไปและไม่เคยทำให้มันทวนน้ำเพราะฉันไม่ทราบสาเหตุ แย่มากมันฟังดูเหมือนเป็นคุณสมบัติที่ดี ในทางกลับกันถ้าคุณใส่ swap ใน RAID-1 - หากความเสียหายนั้นเกินความสามารถในการตรวจสอบการซ่อมแซมคุณต้องการให้ตัวจัดการหน่วยความจำพยายามอ่านจากไดรฟ์อื่นก่อนที่จะตกใจหรืออะไรก็ตาม อาจอยู่นอกขอบเขตของสิ่งที่ตัวจัดการหน่วยความจำควรทำ

สรุป:

• RAM มี ECC เพื่อแก้ไขข้อผิดพลาด
• ไฟล์บนที่เก็บข้อมูลถาวรมี btrfs เพื่อแก้ไขข้อผิดพลาด
• สลับมี ??? <--- นี่คือคำถามของฉัน

เราเชื่อมั่นในความถูกต้องของข้อมูลที่ดึงมาจาก swap เนื่องจากฮาร์ดแวร์หน่วยเก็บข้อมูลมี checksums, CRC และอื่น ๆ

ในหนึ่งในความคิดเห็นข้างต้นคุณพูดว่า:

จริง แต่จะไม่ป้องกันการพลิกบิตนอกดิสก์ตัวเอง

"มัน" หมายถึง checksums ของดิสก์ที่นี่

นั่นเป็นความจริง แต่SATA ใช้ CRC แบบ 32 บิตสำหรับคำสั่งและข้อมูล ดังนั้นคุณมีโอกาส 1 ใน 4 พันล้านข้อมูลที่เสียหายระหว่างดิสก์และตัวควบคุม SATA นั่นหมายความว่าแหล่งที่มาของข้อผิดพลาดอย่างต่อเนื่องสามารถแนะนำข้อผิดพลาดได้บ่อยเท่าที่ทุก ๆ 125 MiB ถ่ายโอน แต่แหล่งที่มาของข้อผิดพลาดแบบสุ่มที่หายากเช่นรังสีคอสมิกจะทำให้เกิดข้อผิดพลาดที่ตรวจไม่พบในอัตราที่น้อย

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

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

หากไม่มีมาตรการดังกล่าวก็จะไม่มีส่วนชี้ไปที่กลุ่มเซกเตอร์สำรองในฮาร์ดไดรฟ์ทุกตัวไดรฟ์นั้นไม่สามารถตรวจพบเซกเตอร์ที่ไม่ดีดังนั้นจึงไม่สามารถแลกเปลี่ยนเซกเตอร์ใหม่ได้

ในความคิดเห็นอื่นคุณถาม:

ถ้า SATA มีความน่าเชื่อถือทำไมจึงมีการตรวจสอบระบบไฟล์เช่น ZFS, btrfs, ReFS?

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

ยิ่งไปกว่านั้นช่วงเวลาที่ผ่านไปมักจะสั้นลงในช่วงหลายปีที่ผ่านมาสิ่งที่เพิ่มความถี่ของเคอร์เนลและlibcการอัพเดทเวอร์ชวลไลเซชันสถาปัตยกรรมคลาวด์ ฯลฯ

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

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

ZFS และความแตกต่างดังกล่าวจากการสลับในอีกวิธีสำคัญที่นี่: เราไม่ได้แลกเปลี่ยนระบบไฟล์ RAID ด้วยกัน เมื่อมีการใช้อุปกรณ์แลกเปลี่ยนหลายเครื่องในเครื่องเดียวมันเป็นรูปแบบJBODไม่เหมือน RAID-0 หรือสูงกว่า (เช่นรูปแบบไฟล์เชนของ MacOS , Linux swaponและอื่น ๆ ) เนื่องจากอุปกรณ์ swap มีความเป็นอิสระมากกว่าการพึ่งพาซึ่งกันและกันกับ RAID เราไม่จำเป็นต้องตรวจสอบอย่างละเอียดเนื่องจากการเปลี่ยนอุปกรณ์ swap ไม่เกี่ยวข้องกับการดูอุปกรณ์แลกเปลี่ยนแบบพึ่งพาซึ่งกันและกันสำหรับ ข้อมูลที่ควรไปในอุปกรณ์ทดแทน ในแง่ ZFS เราจะไม่ resilver อุปกรณ์แลกเปลี่ยนจากสำเนาที่ซ้ำซ้อนบนอุปกรณ์เก็บข้อมูลอื่น ๆ

ทั้งหมดนี้หมายความว่าคุณต้องใช้อุปกรณ์สลับที่เชื่อถือได้ ฉันเคยใช้กล่องหุ้ม HDD USB ภายนอก $ 20 เพื่อช่วยเหลือสระ ZFS ที่ไม่สบายเพียงเพื่อค้นพบว่าตู้นั้นไม่น่าเชื่อถือและแนะนำข้อผิดพลาดของตัวเองในกระบวนการ การตรวจสอบที่แข็งแกร่งของ ZFS ช่วยฉันด้วยที่นี่ คุณไม่สามารถออกไปกับการเก็บรักษาสื่อเก็บข้อมูลแบบคาวาเลียร์ด้วยไฟล์ swap ได้ หากอุปกรณ์ swap กำลังจะตายและกำลังเข้าใกล้กรณีที่เลวร้ายที่สุดซึ่งมันสามารถฉีดข้อผิดพลาดที่ตรวจไม่ได้ทุก ๆ 125 MiB ที่ถ่ายโอนคุณเพียงแค่ต้องเปลี่ยนมันโดยเร็วที่สุด

ความรู้สึกโดยรวมของความหวาดระแวงในคำถามนี้ devolves อินสแตนซ์ของปัญหาที่เกิดขึ้นนายพลไบเซนไทน์ อ่านข้อมูลนั้นไตร่ตรองวันที่ปีพ. ศ. 2525 ในบทความทางวิชาการที่อธิบายปัญหาโลกวิทยาศาสตร์คอมพิวเตอร์แล้วตัดสินใจว่าในปี 2562 คุณมีความคิดใหม่ที่จะเพิ่มปัญหานี้ และถ้าไม่เช่นนั้นคุณอาจจะใช้เทคโนโลยีที่ออกแบบโดยบัณฑิตที่สำเร็จการศึกษาจาก CS กว่าสามทศวรรษที่ทุกคนรู้เกี่ยวกับปัญหาของนายพลไบเซนไทน์

นี่คือพื้นดินที่สมบูรณ์ คุณอาจไม่สามารถคิดความคิดคัดค้านหรือแก้ปัญหาที่ยังไม่ได้พูดถึงความตายในวารสารวิทยาศาสตร์คอมพิวเตอร์

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

มันเป็นไม่ได้ในทางปฏิบัติที่จะนำแลกเปลี่ยนไฟล์ของคุณอยู่ด้านบนของ ZFS หรือ Btrfs แต่ถ้าข้างบนไม่ได้สร้างความมั่นใจให้คุณอย่างน้อยคุณสามารถวางไว้บนยอด XFS หรือ ext4 นั่นจะดีกว่าการใช้ swap partition เฉพาะ

DM-สมบูรณ์

ดู: เอกสาร / อุปกรณ์ -mapper / dm-integrity.txt

dm-integrityโดยปกติจะใช้ในโหมด journalling ในกรณีของการแลกเปลี่ยนคุณสามารถจัดการได้โดยไม่ต้องลงทะเบียน สิ่งนี้อาจลดค่าใช้จ่ายด้านประสิทธิภาพลงอย่างมาก ฉันไม่แน่ใจว่าคุณจะต้องฟอร์แมตพาร์ติชัน swap-over-integrity ในการบู๊ตแต่ละครั้งหรือไม่เพื่อหลีกเลี่ยงการจับข้อผิดพลาดหลังจากการปิดระบบที่ไม่สะอาด

ในการประกาศครั้งแรกของdm-integrityผู้เขียนระบุการตั้งค่าสำหรับ "การป้องกันความสมบูรณ์ของข้อมูลในระดับที่สูงขึ้น" แทน ในกรณีของการสลับที่จะเปิดความเป็นไปได้ในการจัดเก็บเช็คซัมใน RAM อย่างไรก็ตามตัวเลือกนั้นต้องการการแก้ไขที่ไม่สำคัญกับรหัสการแลกเปลี่ยนปัจจุบันและเพิ่มการใช้หน่วยความจำ (รหัสปัจจุบันติดตามการแลกเปลี่ยนอย่างมีประสิทธิภาพโดยใช้ส่วนขยายไม่ใช่แต่ละหน้า / ส่วน)

DIF / DIX?

Oracle เพิ่มการรองรับ DIX ใน Linux 2.6.27 (2008)

การใช้ DIX ให้ความสมบูรณ์แบบครบวงจรหรือไม่

คุณสามารถปรึกษาผู้ขายของคุณ ฉันไม่รู้ว่าคุณจะบอกได้อย่างไรว่าพวกเขาโกหกเกี่ยวกับเรื่องนี้

DIX จำเป็นต้องมีการป้องกันข้อมูลในเที่ยวบินระหว่าง OS (ระบบปฏิบัติการ) และ HBA

DIF เพิ่มการป้องกันข้อมูลระหว่าง HBA และอุปกรณ์จัดเก็บข้อมูลของตัวเอง (ดูเพิ่มเติมที่: การนำเสนอที่มีตัวเลขบางส่วนเกี่ยวกับความแตกต่างของอัตราความผิดพลาด )

แม่นยำเนื่องจากการตรวจสอบในเขตรักษาความปลอดภัยเป็นมาตรฐานเป็นไปได้ทางเทคนิคในการใช้คำสั่ง DIX โดยไม่ต้องให้การป้องกันข้อมูลใด ๆที่เหลือ เพียงแค่ให้ HBA (หรืออุปกรณ์เก็บข้อมูล) สร้างเช็คซัมขึ้นใหม่ในเวลาอ่าน มุมมองนี้ค่อนข้างชัดเจนจากโครงการ DIX ดั้งเดิม

• DIF / DIX เป็นมุมฉากเป็นเช็คซัมบล็อกแบบลอจิคัล
  • เรายังรักคุณ btrfs!
  • การตรวจสอบข้อผิดพลาดแบบลอจิคัลบล็อกใช้สำหรับตรวจหาข้อมูลที่เสียหาย
  • การตรวจจับเกิดขึ้นในเวลาที่อ่าน
  • ... ซึ่งอาจเป็นเดือนต่อมาบัฟเฟอร์เดิมจะหายไป
  • สำเนาที่ซ้ำซ้อนใด ๆ อาจไม่ดีเช่นกันถ้าบัฟเฟอร์ต้นฉบับอ่านไม่ออก
• DIF / DIX เกี่ยวกับการป้องกันเชิงรุก
  • การป้องกันไม่ให้ข้อมูลที่ไม่ดีถูกเก็บไว้ในดิสก์ตั้งแต่แรก
  • ... และค้นหาปัญหาก่อนบัฟเฟอร์ต้นฉบับจะถูกลบออกจากหน่วยความจำ

- lpc08-data-integrity.pdf จาก oss.oracle.com

หนึ่งในการโพสต์ครั้งแรกของพวกเขาเกี่ยวกับ DIX กล่าวถึงความเป็นไปได้ของการใช้ DIX ระหว่างระบบปฏิบัติการและ HBA แม้ในขณะที่ไดรฟ์ไม่รองรับ DIF

ความสมบูรณ์ที่ไม่น่าจะเกิดขึ้นในบริบทของ "องค์กร" ที่ใช้ DIX อยู่ในปัจจุบัน คนจะสังเกตเห็นมัน นอกจากนี้ DIF ยังใช้ฮาร์ดแวร์ที่มีอยู่ซึ่งสามารถฟอร์แมตด้วยเซ็กเตอร์ขนาด 520 ไบต์ โปรโตคอลสำหรับการใช้ DIF ที่ถูกกล่าวหาต้องให้คุณฟอร์แมตไดรฟ์ก่อนดูที่sg_formatคำสั่ง

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

อีกทางหนึ่งระบบปฏิบัติการสามารถสร้าง checksums ของตัวเองและเก็บไว้ในพื้นที่แท็กแอปพลิเคชัน อย่างไรก็ตามมีการสนับสนุนในปัจจุบันไม่มีลินุกซ์ (v4.20) ความคิดเห็นที่เขียนในปี 2014 ชี้ให้เห็นว่านี่อาจเป็นเพราะ "อุปกรณ์จัดเก็บข้อมูลน้อยมากที่อนุญาตให้ใช้พื้นที่แท็กแอปพลิเคชัน" (ฉันไม่แน่ใจว่าสิ่งนี้หมายถึงอุปกรณ์เก็บข้อมูลตัวเอง HBA หรือทั้งสองอย่าง)

อุปกรณ์ DIX ประเภทใดที่ใช้งานได้กับ Linux

การแยกบัฟเฟอร์ข้อมูลเมตาดาต้าและความสมบูรณ์รวมถึงตัวเลือกในการตรวจสอบเรียกว่า Data Integrity Extensions [DIX] เนื่องจากส่วนขยายเหล่านี้อยู่นอกขอบเขตของส่วนร่างโปรโตคอล (T10, T13), Oracle และคู่ค้าพยายามที่จะสร้างมาตรฐานให้กับพวกเขาภายในสมาคมอุตสาหกรรมระบบเครือข่ายการเก็บข้อมูล

- v4.20 / เอกสาร / บล็อก / data-integrity.txt

Wikipedia บอกฉันว่า DIF นั้นได้มาตรฐานใน NVMe 1.2.1 สำหรับ SCSI HBAs ดูเหมือนว่ายากที่จะปักหมุดลงถ้าเราไม่มีมาตรฐานที่จะชี้ไป ในขณะนี้อาจเป็นการแม่นยำที่สุดที่จะพูดคุยเกี่ยวกับการสนับสนุน "Linux DIX" :-) มีอุปกรณ์ที่ใช้ได้:

SCSI T10 DIF / DIX [sic] ได้รับการสนับสนุนอย่างเต็มที่ใน Red Hat Enterprise Linux 7.4 โดยมีเงื่อนไขว่าผู้จำหน่ายฮาร์ดแวร์ได้ผ่านการรับรองและให้การสนับสนุนอย่างเต็มที่สำหรับ HBA และการจัดเก็บอาร์เรย์ DIF / DIX ไม่รองรับการกำหนดค่าอื่น ๆ ไม่รองรับการใช้งานบนอุปกรณ์สำหรับบู๊ตและไม่รองรับกับแขกเสมือนจริง

ในเวลาปัจจุบันผู้ขายต่อไปนี้ทราบว่าให้การสนับสนุนนี้ ...

- RHEL 7.5 Release Notes, บทที่ 16 การจัดเก็บข้อมูล

ฮาร์ดแวร์ทั้งหมดที่กล่าวถึงในบันทึกย่อประจำรุ่น RHEL 7.5 คือ Fibre Channel

ฉันไม่รู้ตลาดนี้ ดูเหมือนว่า DIX อาจมีให้บริการในเซิร์ฟเวอร์ในอนาคตมากขึ้น ฉันไม่รู้เหตุผลที่จะพร้อมใช้งานสำหรับดิสก์ SATA ของผู้บริโภค - เท่าที่ฉันรู้ว่าไม่มีมาตรฐาน de-พฤตินัยสำหรับรูปแบบคำสั่ง ฉันจะสนใจที่จะดูว่าจะมีให้ใช้อย่างกว้างขวางมากขึ้นใน NVMe หรือไม่

สลับมี ??? <--- นี่คือคำถามของฉัน

การสลับยังคงไม่ได้รับการป้องกันใน Linux (แต่ดูที่ UPD)

แน่นอนว่ามี ZFS บน Linux ที่สามารถเป็นที่เก็บสลับได้แต่ยังคงมีการล็อคในบางกรณี - ดังนั้นจึงยกเลิกตัวเลือกดังกล่าวได้อย่างมีประสิทธิภาพ

Btrfs ยังไม่สามารถจัดการไฟล์สลับได้ พวกเขากล่าวถึงการใช้ลูปแบ็คที่เป็นไปได้แม้ว่าจะระบุว่ามีประสิทธิภาพต่ำ มีข้อบ่งชี้ที่ชัดเจนว่าในที่สุด Linux 5 อาจมี (?) ...

แพทช์เพื่อป้องกันการแลกเปลี่ยนแบบเดิมด้วย checksums ไม่ได้ทำให้เป็นกระแสหลัก

ดังนั้นทั้งหมด: ทั้งหมดไม่ Linux ยังคงมีช่องว่างอยู่

UPD : @ @ sourcejedi ชี้ให้เห็นว่ามีเครื่องมือเช่น dm-integrity ลินุกซ์เคอร์เนลตั้งแต่เวอร์ชั่น 4.12 มีเป้าหมายเป็นผู้ทำแผนที่ของอุปกรณ์ซึ่งสามารถนำไปใช้ในการจัดเตรียมเช็คซัมให้กับอุปกรณ์บล็อกทั่วไปใด ๆ และสำหรับการแลกเปลี่ยนนั้นไม่มีข้อยกเว้น การใช้เครื่องมือไม่ได้ถูกรวมเข้ากับ distros ใหญ่และส่วนใหญ่ไม่ได้รับการสนับสนุนในระบบย่อย udev แต่ท้ายที่สุดสิ่งนี้ควรเปลี่ยน เมื่อจับคู่กับผู้ให้บริการซ้ำซ้อนพูดว่าวางบนสุดของ MD aka Linux Software RAID มันควรจะเป็นไปได้ไม่เพียง แต่จะตรวจจับบิตเน่า แต่ยังเพื่อขอเส้นทาง I / O ใหม่ไปยังข้อมูลที่ดีต่อสุขภาพเพราะ dm-integrity ปัญหาและ MD ควรจัดการกับมัน

ฉันไม่คิดว่ามีวิธี "ยอมรับ" ดังนั้นต่อไปนี้เป็นความเห็นส่วนตัวของฉัน

จากการติดตามความก้าวหน้าของ btrfs จากมุมมองของผู้ใช้ที่มีศักยภาพฉันต้องบอกว่ามันยังปิดบังฉันอยู่บ้าง มีคุณสมบัติที่เป็นผู้ใหญ่และพร้อมสำหรับการใช้การผลิตและมีคุณสมบัติที่ดูอ่อนและอันตรายต่อการใช้งาน

โดยส่วนตัวแล้วฉันไม่มีเวลาที่จะตัดสินใจว่าจะใช้ฟีเจอร์ไหนและจะไม่ปล่อยให้เวลาที่ฉันต้องใช้เพื่อหาวิธีปิดหรือเปิดฟีเจอร์เหล่านี้

ในทางตรงกันข้าม ZFS นั้นมีความแข็งแกร่งและเป็นผู้ใหญ่ (IMHO) ดังนั้นเพื่อตอบคำถามของคุณฉันจะใช้ ZFS (โดยวิธีการนี้มันไม่ได้ใช้หน่วยความจำมากนัก - ดูด้านล่าง)

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

โดยบังเอิญฉันได้วางเซิร์ฟเวอร์ Linux บางตัวใน ZFS ในช่วงวันสุดท้าย ๆ ในแต่ละครั้งรวมถึงระบบไฟล์รูทและการสลับ ก่อนที่ฉันจะทำสิ่งนี้ฉันได้ทำการวิจัยอย่างละเอียดมากซึ่งใช้เวลาหลายวัน สรุปสั้น ๆ เกี่ยวกับสิ่งที่ฉันได้เรียนรู้:

ปริมาณการใช้หน่วยความจำของ ZFS

มีความเข้าใจผิดทั่วไปเกี่ยวกับการใช้หน่วยความจำของ ZFS โดยทั่วไป ZFS จะใช้หน่วยความจำไม่มาก ในความเป็นจริงมันทำงานด้วยการจัดเก็บ TBs บนเครื่องที่มี RAM 2 GB เฉพาะเมื่อคุณใช้การขจัดข้อมูลซ้ำซ้อน (ปิดใช้งานตามค่าเริ่มต้น) คุณต้องใช้ RAM จำนวนมากและมาก ๆ

การตรวจสอบ / แก้ไขข้อผิดพลาดของฮาร์ดแวร์

ไม่ว่าจะเป็นของ SATA, PATA, RAID หรือกลไกการตรวจจับ / แก้ไขข้อผิดพลาดอื่น ๆ นั้นเพียงพอสำหรับความถูกต้องของข้อมูลเป็นเรื่องที่ทำให้เกิดการสนทนาที่ไม่รู้จบ ตามทฤษฎีแล้วอุปกรณ์จัดเก็บข้อมูลฮาร์ดแวร์ควรรายงานข้อผิดพลาดใด ๆ ที่เกิดขึ้นและฮาร์ดแวร์การส่งข้อมูลในทุกระดับ (ชิปเซ็ตหน่วยความจำและอื่น ๆ ) ควรทำเช่นกัน

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

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

นั่นเป็นพฤติกรรมที่สมเหตุสมผลหรือไม่? เท่าที่ฉันรู้ตัวควบคุมฮาร์ดแวร์ RAID5 ส่วนใหญ่และแม้แต่ md RAID ของ Linux ก็ใช้วิธีนี้

ฉันไม่รู้เกี่ยวกับการแก้ไขข้อผิดพลาดของ btrfs แต่ในที่สุดคุณควรอ่านเอกสารอย่างละเอียดอีกครั้งโดยเฉพาะถ้าคุณใช้ RAID ของ btrfs

เงียบเน่าบิต

แม้จะมีเปลวไฟสงครามและการอภิปรายทางวิทยาศาสตร์ (หลอก): ความจริงส่วนใหญ่จะแตกต่างจากทฤษฎีและบิตเน่าเงียบเกิดขึ้นแน่นอนแม้ว่าทฤษฎีอาจระบุตรงกันข้าม (บอทเงียบมักจะหมายความว่าข้อมูลในการจัดเก็บฮาร์ดแวร์ได้รับความเสียหาย เกิดข้อผิดพลาดเมื่อข้อมูลนี้ถูกอ่าน แต่ฉันจะเพิ่มบิตการพลิกที่ใดก็ได้ในเส้นทางการส่งไปยังคำจำกัดความนี้)

สิ่งนี้เกิดขึ้นไม่ใช่ความเห็นส่วนตัวของฉัน: อย่างน้อย Google, Amazon และ CERN ได้ตีพิมพ์เอกสารรายละเอียดที่ครอบคลุมหัวข้อนั้น ๆ เอกสารเผยแพร่ต่อสาธารณชนให้ดาวน์โหลดฟรี พวกเขาได้ทำการทดลองอย่างเป็นระบบกับฮาร์ดดิสก์จำนวนหลายล้านตัวและเซิร์ฟเวอร์ / อุปกรณ์จัดเก็บข้อมูลนับแสนเนื่องจากพวกเขามีปัญหาเกี่ยวกับความเสียหายของข้อมูลที่ตรวจไม่พบหรือเพราะพวกเขาต้องการทราบว่าต้องทำอย่างไรเพื่อป้องกันก่อนที่จะเกิดขึ้น

โดยสรุปข้อมูลในเซิร์ฟเวอร์ฟาร์มของพวกเขาเสียหายด้วยอัตราที่สูงกว่าสถิติ MTBF หรือทฤษฎีอื่น ๆ สูงขึ้นอย่างมีนัยสำคัญฉันหมายถึงคำสั่งของขนาด

บิตเน่าที่เงียบสนิทเช่นความเสียหายของข้อมูลที่ตรวจไม่พบ ณ จุดใด ๆ ในเส้นทางการส่งข้อมูลเป็นปัญหาชีวิตจริง

อายุการใช้งานข้อมูล

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

ถ้อยคำส

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

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

ข้อสงวนสิทธิ์: ฉันไม่มีส่วนเกี่ยวข้องกับผู้ขายหรือผู้พัฒนา ZFS ใด ๆ นี่เป็นจริงสำหรับตัวแปรทั้งหมด (forks) ของ ZFS ฉันเพิ่งเป็นแฟนของมันในวันที่ผ่านมา ...