Verschieben von 2 TB (10 Mio. Dateien + Verzeichnis), was ist mein Engpass?

4468
Tim

Hintergrund

Ich lief aus dem Raum auf /home/dataund müssen zur Übertragung /home/data/repoan /home/data2.

/home/data/repoenthält 1M-Verzeichnisse, die jeweils 11 Verzeichnisse und 10 Dateien enthalten. Es beläuft sich auf 2 TB.

/home/dataist auf ext3 mit aktiviertem dir_index. /home/data2ist auf ext4. CentOS ausführen 6.4.

Ich repo/gehe davon aus, dass diese Ansätze langsam sind, da sich direkt darunter 1 Million Dirs befinden.


Versuch 1: mvist schnell, wird aber unterbrochen

Ich könnte getan werden, wenn das beendet wäre:

/home/data> mv repo ../data2 

Es wurde jedoch unterbrochen, nachdem 1,5 TB übertragen worden waren. Es wurde mit etwa 1 GB / min geschrieben.

Versuch 2: rsynccrawlt nach 8 Stunden Erstellung der Dateiliste

/home/data> rsync --ignore-existing -rv repo ../data2 

Es dauerte mehrere Stunden, um die Liste der inkrementellen Dateien zu erstellen. Anschließend wurde die Übertragung mit 100 MB / min durchgeführt.

Ich storniere es, um einen schnelleren Ansatz zu versuchen.

Versuch 3a: mvbeschwert sich

Testen Sie es in einem Unterverzeichnis:

/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 

Ich bin mir nicht sicher, worum es sich bei diesem Fehler handelt, aber vielleicht cpkann ich mich rauswerfen.

Versuch 3b: cpkommt nach 8 Stunden nirgendwo hin

/home/data> cp -nr repo ../data2 

Es liest die Platte für 8 Stunden und ich beschließe, sie abzubrechen und zu rsync zurückzukehren.

Versuch 4: rsynccrawlt nach 8 Stunden Erstellung der Dateiliste

/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2 

Ich --remove-source-filesdachte, es könnte schneller gehen, wenn ich jetzt mit dem Aufräumen beginne.

Es dauert mindestens 6 Stunden, um die Dateiliste zu erstellen, die dann mit 100-200 MB / min übertragen wird.

Der Server wurde jedoch über Nacht belastet und meine Verbindung wurde geschlossen.

Versuch 5: Es sind nur 300 GB übrig, um zu bewegen, warum dies so schmerzlos ist

/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2 

Wieder unterbrochen. Das -Wschien das "Senden der inkrementellen Dateiliste" fast zu beschleunigen, was meines Erachtens nicht sinnvoll sein sollte. Trotzdem ist der Transfer furchtbar langsam und ich gebe das auf.

Versuch 6: tar

/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -) 

Grundsätzlich versuchen Sie, alles neu zu kopieren, aber vorhandene Dateien zu ignorieren. Es muss durch 1,7 TB der vorhandenen Dateien laufen, aber das Lesen von mindestens 1,2 GB / Min.

Dies ist bisher der einzige Befehl, der sofortige Befriedigung gibt.

Update: wieder unterbrochen, irgendwie auch mit nohup ..

Versuch 7: Harakiri

Über dieses noch debattieren

Versuch 8: Skript "zusammenführen" mit mv

Das Zielverzeichnis hatte etwa 120.000 leere Verzeichnisse, also bin ich gerannt

/home/data2/repo> find . -type d -empty -exec rmdir {} \; 

Ruby-Skript:

SRC = "/home/data/repo" DEST = "/home/data2/repo"  `ls # --color=never > lst1.tmp` `ls # --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: #"  # Manually `mv` each missing directory File.open('missing.tmp').each do |line| dir = line.strip.gsub('< ', '') puts `mv #/# #/` end 

ERLEDIGT.

