Compressione del flusso al volo che non si riversa in risorse hardware?

Ho 200 GB di spazio libero su disco, 16 GB di RAM (di cui ~ 1 GB occupati dal desktop e dal kernel) e 6 GB di swap.

Ho un SSD esterno da 240 GB, con 70 GB utilizzati ¹ e il resto libero, di cui ho bisogno per eseguire il backup sul mio disco.

Normalmente, prima vorrei dd if=/dev/sdb of=Desktop/disk.imgil disco e poi comprimerlo, ma fare prima l'immagine non è un'opzione poiché farlo richiederebbe molto più spazio su disco di quello che ho, anche se il passaggio di compressione comporterà la compressione dello spazio libero in modo che il l'archivio finale può facilmente adattarsi al mio disco.

ddscrive su STDOUT per impostazione predefinita e gzippuò leggere da STDIN, quindi in teoria posso scrivere dd if=/dev/sdb | gzip -9 -, ma gzipimpiega molto più tempo a leggere i byte di ddquanti ne possano produrre.

Da man pipe:

I dati scritti all'estremità di scrittura della pipe vengono bufferizzati dal kernel fino a quando non vengono letti dall'estremità di lettura della pipe.

Visualizzo a |come un vero pipe - un'applicazione che inserisce i dati e l'altra che estrae i dati dalla coda del pipe il più rapidamente possibile.

Cosa succede quando il programma sul lato sinistro scrive più dati più rapidamente di quanto l'altro lato della pipe possa sperare di elaborarlo? Provocherà un utilizzo estremo della memoria o dello scambio o il kernel tenterà di creare un FIFO su disco, riempiendo così il disco? O fallirà SIGPIPE Broken pipese il buffer è troppo grande?

Fondamentalmente, questo si riduce a due domande:

1. Quali sono le implicazioni e i risultati di inserire più dati in una pipe di quanti ne vengano letti alla volta?
2. Qual è il modo affidabile per comprimere un flusso di dati su disco senza mettere l'intero disco di dati non compresso sul disco?

_{Nota 1: non posso semplicemente copiare esattamente i primi 70 GB usati e mi aspetto di ottenere un sistema o un filesystem funzionante, a causa della frammentazione e di altre cose che richiedono che il contenuto completo sia intatto.}

Tecnicamente non hai nemmeno bisogno di dd:

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

Se fate uso dd, si dovrebbe sempre andare con i più grandi del blocco di default come dd bs=1Mo subire l'inferno syscall ( dd's-blocco di default è 512 byte, in quanto read()S e write()s che è in 4096chiamate di sistema per MiB, troppo in alto).

gzip -9usa MOLTA CPU in più con pochissimo da mostrare. Se ti gzipsta rallentando, abbassa il livello di compressione o usa un metodo di compressione diverso (più veloce).

Se stai eseguendo backup basati su file anziché ddimmagini, potresti avere una logica che decide se comprimere o meno (non ha senso farlo per vari tipi di file). dar( taralternativa`) è un esempio che ha opzioni per farlo.

Se il tuo spazio libero è ZERO (perché è un SSD che restituisce in modo affidabile zero dopo TRIM e hai eseguito fstrime rilasciato cache) puoi anche usare ddcon conv=sparseflag per creare un'immagine sparsa, non montabile in loop, montabile e che utilizza zero spazio su disco per le aree zero . Richiede che il file di immagine sia supportato da un filesystem che supporti file sparsi.

In alternativa per alcuni filesystem esistono programmi in grado di visualizzare solo le aree utilizzate.

ddlegge e scrive i dati un blocco alla volta e ha sempre un blocco in sospeso. Così

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

mostra che ddutilizza circa 1 MB di memoria. Puoi giocare con la dimensione del blocco e rilasciarlo valgrindper vedere l'effetto sulla ddvelocità.

Quando entri in gioco gzip, ddsemplicemente rallenta per adattarsi alla gzipvelocità. Il suo utilizzo della memoria non aumenta, né fa sì che il kernel memorizzi i buffer sul disco (il kernel non sa come farlo, tranne tramite swap). Un tubo rotto si verifica solo quando una delle estremità del tubo muore; vedi signal(7)e write(2)per i dettagli.

così

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

è un modo sicuro per fare ciò che cerchi.

Durante il piping, il processo di scrittura finisce per essere bloccato dal kernel se il processo di lettura non tiene il passo. Puoi vederlo correndo

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

Vedrai che ddlegge 1 MB, quindi emette un write()che rimane lì in attesa di un minuto mentre sleepcorre. Ecco come entrambi i lati di una pipe si bilanciano: i blocchi del kernel scrivono se il processo di scrittura è troppo veloce e bloccano le letture se il processo di lettura è troppo veloce.

Non ci sono implicazioni negative oltre alle prestazioni: la pipe ha un buffer, che di solito è 64 KB, e successivamente, una scrittura sulla pipe semplicemente bloccherà fino a quando non gziplegge altri dati.

Rispondere alla domanda reale su come funziona: "che cosa succede se il programma sul lato sinistro scrive più dati più rapidamente di quanto l'altro lato del tubo possa sperare di elaborarlo?"

Questo non succede. C'è un buffer abbastanza piccolo, di dimensioni limitate nel tubo; vedi Quanto è grande il buffer del tubo?

Quando il buffer delle pipe è pieno, il programma di invio si blocca . Quando effettua una chiamata di scrittura, il kernel non restituirà il controllo al programma finché i dati non sono stati scritti nel buffer. Questo dà al programma di lettura il tempo della CPU in cui svuotare il buffer.

Forse hai solo bisogno dei file, quindi usa tar. Puoi riempire di zeri i blocchi che non contengono nulla che desideri, qualcuno lo ha già chiesto. Cancella spazio inutilizzato con zeri (ext3, ext4)

Quindi, c'è quello pigzche di solito è più veloce di gzip.