วิธีคัดลอกระบบไฟล์ btrfs

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

ดูเหมือนว่าสำเนาระดับบล็อก (เช่นมีdd) ไม่ได้เป็นความคิดที่ดีเพราะมันทำซ้ำ UUID และไม่มีทางที่จะสามารถเปลี่ยนมันเห็นได้ชัด

ตัวเลือก 1 - คัดลอกข้อมูลเป็นใบ้จากนั้นเปลี่ยน UUID

ตรวจสอบให้แน่ใจว่าไม่ได้ต่อเชื่อมพาร์ติชันต้นทางและจะไม่ถูกเมาต์อัตโนมัติ

ใช้อย่างใดอย่างหนึ่งdd(ช้าใบ้) หรือpartclone.btrfs -b -s /dev/src -o /dev/target

ใช้btrfstune -uเพื่อเปลี่ยน UUID หลังจากการคัดลอกและก่อนการติดตั้ง

คำเตือนการสูญเสียข้อมูล : ทำไม่ได้พยายามที่จะ (อัตโนมัติ) ติดทั้งต้นฉบับหรือคัดลอกจน UUID มีการเปลี่ยนแปลง

ตัวเลือก 2 - btrfs-clone

ฉันไม่ได้ลองเป็นการส่วนตัวbtrfs-cloneแต่เป็นการอ้างว่าจะโคลนระบบไฟล์ BTRFS ที่มีอยู่ไปเป็นระบบใหม่โดยทำการโคลนแต่ละไดรฟ์ย่อยตามลำดับ

ฉันไม่พบวิธีแก้ปัญหาใด ๆ ณ วันนี้ (2016-05-06) แต่แก้ไขปัญหาสำหรับวัตถุประสงค์ของฉันรวมถึงการจัดการ Copy-on-Write ขั้นตอนในการ "โคลน" /sourceถึง/targetคือ:

1. รับรายชื่อของ subvolumes รับคำสั่งจาก:ogen btrfs subvolume list -qu --sort ogen /sourceการเรียงลำดับอาจเพียงพอที่จะรับประกันได้ว่าสแน็ปช็อตหรือไดรฟ์ย่อยที่ขึ้นอยู่กับรายการก่อนหน้าจะได้รับการจัดการก่อน นี่เป็นสิ่งสำคัญสำหรับการจัดการกับการคัดลอกเมื่อเขียนเนื่องจากเราจำเป็นต้องโอนปริมาณพื้นฐานก่อน

2. ทำให้ subvolumes btrfs property set -ts /source/some-volume ro trueทั้งหมดอ่านอย่างเดียวโดยใช้

3. ทีนี้สำหรับแต่ละหัวข้อย่อยจากรายการด้านบนเริ่มต้นที่ด้านบนทำต่อไปนี้:

   1. หากปริมาณไม่มี UUID หลัก (แสดงเป็น-) หรือ UUID หลักไม่มีอยู่อีกต่อไปในรายการให้รัน:btrfs send /source/some/volume | btrfs receive /target/some/

   2. หากปริมาณมี UUID หลักที่ยังคงมีอยู่เราควรโอนย้ายไปแล้วเนื่องจาก--sort ogenและเราสามารถใช้เป็นฐานเพื่อหลีกเลี่ยงการทำซ้ำข้อมูล ดังนั้นค้นหาพา ธ ของ UUID ของผู้ปกครองในรายการและเรียกใช้: btrfs send -p /source/parent/volume/ -c /source/parent/volume/ /source/some/volume/ | btrfs receive /target/some/(btrfs อาจจะคาดเดา-pข้อโต้แย้งโดยอัตโนมัติ แต่ฉันชอบที่จะชัดเจน)

   3. btrfs property set -ts /source/some/volume ro false; btrfs property set -ts /target/some/volume ro falseหลังจากที่ทำงานของคำสั่งดังกล่าวทำให้เป้าหมายและแหล่งที่มาอ่านเขียนอีกครั้ง: สามารถข้ามขั้นตอนนี้ได้หากแหล่งที่มาเป็นแบบอ่านอย่างเดียวก่อนหน้านี้

