Rendi la copia del disco / disco più lenta

Esiste un metodo per rallentare il processo di copia su Linux?

Ho un file di grandi dimensioni, diciamo 10 GB, e vorrei copiarlo in un'altra directory, ma non voglio copiarlo alla massima velocità. Diciamo che vorrei copiarlo con la velocità di 1 mb / s, non più veloce. Vorrei usare un cpcomando Linux standard .

È possibile? (Se sì, come?)

Modifica : quindi, aggiungerò più contesto a ciò che sto cercando di ottenere.

Ho un problema con il sistema ArchLinux durante la copia di file di grandi dimensioni tramite USB (su un pendrive, un disco USB, ecc.). Dopo aver riempito la cache del buffer USB, il mio sistema smette di rispondere (anche il mouse si ferma; si sposta solo sporadicamente). L'operazione di copia è ancora in corso, ma richiede il 100% delle risorse della scatola. Al termine dell'operazione di copia, tutto torna alla normalità, tutto risponde perfettamente.

Forse è un errore hardware, non lo so, ma so di avere due macchine con questo problema (entrambi sono su ArchLinux, uno è un desktop box, il secondo è un laptop).

La "soluzione" più semplice e veloce a questo (sono d'accordo che non è la soluzione "reale", solo un brutto "hack") sarebbe quella di impedire che questo buffer si riempia copiando il file con una velocità di scrittura media dell'unità USB, per questo sarebbe abbastanza.

Puoi strozzare un tubo con pv -qL(o cstream -tfornisce funzionalità simili)

tar -cf - . | pv -q -L 8192 | tar -C /your/usb -xvf -

-q rimuove i rapporti sui progressi di stderr.

Il -Llimite è in byte.

Maggiori informazioni sulla --rate-limit/-Lbandiera dal man pv:

-L RATE, --rate-limit RATE

    Limit the transfer to a maximum of RATE bytes per second.
    A suffix of "k", "m", "g", or "t" can be added to denote
    kilobytes (*1024), megabytes, and so on.

Questa risposta originariamente indicava throttlema quel progetto non è più disponibile, quindi è scivolato fuori da alcuni sistemi di pacchetti.

Invece di cp -a /foo /barte puoi anche usare rsynce limitare la larghezza di banda di cui hai bisogno.

Dal rsyncmanuale di:

--bwlimit=KBPS

limitare la larghezza di banda I / O; KByte al secondo

Quindi, il comando actuall, mostrando anche l'avanzamento, sarebbe simile al seguente:

rsync -av --bwlimit=100 --progress /foo /bar

Suppongo che stai cercando di non interrompere altre attività. Le versioni recenti di Linux includono ioniceciò che consente di controllare la pianificazione di IO.

Oltre a consentire varie priorità, esiste un'opzione aggiuntiva per limitare IO a momenti in cui il disco è inattivo. Il comando man ionicevisualizzerà la documentazione.

Prova a copiare il file usando un comando come:

ionice -c 3 cp largefile /new/directory

Se le due directory si trovano sullo stesso dispositivo, è possibile che il collegamento del file faccia ciò che si desidera. Se si esegue la copia a scopo di backup, non utilizzare questa opzione. lnè estremamente veloce in quanto il file stesso non viene copiato. Provare:

ln largefile /new/directory

Oppure se vuoi semplicemente accedervi da una directory su un altro dispositivo prova:

ln -s largefile /new/directory

Se la ionicesoluzione non è sufficiente (perché) e vuoi davvero limitare l'I / O a un valore assoluto, ci sono diverse possibilità:

1. la probabilmente più facile: ssh. Ha un limite di larghezza di banda integrato. Utilizzeresti ad esempio tar(invece di cp) o scp(se è abbastanza buono; non so come gestisca i collegamenti simbolici e quelli fissi) o rsync. Questi comandi possono reindirizzare i loro dati ssh. Nel caso in cui tartu scriva a /dev/stdout(o -) e lo installi nelssh client che ne esegue un altro tarsul lato "remoto".

2. elegante ma non nel kernel vanilla (AFAIK): il target del mapper del dispositivo ioband. Questo, ovviamente, funziona solo se è possibile smontare il volume di origine o di destinazione.

3. un po 'di divertimento auto-scritto: grep "^write_bytes: " /proc/$PID/ioti dà la quantità di dati che un processo ha scritto. Potresti scrivere uno script che inizia cpin background, dorme per esempio 1/10 di secondo, interrompe il cpprocesso in background ( kill -STOP $PID), controlla la quantità che è stata scritta (e leggi sullo stesso valore in questo caso), calcola per quanto tempo cpdeve mettere in pausa per portare la velocità di trasferimento media al valore desiderato, dormire per quel tempo, sveglia cp( kill -CONT $PID) e così via.

Il tuo problema probabilmente non è con il tuo computer, di per sé, probabilmente va bene. Ma quel livello di transizione flash USB ha un proprio processore che deve mappare tutte le tue scritture per compensare quello che potrebbe essere un chip flash difettoso al 90%, chi lo sa? Lo allaghi, poi allaghi i tuoi buffer, quindi allaghi l'intero bus, poi sei bloccato, amico - dopo tutto, è lì che si trova tutta la tua roba. Può sembrare controintuitivo, ma ciò di cui hai davvero bisogno è bloccare l'I / O: devi lasciare che FTL stabilisca il ritmo e poi tenere il passo.

(Per hackerare i microcontrollori FTL: http://www.bunniestudios.com/blog/?p=3554 )

Tutte le risposte sopra dovrebbero funzionare, quindi questo è più un "anch'io!" di ogni altra cosa: ci sono stato totalmente, amico. Ho risolto i miei problemi con rsync's --bwlimit arg di (2,5 Mb sembrava essere il punto debole per una singola corsa senza errori - niente di più e finirei con errori di protezione da scrittura). rsync era particolarmente adatto al mio scopo perché stavo lavorando con interi filesystem - quindi c'erano molti file - e semplicemente eseguire rsync una seconda volta avrebbe risolto tutti i problemi della prima esecuzione (che era necessario quando sarei diventato impaziente e avrei provato superare 2,5 mbs).

Tuttavia, suppongo che non sia altrettanto pratico per un singolo file. Nel tuo caso potresti semplicemente pipe per dd impostato su raw-write - puoi gestire qualsiasi input in quel modo, ma solo un file di destinazione alla volta (anche se quel singolo file potrebbe essere un intero dispositivo a blocchi, ovviamente).

## OBTAIN OPTIMAL IO VALUE FOR TARGET HOST DEV ##
## IT'S IMPORTANT THAT YOUR "bs" VALUE IS A MULTIPLE ##
## OF YOUR TARGET DEV'S SECTOR SIZE (USUALLY 512b) ##
% bs=$(blockdev --getoptio /local/target/dev)

## START LISTENING; PIPE OUT ON INPUT ##
% nc -l -p $PORT | lz4 |\ 
## PIPE THROUGH DECOMPRESSOR TO DD ## 
>    dd bs=$bs of=/mnt/local/target.file \
## AND BE SURE DD'S FLAGS DECLARE RAW IO ##
>        conv=fsync oflag=direct,sync,nocache

## OUR RECEIVER'S WAITING; DIAL REMOTE TO BEGIN ##
% ssh user@remote.host <<-REMOTECMD
## JUST REVERSED; NO RAW IO FLAGS NEEDED HERE, THOUGH ## 
>    dd if=/remote/source.file bs=$bs |\
>    lz4 -9 | nc local.target.domain $PORT
> REMOTECMD  

Potresti trovare netcat un po 'più veloce di ssh per il trasporto dei dati se ci dai una possibilità. Ad ogni modo, le altre idee erano già state prese, quindi perché no?

[EDIT]: ho notato le menzioni di lftp, scp e ssh nell'altro post e ho pensato che stessimo parlando di una copia remota. Il locale è molto più semplice:

% bs=$(blockdev --getoptio /local/target/dev)
% dd if=/src/fi.le bs=$bs iflag=fullblock of=/tgt/fi.le \
>    conv=fsync oflag=direct,sync,nocache

[EDIT2]: Ringraziamenti dove è dovuto: ho appena notato che ptman mi ha battuto su questo per circa cinque ore nei commenti.

Sicuramente potresti mettere a punto $ bs per le prestazioni qui con un moltiplicatore, ma alcuni filesystem potrebbero richiedere che sia un multiplo della dimensione settoriale del fs di destinazione, quindi tienilo a mente.

Il problema è che la copia sta riempiendo la tua memoria di blocchi "in volo", che ammucchiano dati "utili". Un bug noto (e molto difficile da risolvere) nella gestione del kernel Linux dell'I / O per rallentare i dispositivi (USB in questo caso).

Forse puoi provare a distribuire la copia, ad esempio con uno script come il seguente (schizzo di prova, totalmente non testato!):

while true do
  dd if=infile of=outfile bs=4096 count=... seek=... skip=...
  sleep 5
done

aggiustando seeke skipad countogni giro. È necessario sintonizzarsi in countmodo che non riempia (troppa) memoria e 5consentirne il drenaggio.

Abbassa il limite di pagine sporche. Il limite predefinito è folle.

Crea /etc/sysctl.d/99-sysctl.conf con:

vm.dirty_background_ratio = 3
vm.dirty_ratio = 10

Quindi eseguire sysctl -p o riavviare.

Quello che sta succedendo è che i dati vengono letti più velocemente di quanto possano essere scritti sul disco di destinazione. Quando Linux copia i file, ciò che fa è leggerli nella RAM, quindi contrassegnare le pagine come sporche per la scrittura nella destinazione. Le pagine sporche non possono essere scambiate. Quindi, se il disco di origine è più veloce del disco di destinazione e stai copiando più dati di quanti ne hai RAM libera, l'operazione di copia consumerà tutta la RAM disponibile (o almeno qualunque sia il limite di pagina sporca, che potrebbe essere superiore al RAM disponibile) e causa la fame poiché le pagine sporche non possono essere scambiate e le pagine pulite vengono utilizzate e contrassegnate come sporche quando vengono liberate.

Nota che il suo non risolverà completamente il problema ... ciò di cui Linux ha davvero bisogno è un modo per arbitrare la creazione di pagine sporche, quindi un grande trasferimento in corso non consuma tutta la RAM disponibile / tutte le pagine sporche consentite.

Questo problema non ha nulla a che fare con errori o guasti nell'hardware o nel software, è solo il tuo kernel che cerca di essere gentile con te e restituire il tuo prompt e copiarlo in background (usa una cache nel kernel: più RAM, più cache, ma puoi limitarlo scrivendo da qualche parte in / proc - non consigliato però). Le unità flash sono troppo lente e mentre il kernel scrive su di esso, altre operazioni di I / O non possono essere eseguite abbastanza velocemente. ionicemenzionato più volte in altre risposte è ok. Ma hai provato a montare l'unità con -o syncper evitare il buffering del sistema operativo? È probabilmente la soluzione più semplice là fuori.