Bonjour,
Par manque d'inode sur un FS je vais devoir archiver beaucoup de dossiers sur un autre FS.
J'aimerai savoir si il y a un commande que je peux intégrer dans ma boucle pour purger le cache après à chaque tour de boucle car la RAM sature après la copie d'environ 300 dossiers et fait planter l'opération en cours de route?
Voici à quoi ressemble ma boucle
for dir in $dirsrc/* ; do
if [ -d $dir]; then
ionice -c 2 tar -cvf - $dir | throttle -M 10 | gzip > $dirdst/$dir.tar.gz
if [ $? -eq 0]; then
ionice -c 2 rm -rf $dir
fi
fi
Merci beaucoup
# sync ?
Posté par gUI (Mastodon) . Évalué à 2. Dernière modification le 26 août 2016 à 14:47.
pas certain que ce soit ce que tu cherches, mais "sync" est bloquant, et attend jusqu'à ce que toutes les écritures soit faites.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: sync ?
Posté par Orwell . Évalué à 0.
Bonjour gUI,
Et comment puis-je utiliser sync ou autrement dit suis-je sur qu'après le tar | gzip le fichier est bien écrit?
Car j'ai lu sur sync qu'il fallait être sur que les données soient ecrites sur disk avant d'utiliser sync.
Donc si je fais ça
tar -zcvf $dir | throttle -M 10 | gzip > $dirdst/$dir.tar.gz && sync
est-ce bon ?
Merci, je sais que ce que je dis n'est pas très clair mais c'est un peu le bordel dans ma tête.
[^] # Re: sync ?
Posté par fearan . Évalué à 2. Dernière modification le 26 août 2016 à 15:43.
attention tu mixes 2 commandes :)
tar cvf machine > destination
et
tar zcvf destination machin
donc déjà ça ne va pas marcher (il manque la destination à la première commande; et ensuite tu gzip 2 fois (z) ;)
et je ne vois toujours pas l'intérêt de throttle mais je n'ai pas toutes les infos ;)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: sync ?
Posté par Orwell . Évalué à 1. Dernière modification le 26 août 2016 à 16:04.
Oui pardon c'est un copier/coller hasardeux mais c'est un tar cvf | gzip >
et pour le tar y a le (-) juste après le cvf qui permet d'parès ce que j'ai lu de ne pas créer de fichier intermédiaire (.tar)
http://www.krazyworks.com/create-tar-and-pipe-through-gzip/
[^] # Re: sync ?
Posté par gUI (Mastodon) . Évalué à 3.
Bin non justement, sync sert à forcer l'écriture.
Exemple.
Tu as un clé USB lente. Tu copies dessus 1GB. Ca met 10 secondes. Tu te dis "pas possible en 10 secondes, tout n'est pas écrit". Et en effet, tu vois ta clé clignoter. Mais la commande 'cp' est finie, tu es de nouveau au prompt.
Tu peux taper 'sync'. Et là la commande va mettre plusieurs minutes à te rendre la main. Parce que elle attend que les données soient réellement écrites (celles de la clé USB, et au passage toutes les autres de l'ordi, quel que soit le périphérique).
D'ailleurs une fois que la commande sync est finie, tu peux arracher la clé USB sans umounter. C'est pas spécialement conseillé (ni très intelligent) mais ça marchera : tu es certain que toutes les données de la clé sont écrites, ta clé est "propre".
Autre exemple : quand le kernel s'éteint, il lance rapidement un "sync" lui-même afin de forcer tous les caches à se vider et de pouvoir éteindre proprement la machine.
Oui, je pense à ça en effet. Dans ta commande principale, tu ajoutes un 'sync' à la fin.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: sync ?
Posté par Orwell . Évalué à 1.
Ok Merci gUI.
Parfait.
# limit inode
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Jamais eu le cas malgré des gros volumes pleins d'images ou de courriels IMAP… Mes volumes sont tous en XFS.
[^] # Re: limit inode
Posté par Orwell . Évalué à 1.
Là les volumes sont en EXT3 et il y a plein de petits fichiers jpeg et texte (+ de 60 millions)
# curieux
Posté par fearan . Évalué à 2.
j'ai un doute sur l'utilité di throttle, tant que tu ne joues pas sur le réseau, ça ne devrait pas trop poser de problèmes, j'ajouterai que ta commande joue avec 3 pipe | throttle | (je considère throttle comme un pipe), là ou un tar zcvf $dirdst/$dir.tar.gz $dir suffirait (mais on a pas le throttle; mais là encore si c'est pour la capacité de destination, il n'est pas au bon endroit
tar zcvf $dir | throttle -M 10 > $dirdst/$dir.tar.gz
Et si c'est tar qui n'a pas l'option z, tar cvf $dir | gzip | throttle -M10
enfin j'aurais tendance à préférer l'usage de la commande tout en un (tar zcvf ) pour la simple et bonne raison que
true | true | false
va donner un $? à faux
alors que
false | true | true
va donner un $? à vrai, or le tar aura foiré (incomplet).
Quant au cache, je ne vois pas trop duquel tu parles, si c'est celui qui est affiché par la commande free, c'est normal qu'il soit plein, et ça ne fait pas planter la machine.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: curieux
Posté par Orwell . Évalué à 1.
En fait, la destination est un volume nfs , c'est pourquoi j'ai mis throttle -M10.
Maintenant c'est vrai que de faire un test à l'issue de ma commande c'est pas super intelligent de ma part étant donné que c'est une succession de 3 commande et que je pense en effet qu'il va évaluer uniquement le retour de la dernière commande.
maintenant je sais pas trop comment faire pour tester ET que le fichier est bien présent à la destination ( if [ -e $dirdst/$dir.tar.gz ] ) Et que l'archive est bien complète?
Pour le cache en fait c'est pas vraiment le cache mais la consommation RAM elle même qui augmente au bout de 2 ou 3 heures.
Sachant qua ça fait 3 jours que j'essaye de faire la copie mais que ça plante chaque fois à un endroit différent.
[^] # Re: curieux
Posté par fearan . Évalué à 2. Dernière modification le 26 août 2016 à 16:17.
dans ce cas il faut le mettre au dernier moment avec le minimum de |
typiquement tar zcvf - $dir | throttle -M10 > $destdir/dir.tar.gz
histoire de compresser dès le début et avoir le throttle sur le flux réel et pas avant compression; mais là encore on a aucune garantie que le tar s'est bien déroulé
si tu peux écrire le fichier en local (quitte à monter un volume en loop ou sur un disque temporaire), tu peux créer le fichier en local puis le déplacer sur le volume distant, de préférence avec rsync sans passer par le nfs
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: curieux
Posté par benja . Évalué à 2. Dernière modification le 26 août 2016 à 23:47.
Je conseillerais aussi rsync pour cela. De même, j'appuye le fait que le cache ne peut pas causer une pénurie de mémoire, donc vouloir le vider est une mauvaise idée (sinon c'est echo 3 > /proc/sys/vm/drop_caches…). Peut-être qu'ajouter de la swap pourrait résoudre ton problème ?
Concernant throttle, son utilisation est largement douteuse. Cela n'est pas parcequ'un process écrit à une certaine vitesse que le noyau va être plus ou moins chargé, va cacher plus ou moins, etc… Il faut garder en mémoire que pour ne pas exhiber des performances désastreuses, un FS combine les écritures de plusieurs activités en même temps.
Pour tester les conditions dans un pipe, apparemment bash possède l'option pipefail (set -o pipefail) qui fait l'affaire. Sinon, tu pourrais passer par un named-pipe, et tu lances tar en dernier. Genre mkfifo /tmp/fifo; gzip > out.gz < /tmp/fifo; tar cf - > /tmp/fifo.
De manière plus générale, je te conseillerais de rechercher la cause de l'erreur que tu rencontres, éventuellement en postant ici, au lieu de jouer à l'apprenti-sorcier. Car en prenant l'habitude d'essayer un truc au pif au lieu d'essayer de comprendre ce qui ne va pas, tu ne parviendras jamais à produire un système fiable.
edit: je m'adresse bien sûr à la deuxième personne à l'auteur de ce sujet.
[^] # Re: curieux
Posté par benja . Évalué à 1.
Pour l'astuce du fifo afin de tester le retour de toutes les commandes, on peut faire:
Sh étant ce qu'il est, il n'y a pas vraiment d'autre moyen que de passer par un fichier pour stocker les codes retours…
[^] # Re: curieux
Posté par benja . Évalué à 1. Dernière modification le 27 août 2016 à 00:08.
Il manque un '&' dans l'appel à gzip, sinon il ne va pas se passer grand chose :p
mkfifo /tmp/fifo
gzip > out.gz < /tmp/fifo &
tar cf - > /tmp/fifo
# d'autres pistes
Posté par NeoX . Évalué à 2.
tu peux essayer aussi
qui ne compresse pas par clone le dossier $dirlocal dans le /dossier/destination de la machine distante.
mais evidemment si tu as ssh entre les machines, un bon rsync devrait faire le boulot.
rsync -aP $dir machinedistante:/dossier/destinationSuivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.