20
Sie haben Recht, es muss jedes Verzeichnis finden und auflisten, und 1 Million Verzeichnisse werden schmerzhaft sein. cybernard vor 10 Jahren 0
Schauen Sie sich die helle Seite an ... Wenn es Windows wäre, könnten Sie nicht einmal eine Million Unterverzeichnisse haben und trotzdem ein Betriebssystem haben, das funktioniert. :) Jack vor 10 Jahren 2
@ Jack wirklich? Hat Windows ein Limit? Ist dies nicht ein Relikt aus den FAT32-Tagen (ich habe Windows seit ~ 2001 nicht mehr als Hauptbetriebssystem verwendet und bin daher nicht wirklich auf dem neuesten Stand)? terdon vor 10 Jahren 0
@ Tim, warum machst du nicht einfach 'mv' nochmal? Theoretisch wird "mv" eine Quelldatei nur dann löschen, wenn die Zieldatei vollständig kopiert wurde, so dass sie ordnungsgemäß funktioniert. Haben Sie auch physischen Zugriff auf die Maschine oder erfolgt dies über eine `ssh'-Verbindung? terdon vor 10 Jahren 1
@ terdon - Windows hat an sich kein Limit ... aber es hat einen Punkt, an dem es für alle Absichten und Zwecke unbrauchbar wird. Der Windows Explorer benötigt für die Anzeige der Dateiliste usw. ewig. Jack vor 10 Jahren 0
@Jack OK, aber das wirkt sich nur auf das eine Verzeichnis aus, oder? Oder wird das gesamte System betroffen sein? terdon vor 10 Jahren 0
@terdon - Nur das eine Verzeichnis. Siehe http://technet.microsoft.com/de-de/magazine/hh395477.aspx Jack vor 10 Jahren 0
@terdon - Wollte "mv -f" verwenden, testete es jedoch in einem Unterverzeichnis und erhielt "mv: inter-device move failed:" (foobar) "in" ../../data2/repo/foobar "; Ziel kann nicht entfernt werden: Ist ein Verzeichnis`. Und ja, ich verwende 'ssh'. Tim vor 10 Jahren 0
Bei so vielen Dateien / Verzeichnissen wären Sie mit `dd` wirklich besser dran (obwohl für 2 TB die Fertigstellung Stunden / Tage dauern würde). justbrowsing vor 10 Jahren 0
@justbrowsing - das Problem ist jetzt, dass ich zusammenführen / wieder aufnehmen muss. Kann "dd" das tun? Wenn einige der Quelldateien nicht bereits gelöscht wurden, würde ich einfach das Zielverzeichnis und "mv" die Quelle erneut löschen. Es hätte nur 24 Stunden gedauert, wenn es nicht unterbrochen worden wäre. Tim vor 10 Jahren 0
Nein, das geht nicht. "mv" ist nicht verzeihend. Wenn Sie die Verbindung ständig trennen, können Sie Daten verlieren und es nicht einmal wissen. Wie Sie gesagt haben, dass Sie dies über `ssh` tun, empfehle ich dringend,` screen 'zu verwenden und zu trennen. Aktivieren Sie die Protokollierung und verfolgen Sie diesen Weg. Wenn Sie verbose verwenden, dauert es einfach länger. Versuchen Sie auch "iotop" justbrowsing vor 10 Jahren 5
@justbrowsing - Guter Anruf auf "Bildschirm". Ich habe mich über Verbose gewundert, aber ich denke, es ist zu spät, um `tar 'jetzt neu zu starten. Und "iotop" war in den letzten Tagen mein Lieblingsprogramm :) Tim vor 10 Jahren 2
ist eines Ihrer Verzeichnisse von einem Server gemountet? dann würde ich empfehlen, eine direkte Verbindung mit `rsync dir1 server: dir2` oder` rsync server: dir1 dir2` zu verwenden, abhängig von dem Server, der weniger wahrscheinlich getrennt wird. Durch Verschachteln dieses Befehls in einer `screen`-Shell können einige Verbindungsabbrüche vermieden werden. meduz vor 10 Jahren 0

3 Antworten auf die Frage

