На одном из моих размещенных серверов есть проблемы с XFS. после последнего сбоя некоторые из моих папок RRD были повреждены.
пример (извините, это на французском):
# rm *
rm: impossible de supprimer « create_rrd.sh »: La structure a besoin d'un nettoyage
rm: impossible de supprimer « old »: est un dossier
rm: impossible de supprimer « tcgraph.log »: La structure a besoin d'un nettoyage
rm: impossible de supprimer « tcgraph.rrd »: La structure a besoin d'un nettoyage
Обычным шагом было бы перезапустить систему в однопользовательском режиме или с живого компакт-диска и запустить xfs_repair на / dev / sda. К сожалению (это было бы слишком просто), хостинговая компания предоставляет возможность перезапуска с живого компакт-диска, что не работает. И посещение центра обработки данных - не вариант.
Кажется, что я вообще не могу трогать inodes, я каждый раз получаю сообщение «структура нуждается в очистке».
Итак, вопрос: знает ли кто-нибудь способ отремонтировать / исправить эту файловую систему XFS вручную? Любой низкоуровневый инструмент для работы с XFS, который может помочь?
Краткий ответ: нет.
Более длинный ответ - это было бы очень очень увлекательно чтобы попытаться скопировать все на ramdisk tmpfs, переключиться на него, затем размонтировать файловую систему жесткого диска и полностью запустить ее из ramdisk, пока вы восстанавливаете файловую систему диска.
Я не первый, кто подумал об этом, я обнаружил эта тема но нет информации о том, действительно ли схема работала. Поскольку целью этого было стереть диск, они не стали его отключать.
Для этого создайте каталог и mount -t tmpfs none /some/directory, затем начните заполнять его копией важных частей вашей системы (sshd, mount, umount, xfs tools, оболочка и все библиотеки, необходимые для ее запуска, возможно, все файлы / etc, чтобы быть уверенным, и, наконец, init. .. Здесь могут помочь сценарии создания тюрьмы chroot, а также наличие около 4 ГБ ОЗУ. Смонтируйте в нем копию proc, а если вы используете devfs, также смонтируйте копию devfs. Используя копию / etc / ssh / sshd_config, настройте sshd для запуска на другом порту. chroot на ваш ramdisk и убедитесь, что все работает и нет недостающих библиотек, затем запустите sshd на ramdisk (на альтернативном порту), чтобы он был там chrootted. Убедитесь, что вы может ssh (для этого также может потребоваться скопировать туда ваш / home каталог) (и открыть порт на любом брандмауэре, который у вас может быть).
Теперь начинается волшебство: вместо перехода к этой tmpfs вам нужно найти утилиту с именем pivot_root. Его единственная цель в жизни - позвонить pivot_root (). Он находится в util-linux на Debian. Цель pivot_root () состоит в том, чтобы chroot для всех процессов одновременно. Первоначально использовался для перемещения / из образа виртуального диска initrd на фактический диск, если это сработает, вы будете перемещать / с фактического диска на образ виртуального диска. Итак, допустим, вы сделали mkdir /mnt/tmpfs; mount -t tmpfs none /mnt/tmpfs После копирования туда всего, что вам нужно, следующим шагом будет mkdir /mnt/tmpfs/oldroot; pivot_root /mnt/tmpfs /oldroot (Если у вас закончилось место для копирования, размонтируйте / mnt / tmpfs и смонтируйте его снова, на этот раз с -o size=... поскольку по умолчанию разрешается только половина вашей памяти.)
Последний шаг - отключение / oldroot. Вам нужно будет размонтировать / oldroot / sysfs / oldroot / proc и так далее (проверьте / proc / mounts). Если вы все еще получаете сообщение «файловая система занята», вы можете попробовать принудительно или, по крайней мере, отследить все, где были открытые файлы, посмотрев на ls -l /proc/*/cwd /proc/*/fd/ | grep /oldroot/ и убивает все, что еще относится к нему (это, вероятно, включает в себя сервер ssh, который не был chrooted. Убедитесь, что вы вошли в этот альтернативный sshd, прежде чем начинать убивать вещи). Очевидно, не убивайте процесс 1 (init). Если вы не можете принудительно выполнить umount при запущенном init, вам нужно будет использовать chroot /oldroot /sbin/telinit u2 (2 = уровень запуска, на котором вы сейчас находитесь, или init, вероятно, убьет все, а затем вы перезагрузитесь и начнете заново), чтобы инициализировать "обновление", запустив "новый" init, который у вас есть на ramdisk. Вам нужно будет chroot его в / oldroot, чтобы заставить его использовать / oldroot / dev / initctl (ramdisk / dev / initctl не то же самое) (обратите внимание, что telinit будет использовать [/ oldroot] / dev / initctl для взаимодействия с существующим процессом инициализации, который был привязан к виртуальному диску, поэтому запускаемый им процесс инициализации будет находиться на виртуальном диске, а не в / oldroot).
Я не собираюсь пробовать это на производственном сервере. Может, попробую дома в эти выходные.