Rendre le disque / la copie de disque plus lent

Existe-t-il une méthode pour ralentir le processus de copie sous Linux?

J'ai un gros fichier, disons 10 Go, et j'aimerais le copier dans un autre répertoire, mais je ne veux pas le copier à pleine vitesse. Disons que j'aimerais le copier à la vitesse de 1 Mo / s, pas plus vite. Je voudrais utiliser une cpcommande Linux standard .

Est-ce possible? (Si oui, comment?)

Edit : donc, je vais ajouter plus de contexte à ce que j'essaie de réaliser.

J'ai un problème sur le système ArchLinux lors de la copie de gros fichiers via USB (sur une clé USB, un disque USB, etc.). Après avoir rempli le cache du tampon USB, mon système cesse de répondre (même la souris s'arrête; elle ne se déplace que sporadiquement). L'opération de copie est toujours en cours, mais elle prend 100% des ressources de la boîte. Lorsque l'opération de copie est terminée, tout revient à la normale - tout est à nouveau parfaitement réactif.

C'est peut-être une erreur matérielle, je ne sais pas, mais je sais que j'ai deux machines avec ce problème (les deux sont sur ArchLinux, l'une est une boîte de bureau, la seconde est un ordinateur portable).

La "solution" la plus simple et la plus rapide à cela (je conviens que ce n'est pas la "vraie" solution, juste un "hack" moche) serait d'empêcher ce tampon de se remplir en copiant le fichier avec une vitesse d'écriture moyenne du lecteur USB, par exemple. moi ce serait suffisant.

Vous pouvez étrangler un tuyau avec pv -qL(ou cstream -toffre des fonctionnalités similaires)

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

-q supprime les rapports de progression de stderr.

La -Llimite est en octets.

En savoir plus sur le --rate-limit/-Ldrapeau de la 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.

Cette réponse a été indiquée à l'origine, throttlemais ce projet n'est plus disponible et a donc été supprimé de certains systèmes de packages.

Au lieu de cela, cp -a /foo /barvous pouvez également utiliser rsyncet limiter la bande passante selon vos besoins.

D'après le rsyncmanuel de:

--bwlimit=KBPS

limiter la bande passante d'E / S; Koctets par seconde

Ainsi, la commande actuall, montrant également la progression, ressemblerait à ceci:

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

Je suppose que vous essayez de ne pas perturber d'autres activités. Les versions récentes de Linux incluent ionicece qui vous permet de contrôler la planification des E / S.

En plus d'autoriser diverses priorités, il existe une option supplémentaire pour limiter les E / S aux moments où le disque est autrement inactif. La commande man ioniceaffichera la documentation.

Essayez de copier le fichier à l'aide d'une commande comme:

ionice -c 3 cp largefile /new/directory

Si les deux répertoires sont sur le même appareil, vous pouvez trouver que la liaison du fichier fait ce que vous voulez. Si vous copiez à des fins de sauvegarde, n'utilisez pas cette option. lnest extrêmement rapide car le fichier lui-même n'est pas copié. Essayer:

ln largefile /new/directory

Ou si vous souhaitez simplement y accéder à partir d'un répertoire sur un autre appareil, essayez:

ln -s largefile /new/directory

Si la ionicesolution ne suffit pas (quoi qu'il en soit) et que vous souhaitez vraiment limiter les E / S à une valeur absolue, il existe plusieurs possibilités:

1. le moyen le plus probablement: ssh. Il a une limite de bande passante intégrée. Vous utiliseriez par exemple tar(au lieu de cp) ou scp(si cela suffit, je ne sais pas comment il gère les liens symboliques et les liens durs) ou rsync. Ces commandes peuvent diriger leurs données ssh. Dans le cas où tarvous écrivez /dev/stdout(ou -) et canalisez cela dans le sshclient qui en exécute un autre tardu côté "distant".

2. élégant mais pas dans le noyau vanilla (AFAIK): la cible du mappeur de périphériques ioband. Bien sûr, cela ne fonctionne que si vous pouvez démonter le volume source ou le volume cible.

3. un plaisir auto-écrit: grep "^write_bytes: " /proc/$PID/iovous donne la quantité de données qu'un processus a écrites. Vous pouvez écrire un script qui démarre cpen arrière-plan, dort par exemple 1 / 10e de seconde, arrête le cpprocessus d' arrière-plan ( kill -STOP $PID), vérifie le montant qui a été écrit (et lu? Environ la même valeur dans ce cas), calcule la durée cpdoit faire une pause afin de ramener le taux de transfert moyen à la valeur souhaitée, s'endort pendant ce temps, se réveille cp( kill -CONT $PID), etc.

Votre problème n'est probablement pas avec votre ordinateur, en soi, c'est probablement bien. Mais cette couche de transition flash USB possède son propre processeur qui doit cartographier toutes vos écritures pour compenser ce qui pourrait être autant qu'une puce flash défectueuse à 90%, qui sait? Vous l'inondez puis vous inonder vos tampons, puis vous inonder tout le bus, puis vous êtes coincé, l'homme - après tout, c'est là que se trouvent toutes vos affaires. Cela peut sembler contre-intuitif, mais ce dont vous avez vraiment besoin est de bloquer les E / S - vous devez laisser le FTL donner le rythme, puis suivre le rythme.

(Sur le piratage des microcontrôleurs FTL: http://www.bunniestudios.com/blog/?p=3554 )

Toutes les réponses ci-dessus devraient fonctionner, donc c'est plus un "moi aussi!" qu'autre chose: j'y suis totalement allé, mec. J'ai résolu mes propres problèmes avec l' argument --bwlimit de rsync (2,5 Mo semblaient être le point idéal pour une seule exécution sans erreur - rien de plus et je me retrouverais avec des erreurs de protection en écriture). rsync était particulièrement adapté à mon objectif car je travaillais avec des systèmes de fichiers entiers - donc il y avait beaucoup de fichiers - et simplement exécuter rsync une deuxième fois résoudrait tous les problèmes de la première exécution (ce qui était nécessaire lorsque je devenais impatient et essayais rampe au-delà de 2,5 Mo).

Pourtant, je suppose que ce n'est pas aussi pratique pour un seul fichier. Dans votre cas, vous pouvez simplement rediriger vers dd défini sur raw-write - vous pouvez gérer n'importe quelle entrée de cette façon, mais un seul fichier cible à la fois (bien que ce fichier unique puisse être un périphérique de bloc entier, bien sûr).

## 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  

Vous pouvez trouver que netcat est un peu plus rapide que ssh pour le transport de données si vous lui donnez une chance. Quoi qu'il en soit, les autres idées ont déjà été prises, alors pourquoi pas?

[EDIT]: J'ai remarqué les mentions de lftp, scp et ssh dans l'autre post et j'ai pensé que nous parlions d'une copie à distance. Les locaux sont beaucoup plus faciles:

% 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]: Le crédit est dû: je viens de remarquer que ptman m'a battu pendant environ cinq heures dans les commentaires.

Vous pouvez certainement régler $ bs pour les performances ici avec un multiplicateur - mais certains systèmes de fichiers peuvent exiger qu'il soit un multiple de la taille de secteur du fs cible, alors gardez cela à l'esprit.

Le problème est que la copie remplit votre mémoire de blocs "en vol", évincant les données "utiles". Un bogue connu (et très difficile à corriger) dans la gestion par le noyau Linux des E / S vers les périphériques lents (USB dans ce cas).

Vous pouvez peut-être essayer de répartir la copie, par exemple par un script comme celui-ci (croquis de validation de principe , totalement non testé!):

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

réglage seeket skippar countchaque tour. Besoin de régler countpour qu'il ne remplisse pas (trop) de mémoire et 5pour lui permettre de s'écouler.

Abaissez la limite de pages sales. La limite par défaut est folle.

Créez /etc/sysctl.d/99-sysctl.conf avec:

vm.dirty_background_ratio = 3
vm.dirty_ratio = 10

Exécutez ensuite sysctl -p ou redémarrez.

Ce qui se passe, c'est que les données sont lues plus rapidement qu'elles ne peuvent être écrites sur le disque de destination. Lorsque Linux copie des fichiers, il les lit dans la RAM, puis marque les pages comme sales pour l'écriture vers la destination. Les pages sales ne peuvent pas être échangées. Donc, si le disque source est plus rapide que le disque de destination et que vous copiez plus de données que vous n'avez de RAM libre, l'opération de copie consommera toute la RAM disponible (ou au moins quelle que soit la limite de pages sales, qui pourrait être supérieure à la RAM disponible) et provoquer la famine car les pages sales ne peuvent pas être échangées et les pages propres sont utilisées et marquées comme sales lorsqu'elles sont libérées.

Notez que cela ne résoudra pas complètement le problème ... ce dont Linux a vraiment besoin, c'est d'un moyen d'arbitrer la création de pages sales afin qu'un gros transfert en cours ne consomme pas toute la RAM disponible / toutes les pages sales autorisées.

Ce problème n'a rien à voir avec des erreurs ou des défauts de matériel ou de logiciel, c'est juste que votre noyau essaie d'être gentil avec vous et de renvoyer votre invite et de la copier en arrière-plan (il utilise un cache dans le noyau: plus de RAM, plus de cache, mais vous pouvez le limiter en écrivant quelque part dans / proc - pas recommandé cependant). Les lecteurs flash sont trop lents et pendant que le noyau écrit dessus, d'autres opérations d'E / S ne peuvent pas être effectuées assez rapidement. ionicementionné plusieurs fois dans d'autres réponses est ok. Mais avez-vous essayé de simplement monter le lecteur avec -o syncpour éviter la mise en mémoire tampon du système d'exploitation? C'est probablement la solution la plus simple qui existe.