Назад | Перейти на главную страницу

Добавить всю файловую систему на 300 ГБ в репозиторий Git Annex?

По умолчанию я получаю сообщение об ошибке, что у меня слишком много открытых файлов из процесса. Если я подниму лимит вручную, я получаю сообщение об отсутствии памяти. По какой-то причине кажется, что Git Annex в его текущем состоянии не оптимизирован для такого рода задач (одновременное добавление тысяч файлов в репозиторий).

В качестве возможного решения моей следующей мыслью было сделать что-то вроде:

cd /
find . -type d | xargs git annex add --$NONRECURSIVELY
find . -type f | xargs git annex add
    # Need to add parent directories of each file first or adding files fails

Проблема с этим решением заключается в том, что из документации не видно способа нерекурсивного добавления каталога в Git Annex. Что-то мне не хватает или есть обходной путь?

Если предложенное мной решение заходит в тупик, есть ли другие способы решения этой проблемы?

Обновление: не делайте этого.

Очевидно, Git Annex перемещает каждый файл, добавленный в репозиторий, в некоторую структуру каталогов в .git / application / objects, а затем заменяет их символическими ссылками на реальные файлы в .git. Было бы хорошо, если бы я сначала не поэкспериментировал с добавлением / etc.

Излишне говорить, что сервер залит. К счастью, я нашел исправление:

find /etc -type l | while read file ; do realpath=`realpath "${file}"` ; rm "${file}" ; cp -rfa "${realpath}" "${file}" ; done

Изменить: игнорировать; Я тупой; система все еще залита шлангом; это будет долгая ночь.

Второе редактирование: удалось отключить систему. Это потребовало большого количества ручного восстановления / etc и переустановки каждого пакета, включая перенастройку / разблокировку большого количества из них и отладку / решение множества проблем с APT. Больше не буду пробовать.

Что касается проблемы контроля версий 300 гигабайт файлов, я вернусь с обновлением всякий раз, когда я решу что-то и заставлю его работать (независимо от того, с Git Annex или нет).

Я использую приложение для управления хостом, например:

  • создайте репозиторий приложения git в / var / application
  • в / var / application создайте подкаталог для каждой машины - сюда отправляются файлы, уникальные для этой машины. Например, /var/annex/mars.example.com/etc/default/krb5-kdc
  • иметь другой общий каталог для файлов, уникальных для сайта, например /var/annex/example.com/etc/resolv.conf
  • используйте gnu stow для управления всеми символическими ссылками в /, указывающими на / var / application / *
  • есть простой скрипт в /var/annex/example.com/usr/local/bin/, который запускает gnu stow и git application (указанный скрипт, конечно, получает символическую ссылку в / usr / local / bin всеми вышеперечисленными механизмами)

Все это действует как низкоскоростная распределенная «файловая система администратора» с контролем версий, постановкой и любыми проверками и противовесами, которые вы хотите внести в то, как вы используете git и git app.

Если вы разумно управляете своими машинами, вам не нужно проверять всю корневую файловую систему - большая часть ее не меняется от одной машины к другой. У вас действительно должен быть какой-то способ управления установкой и обновлением пакетов, но этот инструментарий можно сам зарегистрировать в приложении вместе с пакетами и другими блобами, которые он использует в качестве исходных данных - опять же, все с поддержкой версий благодаря git.

Небольшое обновление:

  1. Вся эта проблема была полностью ошибкой пользователя. Мой корневой диск - это твердотельный накопитель емкостью 256 ГБ, а одна из папок, которые я пытался добавить, сопоставлена ​​с массивом RAID 1 объемом 1,5 ТБ. Независимо от того, как я пытался это сделать, он неизбежно попытался бы скопировать больше файлов в папку /.git, чем мог бы поместиться диск (да). Не знаю, что, как я думал, должно было случиться: /.

  2. Вот почему вы не возитесь с системными каталогами ...

  3. Вместо этого инициализировал репозиторий Git Annex на диске 1,5 ТБ и просто скопировал каталоги корневого уровня, для которых я хотел создать резервную копию. Нормальный git annex add . работал блестяще, и мой репозиторий находился в процессе резервного копирования на Glacier в течение последних пяти дней или около того, используя эти крюки Аннексия-Ледник с небольшой проблемой.