Я использую почтовый сервер с хранилищем maildir. Это означает, что создается довольно много файлов, а у меня только что закончились inodes. AFAIK нет волшебной команды для увеличения количества inodes в файловой системе ext # (или я ошибаюсь?), Поэтому мне нужно сделать резервную копию и восстановить всю файловую систему. Но как мне это сделать? Я попытался создать еще один раздел и сделать:
dump -f - -0 /vservers/mail | restore rf - -u -v
Хотя это, похоже, работает, это занимает гораздо больше времени, чем я готов ждать (ему удалось создать 500 пустых каталогов за 2 часа, прежде чем я остановил процесс; strace показал, что восстановление вызывало множество бесполезных lseeks). Есть ли какой-либо другой способ скопировать полную файловую систему (включая сокеты, файлы устройств, владельцев, разрешения, ACL и т. Д.)? Дополнительная информация: исходная файловая система - это ext3, место назначения - ext4, файловые системы - на lvm, файловая система, которую я хочу переместить, - это корневая файловая система для vserver.
Мое альтернативное предложение по копированию файловой системы следующее. Имейте в виду, что ближе всего к этой проблеме я подошел к использованию find + xargs + rm, чтобы очистить maildir, который зашел с ума от бесполезного мусора, поэтому вы должны увидеть, к чему это приведет через час или около того.
cd root_of_source ; find . -print0 | tar -c --null -T - -f - | tar -sxf - -C root_of_target
Функция этой конструкции:
Независимо от того, какой метод вы используете:
Кроме как dump | restore, ты можешь использовать tar | tar, или просто cp -ax или rsync чтобы скопировать все файлы в новый файл fs. По моему опыту, dump | restore это самый быстрый способ.
Для справки, на довольно старой и медленной машине у меня уходит 35 минут, чтобы скопировать fs с помощью dump | restore где fs имеет 420 774 inode, занимающих 7,8 ГБ пространства.
Для сравнения: при использовании tar | tarи 64 минуты с использованием cp -ax.
Несколько месяцев назад я выложил патч, чтобы dump быстрее, но это было после выхода 0.4b44, а другого релиза еще не было. Вы можете найти патч на список рассылки. Самостоятельное построение 0.4b44 с применением этого патча может иметь большое значение. Для меня это сократило время с 35 минут до 25. Отзывы о списке рассылки были бы полезны.
Рассматривали ли вы попытку использовать unionfs для объединения существующей файловой системы с новой, при этом запись идет в новую файловую систему?
Я никогда не использовал UnionFS, но то, что я слышал об этом, звучит так, как будто это может позволить вам начать работать и снова начать запись данных на диск без необходимости воссоздавать файловую систему путем объединения существующей файловой системы только для чтения с новым файловая система как файловая система с возможностью записи. Могут быть проблемы с производительностью или другие проблемы, которые делают это недопустимым, но если вы просто ищете идеи и у вас есть время, пока выполняется дамп, вы, вероятно, можете исследовать это с помощью рабочего набора команд.