กำลังอัปเดตการตรวจสอบกับ zfs หรือไม่


13

ฉันเพิ่งเปลี่ยนchecksumคุณสมบัติในหนึ่งในระบบไฟล์ zfs ที่ไม่ซ้ำกันของฉันเป็นsha256จากon(fletcher4) เพื่อรองรับการส่งไอน้ำจำลองแบบที่ซ้ำกันได้ดีขึ้นเช่นเดียวกับในคำสั่งzfs send -DR -I _starting-snaphot_ _ending-snapshot_นี้

อย่างไรก็ตาม zfs manpage มีสิ่งนี้จะพูดเกี่ยวกับsend -D:

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

zfs manpage ระบุสิ่งนี้เกี่ยวกับchecksumคุณสมบัติ:

การเปลี่ยนแปลงคุณสมบัตินี้มีผลกับข้อมูลที่เพิ่งเขียนใหม่เท่านั้น

ฉันไม่มีความปรารถนาที่จะเชื่อใจ fletcher4 ข้อเสียคือแตกต่างจาก SHA256, fletcher4 ไม่ใช่ฟังก์ชันแฮชหลอกแบบสุ่มดังนั้นจึงไม่สามารถเชื่อถือได้ว่าจะไม่ชนกัน ดังนั้นจึงเหมาะสำหรับการลดความซ้ำซ้อนเมื่อรวมกับตัวเลือก 'ตรวจสอบ' ซึ่งตรวจจับและแก้ไขการชนกันของแฮช

ฉันจะอัปเดต checksums ของระบบไฟล์ได้อย่างไรโดยเฉพาะอย่างยิ่งโดยไม่ต้องตัดระบบ

คำตอบ:


11

ในการเปลี่ยนคุณสมบัติ (ไม่ว่าจะเป็นการบีบอัด, การลดความซ้ำซ้อนหรือการตรวจสอบ) ของข้อมูลที่เขียนไว้แล้ววิธีการ zfs คือการเรียกใช้ข้อมูลผ่านzfs send | zfs receiveลำดับ เห็นได้ชัดว่าคุณไม่จำเป็นต้องออฟไลน์ระบบ แต่คุณจะต้อง

  1. มีทรัพยากรเพียงพอใน zpool ของคุณ / บนระบบเพื่อเก็บสำเนาข้อมูลที่ซ้ำซ้อนสองชุด
  2. การหยุดทำงานของชุดข้อมูลในขณะที่คุณอาจจำเป็นต้องทำลายมันหรือเปลี่ยนชื่อในกระบวนการ
  3. มีเวลาและความอดทนเพียงพอสำหรับการดำเนินการ

เมื่อคุณใช้การขจัดความซ้ำซ้อนสำหรับ zpool อยู่แล้วการรัน a zfs send | zfs receiveด้วยปลายทางบนพูลเดียวกับแหล่งที่มาจะใช้พื้นที่ที่จำเป็นสำหรับบล็อกเมทาดาทาที่เพิ่งเขียนใหม่เท่านั้น แต่เตรียมพร้อมสำหรับการคัดลอกที่จะใช้เวลาสักครู่ - การลบข้อมูลอาจช้ามากโดยเฉพาะถ้าคุณไม่มี RAM เพียงพอที่จะเก็บตาราง dedup ทั้งหมดใน RAM

คุณจะต้องหยุดการเขียนทั้งหมดเพื่อสร้างสำเนาชุดข้อมูลที่มีสิทธิ์ขั้นสุดท้าย แต่สามารถลดเวลาหยุดทำงานได้โดยการคัดลอกจากสแน็ปช็อตก่อนหยุดการเขียนทั้งหมดและเพิ่มzfs send -i | zfs receiveขั้นตอนเป็นขั้นตอนสุดท้าย


ไม่ชัดเจนเลยสำหรับฉันที่zfs receiveอัปเดตข้อมูลเมตาของระบบไฟล์ สำหรับฉันดูเหมือนว่ามันจะเร็วกว่ามากถ้าเพียงเอาเมทาดาทาตามที่เป็นอยู่ อย่างไรก็ตามการทำเช่นนั้นอาจเป็นไปไม่ได้เนื่องจากบล็อกของเช็คซัมมากกว่าระดับไฟล์ ในกรณีzfs send | zfs receiveนั้นจะเป็นฐานที่ยอมรับได้สำหรับโซลูชัน
84104

1
ส่ง zfs zfs recv จะเปลี่ยนข้อมูลเมตาทั้งหมดอย่างมีประสิทธิภาพ (ตัวเลือกการบีบอัดตัวเลือกตรวจสอบตัวเลือกซ้ำซ้อน) zfs send กำลังสร้างวัตถุที่คุณนำเข้าไปใช้โดยใช้ zfs recv ซึ่งเขียนออกมาเหมือนว่ามันเป็นข้อมูลใหม่ทั้งหมด อย่างไรก็ตาม - ฉันคิดว่าคุณอาจเข้าใจผิดเกี่ยวกับ zfs send | recv เกี่ยวกับการขจัดข้อมูลซ้ำซ้อน zfs send -D พยายามที่จะลดความซ้ำซ้อนของข้อมูล / ภายในสตรีมตัวเอง /, ไม่รักษาความซ้ำซ้อนของข้อมูลที่มีอยู่จากชุดข้อมูลต้นทาง นี่คือสาเหตุที่ไม่มีข้อกำหนดที่ด้าน recv ได้เปิดใช้งานการหักเงินซ้ำซ้อนในชุดข้อมูลปลายทาง
Nex7

เพื่ออธิบายเพิ่มเติม - ขณะนี้ยังไม่มีวิธีในการ zfs send | recv ข้อมูลที่ซ้ำซ้อนในลักษณะที่ทุกอย่างที่ข้ามสายเป็นสำเนาเดียวของข้อมูลที่ซ้ำซ้อนและรายการตาราง dedupe ที่เกี่ยวข้อง ไม่แม้ว่าแหล่งที่มาและปลายทางจะซิงค์กันและคุณกำลังส่งอะไรมากกว่าสแนปชอตที่เพิ่มขึ้น ZFS ยังคงลูกโป่งส่งข้อมูลให้เต็มขนาดหากข้อมูลที่อยู่ในนั้นไม่สามารถขจัดข้อมูลซ้ำได้ / ภายในขอบเขตของสตรีมเอง / คุณอาจมีข้อมูลที่ซ้ำซ้อนได้ง่ายใน POOL DDT แต่ในฐานะที่เป็นวัตถุส่งขนาดเล็ก
Nex7
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.