Donanım kaynaklarına dökülmeyen anında akış sıkıştırma?

200 GB boş disk alanım var, 16 GB RAM (bunlardan ~ 1 GB masaüstü ve çekirdeğin kapladığı) ve 6 GB takas.

240 GB harici SSD'm var, 70 GB kullanılmış ¹ ve gerisi ücretsiz, diskime yedeklemem gerekiyor.

Normalde, önce dd if=/dev/sdb of=Desktop/disk.imgdiski ve ardından sıkıştırırdım, ancak görüntüyü ilk yapmak bir seçenek değildir, çünkü bunu yapmak benimkinden çok daha fazla disk alanı gerektirir, ancak sıkıştırma adımı boş alanın ezilmesine neden olur. son arşiv diskime kolayca sığabiliyor.

ddvarsayılan olarak STDOUT'a yazar ve STDIN'den gzipokuyabilir, bu yüzden teoride yazabilirim dd if=/dev/sdb | gzip -9 -, ancak gzipbaytları okumak ddonları üretebileceklerinden çok daha uzun sürer .

Kimden man pipe:

Borunun yazma ucuna yazılan veriler, borunun okunan ucundan okunana kadar çekirdek tarafından tamponlanır.

|Birinin gerçek bir boru gibi göründüğünü hayal ediyorum - biri uygulamada veri toplayan, diğeri ise borunun kuyruğundan mümkün olan en kısa sürede veri alıyor.

Sol taraftaki program borunun diğer tarafına göre daha hızlı veri yazdığında ne işleyeceğini umarız? Aşırı belleğe mi yoksa takas kullanımına mı neden olacak, yoksa çekirdek diskte bir FIFO oluşturmaya çalışıp diski doldurmaya çalışacak mı? Yoksa SIGPIPE Broken pipetampon çok büyükse sadece başarısız olur ?

Temel olarak, bu iki soruya yol açar:

1. Bir kerede okunandan daha fazla veriyi bir boruya aktarmanın sonuçları ve sonuçları nelerdir?
2. Sıkıştırılmamış tüm veri akışını diske koymadan bir veri akışını diske sıkıştırmanın güvenilir yolu nedir?

_{Not 1: İlk kullanılan 70 GB'nin tamamını tam olarak kopyalayamıyorum ve tam bir içeriğin bozulmasını gerektiren parçalanma ve diğer şeyler nedeniyle bir çalışma sistemi veya dosya sistemi almayı umuyorum.}

Teknik olarak ihtiyacınız yok bile dd:

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

Eğer kullanımını yaparsanız dd, her zaman gibi varsayılan blok boyutundan daha büyük ile gitmeli dd bs=1Mveya syscall cehennem acı ( ddo zamandan beri 'ın varsayılan blokboyu, 512 bayt read()s ve write()var ler 4096başına syscalls MiBçok fazla havai).

gzip -9bunun için göstermek için çok az bir LOT daha fazla CPU kullanır. Eğer gzipsizi yavaşlatıyor, sıkıştırma düzeyini düşürmek veya farklı (daha hızlı) sıkıştırma yöntemini kullanın.

ddGörüntüler yerine dosya tabanlı yedeklemeler yapıyorsanız , sıkıştırıp sıkıştırmamaya karar veren bir mantığa sahip olabilirsiniz (çeşitli dosya türleri için bunu yapmanın bir anlamı yoktur). dar( taralternatif`) bunu yapma seçeneği olan bir örnektir.

Boş yer SIFIR ise (bir SSD çünkü güvenilir döner TRIM sonra sıfır ve kaçtın o fstrimve önbelleklerini düştü) ayrıca kullanabilirsiniz ddile conv=sparsekullanımları sıfır alanlar için disk alanı sıfır olduğu sıkıştırılmamış, döngü monte, seyrek bir görüntü oluşturmak için bayrak . Görüntü dosyasının, seyrek dosyaları destekleyen bir dosya sistemi tarafından desteklenmesini gerektirir.

Alternatif olarak, bazı dosya sistemlerinde yalnızca kullanılan alanları görüntüleyebilecek programlar vardır.

ddher seferinde bir blok veri okur ve yazar ve sadece bir blok üstündür. Yani

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

ddyaklaşık 1 MB hafıza kullandığını gösterir . Hızı valgrindüzerindeki etkisini görmek için blok büyüklüğü ile oynayabilir ve düşürebilirsiniz dd.

İçine girdiğinde gzip, ddhızını eşleştirmek için yavaşla gzip. Onun bellek kullanımı artmaz, ne de (çekirdek dışında bunun nasıl bilmiyor diskteki tamponlarını saklamak için çekirdek neden vermez aracılığıyla takas). Kırık bir boru yalnızca borunun uçlarından biri öldüğünde gerçekleşir; ayrıntılar için bkz. signal(7)ve write(2).

Böylece

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

peşinde olanı yapmak için güvenli bir yoldur.

Borularda, okuma işlemi devam etmiyorsa, yazma işlemi çekirdek tarafından engellenir. Bunu çalıştırarak görebilirsiniz

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

1 ddMB okuduğunu görüyorsunuz , daha sonra yayınlanırken write()orada bir dakika beklediğini görüyorsunuz sleep. Borunun her iki tarafı da böyle dengelendi: Çekirdek blokları, yazma işleminin çok hızlı olup olmadığını ve okuma işleminin çok hızlı olup olmadığını da okur.

Performanstan başka olumsuz bir çıkarım yoktur: borunun genellikle 64K olan bir tamponu vardır ve bundan sonra boruya bir yazma işlemi gzipdaha fazla veri okuyana kadar bloke olur .

Asıl soruyu nasıl çalıştığına göre cevaplamak: "eğer sol taraftaki program borunun diğer tarafından daha hızlı veri yazıyorsa, işleyebileceğini umar?"

Bu olmaz. Boruda oldukça küçük, sınırlı boyutlu bir tampon var; bkz . Boru tamponu ne kadar büyük?

Boru tamponu dolduğunda, gönderen program bloke eder . Yazma çağrısı yaptığında, veriler arabellek içine yazılana kadar çekirdek programa kontrolü geri döndürmez. Bu, okuma programına CPU'nun arabellek boşaltılacağı zamanı verir.

Belki sadece dosyalara ihtiyacınız vardır, sonra tar kullanın. İstediğiniz herhangi bir şeyi içermeyen blokları sıfırlarla doldurabilirsiniz, biri zaten sormuş. Kullanılmayan alanı sıfırlarla temizleyin (ext3, ext4)

Sonra, pigzgenellikle daha hızlı olan var gzip.