Contexte
Je suis sorti de l' espace sur /home/dataet nécessité de transférer /home/data/repoà /home/data2.
/home/data/repocontient 1 million de répertoires, chacun contenant 11 répertoires et 10 fichiers. Il totalise 2 To.
/home/dataest sur ext3 avec dir_index activé.
/home/data2est sur ext4. Exécution de CentOS 6.4.
Je suppose que ces approches sont lentes en raison du fait qu'il y repo/a 1 million de dirhams directement en dessous.
Tentative 1: mvrapide mais interrompue
Je pourrais faire si cela avait fini:
/home/data> mv repo ../data2
Mais il a été interrompu après le transfert de 1,5 To. Il écrivait à environ 1 Go / min.
Tentative 2: rsyncanalyse après 8 heures de création de la liste des fichiers
/home/data> rsync --ignore-existing -rv repo ../data2
Il a fallu plusieurs heures pour créer la «liste de fichiers incrémentielle», puis elle transfère à 100 Mo / min.
Je l'annule pour essayer une approche plus rapide.
Tentative 3a: se mvplaint
Le tester sur un sous-répertoire:
/home/data/repo> mv -f foobar ../../data2/repo/
mv: inter-device move failed: '(foobar)' to '../../data2/repo/foobar'; unable to remove target: Is a directory
Je ne sais pas de quoi il s'agit, mais cpje peux peut- être me renflouer.
Tentative 3b: cpn'aboutit à rien après 8 heures
/home/data> cp -nr repo ../data2
Il lit le disque pendant 8 heures et je décide de l'annuler et de revenir à rsync.
Tentative 4: rsyncanalyse après 8 heures de création de la liste des fichiers
/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2
J'avais l'habitude de --remove-source-filespenser que cela pourrait être plus rapide si je commence le nettoyage maintenant.
Il faut au moins 6 heures pour créer la liste des fichiers, puis il transfère à 100-200 Mo / min.
Mais le serveur a été surchargé du jour au lendemain et ma connexion a été fermée.
Tentative 5: IL N'Y A PLUS QUE 300 Go À DÉPLACER POURQUOI EST-CE SI DOULEUR
/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2
A nouveau interrompu. Le -Wsemblait presque faire « envoyer la liste des fichiers supplémentaires » plus rapide, ce qui à mon sens ne devrait pas donner un sens. Quoi qu'il en soit, le transfert est horriblement lent et j'abandonne celui-ci.
Tentative 6: tar
/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)
Essayant essentiellement de tout recopier mais en ignorant les fichiers existants. Il doit parcourir 1,7 To de fichiers existants, mais au moins, il lit à 1,2 Go / min.
Jusqu'à présent, c'est la seule commande qui donne une gratification instantanée.
Mise à jour: interrompu à nouveau, en quelque sorte, même avec nohup ..
Tentative 7: harakiri
Débat toujours sur celui-ci
Tentative 8: script de «fusion» avec mv
Le répertoire de destination contenait environ 120 000 répertoires vides, j'ai donc couru
/home/data2/repo> find . -type d -empty -exec rmdir {} \;
Script Ruby:
SRC = "/home/data/repo"
DEST = "/home/data2/repo"
`ls #{SRC} --color=never > lst1.tmp`
`ls #{DEST} --color=never > lst2.tmp`
`diff lst1.tmp lst2.tmp | grep '<' > /home/data/missing.tmp`
t = `cat /home/data/missing.tmp | wc -l`.to_i
puts "Todo: #{t}"
# Manually `mv` each missing directory
File.open('missing.tmp').each do |line|
dir = line.strip.gsub('< ', '')
puts `mv #{SRC}/#{dir} #{DEST}/`
end
TERMINÉ.
mvpas? En théorie, mvle fichier source ne sera supprimé que si le fichier de destination a été entièrement copié, il devrait donc fonctionner correctement. De plus, avez-vous un accès physique à la machine ou cela se fait-il via une sshconnexion?
mvne pardonne pas, si vous continuez à être déconnecté, vous pourriez perdre des données et même ne pas le savoir. Comme vous l'avez dit, vous sshrecommencez, je recommande fortement d'utiliser screenet de détacher. Activez la journalisation et gardez une trace de cette façon. Si vous utilisez verbeux, cela prendra juste plus de temps. Essayez égalementiotop
screen. Je me posais des questions sur verbeux mais je suppose qu'il est trop tard pour redémarrer tarmaintenant. Et iotopa été mon utilitaire préféré ces derniers jours :)