tło
I zabrakło miejsca na /home/datai trzeba przenieść /home/data/repodo /home/data2.
/home/data/repozawiera 1M katalogów, z których każdy zawiera 11 katalogów i 10 plików. Łącznie wynosi 2 TB.
/home/datajest na ext3 z włączonym dir_index.
/home/data2jest na ext4. Uruchamianie CentOS 6.4.
Zakładam, że te podejścia są powolne, ponieważ repo/bezpośrednio pod nimi znajduje się 1 milion reż.
Próba 1: mvjest szybka, ale zostaje przerwana
Mógłbym to zrobić, gdyby to się skończyło:
/home/data> mv repo ../data2
Ale zostało przerwane po przeniesieniu 1,5 TB. Pisał z prędkością około 1 GB / min.
Próba 2: rsyncindeksuje się po 8 godzinach budowania listy plików
/home/data> rsync --ignore-existing -rv repo ../data2
Utworzenie „przyrostowej listy plików” zajęło kilka godzin, a następnie przesyłano z prędkością 100 MB / min.
Anuluję to, aby spróbować szybszego podejścia.
Próba 3a: mvnarzeka
Testowanie w podkatalogu:
/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
Nie jestem pewien, o co chodzi z tym błędem, ale może cpmnie uratuje ...
Próba 3b: cpnigdzie nie dotrze po 8 godzinach
/home/data> cp -nr repo ../data2
Czyta dysk przez 8 godzin i postanawiam go anulować i wrócić do rsync.
Próba 4: rsyncindeksuje się po 8 godzinach budowania listy plików
/home/data> rsync --ignore-existing --remove-source-files -rv repo ../data2
Myślałem, --remove-source-filesże może to przyspieszyć, jeśli zacznę teraz czyszczenie.
Tworzenie listy plików zajmuje co najmniej 6 godzin, a następnie przesyła z prędkością 100-200 MB / min.
Ale serwer był z dnia na dzień obciążony i moje połączenie zostało zamknięte.
Próba 5: POSTĘPUJE TYLKO 300 GB, DLACZEGO JEST TO TAK Bolesne
/home/data> rsync --ignore-existing --remove-source-files -rvW repo ../data2
Znów przerwane. -WPrawie wydawało się „wysyłanie przyrostową listę plików” szybciej, co w moim rozumieniu nie powinno mieć sens. Niezależnie od tego transfer jest strasznie powolny i rezygnuję z tego.
Próba 6: tar
/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)
Zasadniczo próba skopiowania wszystkiego, ale ignorowanie istniejących plików. Musi przebrnąć przez 1,7 TB istniejących plików, ale przynajmniej odczytuje z prędkością 1,2 GB / min.
Jak dotąd jest to jedyne polecenie, które daje natychmiastową satysfakcję.
Aktualizacja: jakoś przerwana, nawet bez nohup ..
Próba 7: harakiri
Nadal debatuję nad tym
Próba 8: skryptowe „scalenie” z mv
Docelowy katalog miał około 120 tysięcy pustych katalogów, więc pobiegłem
/home/data2/repo> find . -type d -empty -exec rmdir {} \;
Skrypt 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
GOTOWY.
mvraz? Teoretycznie mvusunie plik źródłowy tylko wtedy, gdy plik docelowy został całkowicie skopiowany, więc powinien działać poprawnie. Ponadto, czy masz fizyczny dostęp do maszyny, czy jest to wykonywane przez sshpołączenie?
mvnie wybacza, jeśli będziesz się rozłączać, możesz stracić dane, a nawet ich nie znać. Jak powiedziałeś, że robisz to po raz kolejny ssh, zdecydowanie polecam używanie screeni odłączanie. Włącz rejestrowanie i śledź w ten sposób. Jeśli używasz pełnego tekstu, potrwa to dłużej. Spróbuj takżeiotop
screen. Zastanawiałem się nad gadatliwością, ale wydaje mi się, że jest już za późno na ponowne uruchomienie tar. I iotopbył moim ulubionym narzędziem od kilku ostatnich dni :)