ext2 выводят/восстанавливают проблему
Я предполагаю, что A.foo.bar и B.foo.bar решают к тому же IP.
Не было бы никакого способа сделать это без своего рода проксирования Прикладного уровня. Вы могли использовать HTTP или соединение прокси SOCKS на Ваших клиентах, таким образом, можно переключить соединение на основе имени хоста. Вы могли, вероятно, также настроить IRC MitM, который обнаруживает имя хоста, которое клиент пробует к подключениям к, затем невмешательство к корректному серверу, но я не знаю, обеспечил ли протокол IRC достаточно информации, чтобы сделать это.
My alternative suggestion for copying the filesystem follows. Keep in mind that the closest I've come to this problem is using find+xargs+rm to clear a maildir that had gone wild with useless junk, so you should see where this gets you after an hour or so.
cd root_of_source ; find . -print0 | tar -c --null -T - -f - | tar -sxf - -C root_of_target
The function of this construct is
- Retrieve the list of files in their raw order
- Which is why I use find instead of tar's default... I don't know that tar's default is bad, I just know that find's is good,
- Pass that list to tar null terminated (so that any special characters are handled correctly).
- Take the tar format output, and untar the result (without re-sorting the input (-s)) in the target directory.
Regardless of the method you use:
- If this data is starting and ending on the same physical disks, your performance will naturally suck a LOT compared to normal operations (lots of seeks between reading from the source and writing to the destination).
- If you have some CPU available, a little compression shouldn't hurt, and may help Just add a 'gzip -c -1' stage between the tar commands, and a -z to the second tar.
Have you considered trying to use unionfs to union the existing filesystem with a new one, with writes going to the new filesystem?
I've never used UnionFS myself, but what I have heard about it sounds like it could let you go live and start writing data to disk again without having to re-create the filesystem by unioning the existing filesystem read-only, with a new filesystem as the writable filesystem. There may be performance hits or other issues that make this a no-go, but if you're just looking for ideas and have some time while the dump is running, you can probably research this to a workable set of commands.
Кроме дампа | восстановить , вы можете использовать tar | tar или просто cp -ax или rsync , чтобы скопировать все файлы в новую файловую систему. По моему опыту, дамп | restore - самый быстрый метод.
Для справки, на довольно старой и медленной машине у меня уходит 35 минут, чтобы скопировать fs с помощью dump | restore , где файловая система содержит 420 774 inode, занимающих 7,8 ГБ пространства.
Для сравнения, при использовании tar | tar и 64 минуты с использованием cp -ax .
Несколько месяцев назад я опубликовал патч, чтобы ускорить dump , но это было после выпуска 0.4b44 , а другого релиза пока не было. Вы можете найти патч в списке рассылки . Корпус 0. 4b44 самостоятельно с этим патчем может иметь большое значение. Для меня это сократило время с 35 минут до 25. Отзывы о списке рассылки были бы полезны.