Воссоздание файловой системы XFS с `ftype = 1`

2134
jjlin

У меня есть система CentOS 7, где корневой файловой системой является XFS (созданная с ftype=0помощью настройки CentOS по умолчанию во время установки системы). К сожалению, overlay2драйвер хранилища Docker требует, чтобы файловая система была создана с ftype=1:

https://docs.docker.com/storage/storagedriver/overlayfs-driver/#prerequisites

Так что теперь я хотел бы воссоздать корневую FS с ftype=1. Я думал сделать это следующим образом:

  1. Загрузитесь в какое-нибудь спасательное изображение.
  2. xfsdump корневая ФС в удаленном месте.
  3. Воссоздайте корневую ФС с помощью ftype=1.
  4. xfsrestore корневой фс из удаленного дампа.

Однако в одном я не уверен, несет ли на xfsdumpвыходе что-либо связанное с ftypeнастройкой. То есть, возникнут ли какие-либо проблемы xfsrestoreс файловой системой XFS с другими ftypeнастройками?

Или есть лучший подход к решению этой конкретной проблемы (который не включает переустановку всей системы, перераспределение и т. Д.)?

3

1 ответ на вопрос

4
jjlin

Мой предложенный метод, казалось, работал нормально. Вот моя процедура:

  1. Ботинки в CentOS-7-x86_64-LiveGNOME-1804.iso.
  2. Откройте терминал и sudo -s.
  3. Сканирование для LVM томов: vgscan
  4. Перейдите в соответствующую группу томов ( centosв моем случае):vgchange -ay centos
  5. Сканирование логических томов в этой группе: lvscan
  6. Создайте точку монтирования для корневой FS: mkdir /mnt/root
  7. Смонтируйте логический том, соответствующий корневому FS: mount /dev/centos/root /mnt/root
  8. Дамп на удаленный хост: xfsdump -J - /mnt/root | ssh <host> 'cat >/data/rootfs.dump'
  9. Размонтировать корневую ФС: umount /mnt/root
  10. Воссоздайте корневую ФС: mkfs.xfs -f -n ftype=1 /dev/centos/root
  11. Смонтируйте воссозданный корневой FS: mount /dev/centos/root /mnt/root
  12. Восстановить с удаленного хоста: ssh <host> 'cat /data/rootfs.dump' | xfsrestore -J - /mnt/root
  13. Перезагружать. Все должно быть так, как было раньше, кроме как xfs_info /теперь должно показывать ftype=1.

Примечание: мой xfsdumpзвонок привел к ряду предупреждений в форме

xfsdump: WARNING: failed to get bulkstat information for inode 10485897

По словам человека, который, кажется, является разработчиком XFS ( http://xfs.9218.n7.nabble.com/xfs-and-lvm-snapshots-td1241.html ):

Их можно игнорировать - они являются инодами, которые ранее не были связаны, но все еще частично присутствуют на томе моментального снимка и видимы интерфейсам дескрипторов, которые xfsdump использует для извлечения всех инодов в моментальном снимке.

Не забудьте проверить свои dracut initramfs и / или конфигурацию GRUB на наличие ссылок UUID: `mkfs.xfs` генерирует новый UUID, и grub / initramfs не сможет найти его по старой ссылке. Восстановите, если нужно! Alex Mazzariol 6 лет назад 1
@AlexMazzariol Я не сталкивался с этой проблемой, и мне любопытно, почему. Ваша установка довольно стандартная? В любом случае, я думаю, что было бы неплохо использовать [`xfs_admin`] (https://linux.die.net/man/8/xfs_admin), чтобы получить (` -u`) UUID перед повторным созданием и, если необходимо, , установите (`-U`) UUID в воссозданной FS обратно к оригиналу. jjlin 6 лет назад 0
Да, пробовал как на LVM, так и на простом разбиении, на простой установке CentOS. В обоих случаях в `/ etc / fstab` разделы идентифицируются по UUID, и dracut не может распознать корень после` mkfs.xfs`; когда не используется LVM, GRUB также передает старые UUIDs как `root =` в ядро. Это можно решить, переделав grub-options и dracut или, как вы сказали, восстановив предыдущий UUID с помощью `xfs_admin`. Alex Mazzariol 6 лет назад 0

Похожие вопросы