การบีบอัดสตรีมแบบทันทีที่ไม่กระจายไปสู่ทรัพยากรฮาร์ดแวร์?

ฉันมีพื้นที่ว่างบนดิสก์ 200 GB, RAM 16 GB (ที่เดสก์ท็อปและเคอร์เนลประมาณ ~ 1 GB) และ swap 6 GB

ฉันมี SSD ภายนอก 240 GB ที่มี 70 GB ใช้¹และที่เหลือฟรีซึ่งฉันต้องสำรองข้อมูลลงดิสก์

โดยปกติแล้วฉันต้องการdd if=/dev/sdb of=Desktop/disk.imgดิสก์ก่อนแล้วจึงบีบอัด แต่การสร้างอิมเมจก่อนไม่ใช่ตัวเลือกเนื่องจากการทำเช่นนั้นจะต้องใช้พื้นที่ดิสก์มากกว่าที่ฉันมีแม้ว่าขั้นตอนการบีบอัดจะส่งผลให้พื้นที่ว่างถูกบีบอัดดังนั้น ไฟล์เก็บถาวรสุดท้ายสามารถใส่ลงในดิสก์ของฉันได้อย่างง่ายดาย

ddเขียนไป STDOUT โดยค่าเริ่มต้นและgzipสามารถอ่านได้จาก STDIN ดังนั้นในทฤษฎีฉันจะเขียนdd if=/dev/sdb | gzip -9 -แต่gzipจะใช้เวลานานมากในการอ่านไบต์กว่าddสามารถผลิตได้

จากman pipe:

ข้อมูลที่เขียนไปยังปลายการเขียนของไพพ์จะถูกบัฟเฟอร์โดยเคอร์เนลจนกว่าจะถูกอ่านจากการอ่านที่ปลายของไพพ์

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

จะเกิดอะไรขึ้นเมื่อโปรแกรมทางด้านซ้ายเขียนข้อมูลได้เร็วกว่าอีกด้านหนึ่งของไปป์สามารถหวังที่จะประมวลผลได้ มันจะทำให้เกิดการใช้หน่วยความจำมากหรือการแลกเปลี่ยนหรือเคอร์เนลจะพยายามสร้าง FIFO บนดิสก์จึงเติมดิสก์? หรือมันจะล้มเหลวSIGPIPE Broken pipeถ้าบัฟเฟอร์มีขนาดใหญ่เกินไป?

โดยพื้นฐานแล้วสิ่งนี้จะลดลงเหลือสองคำถาม:

1. อะไรคือความหมายและผลลัพธ์ของการผลักข้อมูลเข้าสู่ท่อมากกว่าที่อ่านได้ในแต่ละครั้ง?
2. อะไรคือวิธีที่เชื่อถือได้ในการบีบอัดดาต้าสตรีมไปยังดิสก์โดยไม่ต้องบีบอัดดาต้าสตรีมทั้งหมดลงบนดิสก์

_{หมายเหตุ 1: ฉันไม่สามารถคัดลอก 70 GB แรกที่ใช้ไปอย่างแน่นอนและคาดว่าจะได้รับระบบการทำงานหรือระบบไฟล์เนื่องจากการแตกแฟรกเมนต์และสิ่งอื่น ๆ ซึ่งจะต้องใช้เนื้อหาแบบเต็มเพื่อให้สมบูรณ์}

ในทางเทคนิคคุณไม่จำเป็นต้องdd:

gzip < /dev/drive > drive.img.gz

หากคุณใช้ddคุณควรมีขนาดใหญ่กว่าขนาดบล็อกเริ่มต้นที่ชอบdd bs=1Mหรือประสบนรก syscall เสมอ ( ddขนาดบล็อกเริ่มต้นคือ 512 ไบต์เนื่องจากread()เป็นwrite()ขนาด4096syscalls ต่อMiBค่าใช้จ่ายมากเกินไป)

gzip -9ใช้ CPU มากขึ้นและแสดงน้อยมาก หากgzipคุณทำให้ช้าลงลดระดับการบีบอัดหรือใช้วิธีการบีบอัด (เร็วกว่า) อื่น

