ปรับปรุงฟีเจอร์ขจัดข้อมูลซ้ำของ OpenZFS พร้อมคำแนะนำให้หลีกเลี่ยงการใช้งาน

 (despairlabs.com)
1 คะแนน โดย GN⁺ 2024-10-31 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

การขจัดข้อมูลซ้ำของ OpenZFS คืออะไร?

  • ความหมายของการขจัดข้อมูลซ้ำ: ใน OpenZFS ระบบจะตรวจสอบก่อนเขียนข้อมูลลงดิสก์ว่าข้อมูลนั้นมีอยู่บนดิสก์แล้วหรือไม่ และถ้ามีอยู่แล้ว ก็จะไม่เขียนซ้ำใหม่ แต่เพิ่มการอ้างอิงไปยังสำเนาเดิมแทน
  • ความท้าทายของการขจัดข้อมูลซ้ำ: การตรวจสอบว่าข้อมูลมีอยู่บนดิสก์แล้วหรือไม่ และรู้ตำแหน่งของมัน เป็นเรื่องที่ทำได้ยาก ซึ่งต้องใช้การรับส่งข้อมูลเพิ่มเติม (IO) และอาจทำให้ประสิทธิภาพลดลง

การขจัดข้อมูลซ้ำทำงานอย่างไร?

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

ปัญหาของการขจัดข้อมูลซ้ำแบบดั้งเดิม

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

FastDedup แก้ปัญหาอย่างไร?

  • ลดขนาดรายการที่ยังใช้งานอยู่: เพื่อลดการใช้หน่วยความจำ มีการลดขนาดหน่วยความจำที่รายการที่ยังใช้งานอยู่ใช้ลง โดยตารางขจัดข้อมูลซ้ำแบบใหม่ลดส่วน "ค่า" ของรายการลงเหลือ 72 ไบต์
  • ล็อกขจัดข้อมูลซ้ำ: ใช้ล็อกแทนรายการที่ยังใช้งานอยู่เพื่อบันทึกการเปลี่ยนแปลง และเล่นซ้ำล็อกเมื่อกู้คืนจากความขัดข้อง โดยล็อกจะถูกเก็บไว้ในหน่วยความจำเพื่อให้ค้นหาได้รวดเร็ว
  • การ flush ล็อกแบบเพิ่มทีละส่วน: เพื่อควบคุมขนาดของล็อก ระบบจะเขียนบางส่วนของล็อกลงใน ZAP ทุกทรานแซกชัน และจะเร่งการ flush ล็อกเมื่อมีแรงกดดันด้านหน่วยความจำ

สรุปโดย GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-10-31
ความคิดเห็นใน Hacker News

  • กดเข้ามาเพราะสะดุดกับพาดหัว แต่เดิมไม่ได้สนใจ ZFS เลย ถึงอย่างนั้นก็อ่านแทบทุกบรรทัดจนจบ เพราะบทความอธิบายได้ชัดเจนมาก และชอบธีม CSS บนมือถือเป็นพิเศษ มีสรุปแบบกระชับอยู่ท้ายบทความ

  • นอกเหนือจากประเด็น copy_file_range แล้ว คงจะดีถ้าระบบไฟล์สามารถค้นหาไฟล์ขนาด 1MB ขึ้นไปที่มีแฮชเดียวกัน แล้วเลือกใช้การขจัดข้อมูลซ้ำกับไฟล์เหล่านั้นได้

  • ปัญหาของการขจัดข้อมูลซ้ำแบบดั้งเดิมคือโอเวอร์เฮดสูงเกินไป จนยากจะเห็นผลยกเว้นกับเวิร์กโหลดบางประเภท เคยเห็นผลประหยัดจากการขจัดข้อมูลซ้ำ/การบีบอัดได้ 3:1 กับเวิร์กโหลด VMWare บนอาเรย์ของ Pure และ Dell/EMC

  • ประสิทธิผลของการขจัดข้อมูลซ้ำได้รับอิทธิพลอย่างมากจากขนาดบล็อกที่นำไปแฮช ยิ่งบล็อกเล็ก โอกาสที่จะพบบล็อกที่ตรงกันก็ยิ่งสูง ส่วนตัวชอบขนาดบล็อก 4KB

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

  • ตื่นเต้นมากกับการขจัดข้อมูลซ้ำที่รวดเร็ว อยากใช้การขจัดข้อมูลซ้ำของ ZFS กับข้อมูล ArchiveBox ดูเหมือนว่าจะทำให้สามารถเก็บถาวร URL จำนวนมากและปล่อยให้ระบบไฟล์บีบอัดทุกอย่างได้

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

  • การขจัดข้อมูลซ้ำแบบทั่วไปฟังดูดีในทางทฤษฎี แต่ในทางปฏิบัติกลับไม่ค่อยได้ผล IPFS พยายามขจัดข้อมูลซ้ำโดยใช้ชิ้นข้อมูลขนาดแปรผัน แต่ในความเป็นจริงแทบไม่เห็นความแตกต่าง และมีแต่เพิ่มความซับซ้อน

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

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

  • ถ้าประสิทธิภาพการเขียนสำคัญ ก็ไม่จำเป็นต้องขจัดข้อมูลซ้ำตอนเขียน สามารถไปทำภายหลัง ทำควบคู่กัน และตั้งให้มีลำดับความสำคัญต่ำได้