สิ่งนี้ควรจัดการกับหลายกรณี คำเตือน:

1. อาจมีปัญหาบางอย่างเกี่ยวกับการสั่งซื้อเมื่อทำการซ้อน subvolumes / snapshots

2. เห็นได้ชัดว่ากระบวนการทั้งหมดนั้นสนุกมากขึ้นเมื่อใช้สคริปต์

3. btrfs sendยอมรับ-cข้อโต้แย้งหลายแหล่งที่มาของโคลน ( ) มันอาจเป็นประโยชน์ที่ไม่เพียง แต่ระบุเส้นทางเสียงของผู้ปกครอง แต่ยังรวมถึงเส้นทางของบรรพบุรุษหรือเพียงแค่ปริมาณที่ส่งก่อนหน้านี้ มันไม่ได้สร้างความแตกต่างที่นี่ แต่อาจเป็นเพียงการเดาเพื่อช่วยหลีกเลี่ยงการทำซ้ำข้อมูลในบางกรณี

4. ฉันไม่แน่ใจว่าข้อมูลเมตาในสแนปชอตหรือ subvolumes หายไประหว่างทางแต่เพียงเกี่ยวกับทุกสิ่งที่น่าสนใจสำหรับกรณีการใช้งานส่วนใหญ่ควรได้รับการเก็บรักษาไว้

กระบวนการทั้งหมดช่วยให้ฉันถ่ายโอนระบบไฟล์ 800 GB ที่ใช้ 3.8 GB (ตามdf) ไปยังอิมเมจ 10 GB ที่ใช้ 3.8 GB การถ่ายโอนโดยไม่มี-pและ-cจะใช้ประมาณ 190 GB ดังนั้นการทำสำเนาข้อมูลจึงหลีกเลี่ยงได้แน่นอน

ฉันได้สร้างเครื่องมือหลามซึ่งสามารถทำได้ ฉันทำสิ่งนี้เพราะฉันได้ลองวิธีการของ @Thomas Luzat ทั้งของฉันเองและ @Johannes Ernst และการใช้พื้นที่สองเท่าจาก 20GB ถึง 40GB ในขั้นตอนการโคลนนิ่ง ฉันคิดว่าบางสิ่งจำเป็นต้องมีประสิทธิภาพมากขึ้น

พิจารณาประวัติระบบไฟล์ทั่วไปนี้:

current ---------------------------------\
             |       |        |          |
           snap4   snap3    snap2      snap1

ด้วยอัลกอริธึมของโทมัส "กระแส" จะถูกโคลนก่อนและสแนปชอตทั้งหมด (เป็นสแน็ปช็อตของอดีตรัฐของ "กระแส") จะใช้ "กระแส" เป็นแหล่งกำเนิด / ผู้ปกครองโคลน เห็นได้ชัดว่ามันจะดีกว่าถ้าจะยึดฐาน snap3 บน snap4, snap2 บน snap3 ฯลฯ

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

คุณสามารถอ่านรายละเอียดได้ที่หน้า GitHubหากคุณสนใจ

มีคำถามคล้ายกันใน unix.stackexchange.comที่ชี้ไปที่ partclone.btrfs แต่ฉันไม่ทราบรายละเอียดใด ๆ เกี่ยวกับเรื่องนี้

นอกจากนี้ยังมีการอภิปรายในรายชื่อส่งเมลเคอร์เนลไม่ได้ดูมีแนวโน้ม ...

ด้วยbtrfs-sendซึ่งครั้งสุดท้ายที่ฉันเห็นก็ยังแพทช์ทดลองลอยรอบในรายการ btrfs ทางไปรษณีย์