5
Ярослав Рахматуллин

Haben Sie schon einmal davon gehört, große Aufgaben in kleinere Aufgaben aufzuteilen?

/ home / data / repo enthält 1M-Verzeichnisse, die jeweils 11 Verzeichnisse und 10 Dateien enthalten. Es beläuft sich auf 2 TB.

rsync -a /source/1/ /destination/1/ rsync -a /source/2/ /destination/2/ rsync -a /source/3/ /destination/3/ rsync -a /source/4/ /destination/4/ rsync -a /source/5/ /destination/5/ rsync -a /source/6/ /destination/6/ rsync -a /source/7/ /destination/7/ rsync -a /source/8/ /destination/8/ rsync -a /source/9/ /destination/9/ rsync -a /source/10/ /destination/10/ rsync -a /source/11/ /destination/11/  (...) 

Kaffeepause.

Der Vorteil, den ich vage betonen möchte, ist, dass Sie * den Fortschritt in kleinen Teilen manuell verfolgen *, so dass die Wiederaufnahme der Aufgabe weniger Zeit in Anspruch nimmt, wenn ein Teil abgebrochen wird (weil Sie wissen, welche Schritte erfolgreich abgeschlossen wurden). Ярослав Рахматуллин vor 10 Jahren 1
Dies ist im Grunde das, was ich am Ende gemacht habe, außer mit "mv". Unglücklicherweise gibt es kein Werkzeug, das "mv" und "rsync" auf halbem Weg trifft. Tim vor 10 Jahren 0
4
maki

Folgendes passiert:

  • Anfangs erstellt rsync die Liste der Dateien.
  • Das Erstellen dieser Liste ist aufgrund einer anfänglichen Sortierung der Dateiliste sehr langsam.
  • Dies kann vermieden werden, indem Sie ls -f -1 verwenden und mit xargs kombinieren, um die von rsync verwendeten Dateien zu erstellen, oder indem Sie die Ausgabe in eine Datei mit der Dateiliste umleiten.
  • Wenn Sie diese Liste an rsync statt an den Ordner übergeben, wird rsync sofort gestartet.
  • Dieser Trick von ls -f -1 über Ordner mit Millionen von Dateien wird in diesem Artikel perfekt beschrieben: http://unixetc.co.uk/2012/05/20/large-directory-causes-ls-to-hang/
Können Sie ein Beispiel für die Verwendung von ls mit rsync geben? Ich habe eine ähnliche, aber nicht identische Situation. Auf Rechner-AI muss rsyncd ausgeführt werden und ein großer Verzeichnisbaum soll auf Rechner B übertragen werden (tatsächlich sind 90% des Verzeichnisses bereits auf B). Das Problem ist, dass ich dies mit einer instabilen mobilen Verbindung tun muss, die häufig abbricht. Es ist ziemlich ineffizient, immer eine Stunde damit zu verbringen, die Dateiliste zu erstellen. Auch B steht hinter NAT, das ich nicht kontrolliere. Daher ist es schwierig, A -> B zu verbinden, während B -> A einfach ist. d-b vor 9 Jahren 0
1
Angelo

Selbst wenn rsync langsam ist (warum ist es langsam? Vielleicht hilft -z wird helfen), klingt es so, als hätten Sie eine Menge davon verschoben, also könnten Sie es einfach weiter versuchen:

Wenn Sie --remove-source-files verwendet haben, können Sie anschließend leere Verzeichnisse entfernen. --remove-source-files entfernt alle Dateien, lässt jedoch die Verzeichnisse dort.

Stellen Sie nur sicher, dass Sie NICHT --remove-source-files mit --delete verwenden, um mehrere Durchgänge durchzuführen.

Für erhöhte Geschwindigkeit können Sie --inplace verwenden

Wenn Sie rausgeschmissen werden, weil Sie versuchen, dies remote auf einem Server auszuführen, führen Sie dies in einer Bildschirmsitzung aus. Zumindest so kann man es laufen lassen.