หากคุณทำการสำรองข้อมูลโดยใช้ไฟล์แทนที่จะเป็นddรูปคุณอาจมีตรรกะบางอย่างที่ตัดสินใจว่าจะบีบอัดไฟล์ทั้งหมดหรือไม่ dar( tarทางเลือก `) เป็นตัวอย่างหนึ่งที่มีตัวเลือกให้ทำ

หากพื้นที่ว่างของคุณเป็นศูนย์ (เพราะเป็น SSD ที่ให้ผลตอบแทนเป็นศูนย์ได้อย่างน่าเชื่อถือหลังจาก TRIM และคุณรันfstrimและแคชหายไป) คุณยังสามารถใช้ddกับconv=sparseแฟล็กเพื่อสร้างอิมเมจแบบกระจายที่ไม่บีบอัดและติดตั้งได้ . ต้องการไฟล์รูปภาพที่จะสำรองข้อมูลโดยระบบไฟล์ที่รองรับไฟล์แบบกระจาย

อีกทางเลือกหนึ่งสำหรับระบบไฟล์บางโปรแกรมมีโปรแกรมที่สามารถอิมเมจพื้นที่ที่ใช้เท่านั้น

ddอ่านและเขียนข้อมูลทีละบล็อกและจะมีหนึ่งบล็อกที่คงค้างเท่านั้น ดังนั้น

valgrind dd if=/dev/zero status=progress of=/dev/null bs=1M

แสดงให้เห็นว่าddใช้หน่วยความจำประมาณ 1MB คุณสามารถเล่นกับขนาดบล็อกและปล่อยvalgrindเพื่อดูผลddของความเร็ว

เมื่อคุณเข้าไปในท่อgzip, ddเพียงแค่ช้าลงจะมีการแข่งขันgzip's ความเร็ว การใช้หน่วยความจำไม่เพิ่มขึ้นและไม่ทำให้เคอร์เนลเก็บบัฟเฟอร์บนดิสก์ (เคอร์เนลไม่ทราบวิธีการทำยกเว้นผ่านการสลับ) ท่อแตกจะเกิดขึ้นเฉพาะเมื่อปลายด้านใดด้านหนึ่งของท่อตาย ดูsignal(7)และwrite(2)เพื่อดูรายละเอียด

ดังนั้น

dd if=... iconv=fullblock bs=1M | gzip -9 > ...

เป็นวิธีที่ปลอดภัยในการทำสิ่งที่คุณต้องการ

เมื่อการไพพ์กระบวนการเขียนสิ้นสุดลงจะถูกบล็อกโดยเคอร์เนลหากกระบวนการอ่านไม่ได้ติดตาม คุณสามารถเห็นสิ่งนี้ได้ด้วยการวิ่ง

strace dd if=/dev/zero bs=1M | (sleep 60; cat > /dev/null)

คุณจะเห็นว่าddอ่าน 1MB จากนั้นออกwrite()ที่รออยู่หนึ่งนาทีในขณะที่sleepทำงาน นั่นคือวิธีที่สมดุลทั้งสองด้านของท่อ: เคอร์เนลบล็อกเขียนว่ากระบวนการเขียนเร็วเกินไปหรือไม่และบล็อกจะอ่านหากกระบวนการอ่านเร็วเกินไป

ไม่มีผลกระทบเชิงลบอื่น ๆ นอกจากประสิทธิภาพ: ไปป์มีบัฟเฟอร์ซึ่งโดยปกติคือ 64K และหลังจากนั้นการเขียนไปยังไพพ์จะบล็อกเพียงจนกว่าจะgzipอ่านข้อมูลเพิ่มเติมบางส่วน

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

สิ่งนี้ไม่ได้เกิดขึ้น มีบัฟเฟอร์ขนาดเล็กที่ค่อนข้าง จำกัด ในไพพ์ ดูท่อบัฟเฟอร์ใหญ่แค่ไหน?

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

บางทีคุณแค่ต้องการไฟล์จากนั้นใช้ tar คุณสามารถเติมศูนย์บล็อกที่ไม่มีสิ่งที่คุณต้องการมีใครบางคนถามไปแล้ว ล้างพื้นที่ที่ไม่ได้ใช้ด้วยค่าศูนย์ (ext3, ext4)

จากนั้นมีซึ่งมักจะเร็วกว่าpigzgzip