Создание «инкрементного списка файлов» заняло несколько часов, а затем скорость передачи составляет 100 МБ / мин.
Я отменяю это, чтобы попробовать более быстрый подход.
Попытка 3а: mvжалуется
Тестирование в подкаталоге:
/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
Я не уверен, что это ошибка, но, возможно, cpможет выручить меня ..
Попытка 3b: cpникуда не денется через 8 часов
/home/data> cp -nr repo ../data2
Он читает диск в течение 8 часов, и я решаю отменить его и вернуться к rsync.
Попытка 4: rsyncсканирование через 8 часов после создания списка файлов
Прервано снова. -WПочти, как сделать «посылать инкрементный список файлов» быстрее, что в моем понимании не имеет смысла. Несмотря на это, передача ужасно медленная, и я отказываюсь от этого.
Попытка 6: tar
/home/data> nohup tar cf - . |(cd ../data2; tar xvfk -)
В основном, пытаясь переписать все, кроме игнорирования существующих файлов. Он должен расширять до 1,7 ТБ существующих файлов, но, по крайней мере, он читает со скоростью 1,2 ГБ / мин.
Пока что это единственная команда, которая дает мгновенное удовлетворение.
Обновление: снова прервано, как-то даже с nohup ..
Попытка 7: харакири
Все еще обсуждаем этот
Попытка 8: сценарий «слияния» с mv
В директории назначения было около 120 тыс. Пустых директорий, поэтому я побежал
/home/data2/repo> find . -type d -empty -exec rmdir {} \;
Рубиновый скрипт:
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
СДЕЛАННЫЙ.
Вы правы, он должен найти и перечислить каждый каталог, и 1 миллион каталогов будет болезненным.
cybernard 10 лет назад
0
Посмотрите на светлую сторону ... если бы это была Windows, у вас не было бы даже миллиона подкаталогов и все равно была бы работающая ОС. :)
Jack 10 лет назад
2
@ Джек, правда? Есть ли у Windows предел? Разве это не пережиток дней FAT32 (я не использовал Windows в качестве основной ОС с 2001 года, поэтому я не совсем в курсе этого)?
terdon 10 лет назад
0
@ Тим, почему бы тебе просто не повторить? Теоретически, `mv` удалит исходный файл, только если конечный файл полностью скопирован, так что _should_ работает нормально. Кроме того, у вас есть физический доступ к машине или это делается через соединение `ssh`?
terdon 10 лет назад
1
@terdon - У Windows нет предела, как такового ... но есть момент, когда он становится непригодным для всех целей и задач. Проводнику Windows понадобится навсегда, чтобы отобразить список файлов и т. Д.
Jack 10 лет назад
0
@ Джек ОК, но это повлияет только на этот каталог? Или это повлияет на всю систему?
terdon 10 лет назад
0
@terdon - только один каталог. См. Http://technet.microsoft.com/en-us/magazine/hh395477.aspx
Jack 10 лет назад
0
@terdon - хотел использовать `mv -f`, но протестировал его на подкаталоге и получил` mv: перемещение между устройствами не удалось: '(foobar)' в '../../data2/repo/foobar'; невозможно удалить цель: является каталогом. И да, я использую `ssh`.
Tim 10 лет назад
0
С таким количеством файлов / каталогов, честно говоря, было бы лучше использовать `dd` (хотя для 2 ТБ это заняло бы часы / дни)
justbrowsing 10 лет назад
0
@justbrowsing - проблема в том, что мне нужно объединить / возобновить. Может ли `dd` сделать это? Если некоторые исходные файлы еще не были удалены, я бы просто удалил каталог назначения и снова `mv` источника. Это заняло бы всего 24 часа, если бы оно не было прервано.
Tim 10 лет назад
0
Нет, не может. `mv` не прощает, если вы продолжаете отключаться, вы можете потерять данные и даже не знать об этом. Как вы сказали, вы делаете это через `ssh`, я настоятельно рекомендую использовать` screen` и detach. Включите ведение журнала и следите за этим. Если вы используете многословный, это займет больше времени. Также попробуйте `iotop`
justbrowsing 10 лет назад
5
@justbrowsing - Хороший вызов на `screen`. Я задавался вопросом о многословности, но я думаю, что уже слишком поздно, чтобы перезапустить `tar` прямо сейчас. И `iotop` была моей любимой утилитой в последние несколько дней :)
Tim 10 лет назад
2
один из ваших каталогов смонтирован с сервера? тогда я бы порекомендовал использовать прямую ссылку, используя `rsync dir1 server: dir2` или` rsync server: dir1 dir2` в зависимости от сервера, который с меньшей вероятностью будет отключен. вложение этой команды в оболочку `screen` позволяет избежать некоторых отключений.
meduz 10 лет назад
0
3 ответа на вопрос
5
Ярослав Рахматуллин
Вы когда-нибудь слышали о разделении больших задач на более мелкие?
/ home / data / repo содержит 1 млн. каталогов, каждый из которых содержит 11 каталогов и 10 файлов. Это составляет 2 ТБ.
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/ (...)
Время перерыва на кофе
Преимущество, которое я смутно подчеркиваю, заключается в том, что * вы * отслеживаете ход выполнения небольшими частями * вручную *, так что возобновление задачи займет меньше времени, если какая-то часть будет прервана (потому что вы знаете, какие шаги были успешно выполнены).
Ярослав Рахматуллин 10 лет назад
1
Это в основном то, что я в итоге делал, за исключением `mv`. К сожалению, нет никакого инструмента, встречающего `mv` и` rsync` на полпути.
Tim 10 лет назад
0
4
maki
This is what is happening:
Initially rsync will build the list of files.
Building this list is really slow, due to an initial sorting of the file list.
This can be avoided by using ls -f -1 and combining it with xargs for building the set of files that rsync will use, or either redirecting output to a file with the file list.
Passing this list to rsync instead of the folder, will make rsync to start working immediately.
Можете ли вы привести пример использования ls с rsync? У меня похожая, но не идентичная ситуация. На компьютере AI запущен rsyncd и большое дерево каталогов, которое я хочу перенести на компьютер B (фактически 90% каталога уже находится в B). Проблема в том, что я должен сделать это с помощью нестабильной мобильной связи, которая часто падает. Тратить час на создание списка файлов каждый раз, когда я перезагружаюсь, довольно неэффективно. Кроме того, B находится за NAT, который я не контролирую, поэтому сложно подключить A -> B, а B -> A легко.
d-b 9 лет назад
0
1
Angelo
Даже если rsync медленный (почему он медленный? Может быть, -z поможет), похоже, что вы многое перенесли, так что вы можете просто продолжать попытки:
Если вы использовали --remove-source-files, вы можете продолжить, удалив пустые каталоги. --remove-source-files удалит все файлы, но оставит каталоги там.
Просто убедитесь, что вы НЕ используете --remove-source-files с --delete для выполнения нескольких проходов.
Также для увеличения скорости вы можете использовать --inplace
Если вас выгнали из-за того, что вы пытаетесь сделать это удаленно на сервере, продолжайте и запустите это в «экранном» сеансе. По крайней мере, таким образом, вы можете позволить ему работать.