Kompresi aliran on-the-fly yang tidak tumpah ke sumber daya perangkat keras?

Saya memiliki ruang disk bebas 200 GB, RAM 16 GB (yang ~ 1 GB ditempati oleh desktop dan kernel) dan 6 GB swap.

Saya memiliki SSD eksternal 240 GB, dengan 70 GB digunakan ¹ dan sisanya gratis, yang saya perlukan untuk mencadangkan ke disk saya.

Biasanya, saya akan dd if=/dev/sdb of=Desktop/disk.imgdisk terlebih dahulu, dan kemudian kompres, tetapi membuat gambar pertama bukanlah pilihan karena melakukan hal itu akan memerlukan ruang disk jauh lebih banyak daripada yang saya miliki, meskipun langkah kompresi akan menghasilkan ruang kosong yang tergencet sehingga arsip terakhir dapat dengan mudah masuk ke disk saya.

ddmenulis ke STDOUT secara default, dan gzipdapat membaca dari STDIN, jadi secara teori saya dapat menulis dd if=/dev/sdb | gzip -9 -, tetapi gzipsecara signifikan membutuhkan waktu lebih lama untuk membaca byte daripada ddmenghasilkannya.

Dari man pipe:

Data yang ditulis ke ujung tulis pipa disangga oleh kernel sampai dibaca dari ujung baca pipa.

Saya memvisualisasikan a | sebagai seperti pipa nyata - satu aplikasi mendorong data masuk dan yang lainnya mengambil data dari antrian pipa secepat mungkin.

Bagaimana ketika program di sisi kiri menulis lebih banyak data lebih cepat daripada sisi lain dari pipa yang bisa memprosesnya? Apakah akan menyebabkan penggunaan memori atau swap yang ekstrem, atau akankah kernel mencoba membuat FIFO pada disk, sehingga mengisi disk? Atau akankah hanya gagal SIGPIPE Broken pipejika buffer terlalu besar?

Pada dasarnya, ini bermuara pada dua pertanyaan:

1. Apa implikasi dan hasil dari mendorong lebih banyak data ke dalam pipa daripada dibaca pada suatu waktu?
2. Apa cara andal untuk mengompres datastream ke disk tanpa meletakkan seluruh datastream yang tidak terkompresi pada disk?

_{Catatan 1: Saya tidak bisa hanya menyalin persis 70 GB yang digunakan pertama dan berharap untuk mendapatkan sistem kerja atau sistem file, karena fragmentasi dan hal-hal lain yang akan membutuhkan konten lengkap untuk utuh.}

Secara teknis Anda bahkan tidak perlu dd:

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

Jika Anda menggunakan dd, Anda harus selalu pergi dengan lebih besar dari ukuran default seperti dd bs=1Matau menderita neraka syscall ( dddefault ukuran blok adalah 512 byte, karena itu read()dan write()s itu 4096panggilan sys per MiB, terlalu banyak overhead).

gzip -9menggunakan BANYAK lebih banyak CPU dengan sangat sedikit untuk ditampilkan. Jika gzipmemperlambat Anda, turunkan tingkat kompresi, atau gunakan metode kompresi yang berbeda (lebih cepat).

Jika Anda melakukan backup berbasis file alih-alih ddgambar, Anda dapat memiliki beberapa logika yang memutuskan apakah akan dikompres sama sekali atau tidak (tidak ada gunanya melakukannya untuk berbagai jenis file). dar( taralternative`) adalah salah satu contoh yang memiliki opsi untuk melakukannya.

Jika ruang kosong Anda NOL (karena ini adalah SSD yang andal mengembalikan nol setelah TRIM dan Anda berlari fstrimdan menjatuhkan cache) Anda juga dapat menggunakan dddengan conv=sparseflag untuk membuat gambar jarang terkompresi, loop-mountable, jarang yang menggunakan ruang disk nol untuk area nol . Membutuhkan file gambar untuk didukung oleh sistem file yang mendukung file jarang.

Atau untuk beberapa sistem file ada program yang hanya dapat gambar area yang digunakan.

ddmembaca dan menulis data satu blok pada satu waktu, dan hanya memiliki satu blok yang beredar. Begitu

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

menunjukkan bahwa ddmenggunakan sekitar 1MB memori. Anda dapat bermain-main dengan ukuran blok, dan menjatuhkan valgrind, untuk melihat efeknya pada ddkecepatan.

Ketika Anda memasang pipa gzip, ddcukup memperlambat agar sesuai gzipdengan kecepatan. Penggunaan memorinya tidak meningkat, juga tidak menyebabkan kernel untuk menyimpan buffer pada disk (kernel tidak tahu bagaimana melakukan itu, kecuali melalui swap). Pipa yang rusak hanya terjadi ketika salah satu ujung pipa mati; lihat signal(7)dan write(2)untuk detailnya.

Demikian

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

adalah cara aman untuk melakukan apa yang Anda cari.

Ketika melakukan piping, proses penulisan akhirnya diblokir oleh kernel jika proses membaca tidak berjalan. Anda dapat melihat ini dengan menjalankan

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

Anda akan melihat bahwa ddmembaca 1MB, lalu mengeluarkan write()yang duduk di sana menunggu satu menit saat sleepberjalan. Begitulah cara kedua sisi pipa menyeimbangkan: kernel blok menulis jika proses penulisan terlalu cepat, dan blok membaca jika proses membaca terlalu cepat.

Tidak ada implikasi negatif selain kinerja: pipa memiliki buffer, yang biasanya 64K, dan setelah itu, penulisan ke pipa hanya akan memblokir sampai gzipmembaca beberapa data lagi.

Menjawab pertanyaan aktual tentang cara kerjanya: "bagaimana jika program di sisi kiri menulis lebih banyak data lebih cepat daripada sisi lain dari pipa dapat berharap untuk memprosesnya?"

Ini tidak terjadi. Ada penyangga ukuran yang cukup kecil di dalam pipa; Lihat Seberapa besar penyangga pipa?

Setelah buffer pipa penuh, program pengiriman terhalang . Ketika melakukan panggilan tulis, kernel tidak akan mengembalikan kontrol ke program sampai data telah ditulis ke dalam buffer. Ini memberi waktu membaca program CPU untuk mengosongkan buffer.

Mungkin Anda hanya perlu file, lalu gunakan tar. Anda dapat mengisi dengan nol blok yang tidak mengandung apa pun yang Anda inginkan, seseorang telah bertanya tentangnya. Bersihkan ruang yang tidak digunakan dengan nol (ext3, ext4)

Lalu, ada pigzyang biasanya lebih cepat dari gzip.