Recriando um sistema de arquivos XFS com 'ftype = 1'

Question

Eu tenho um sistema CentOS 7 em que o sistema de arquivos raiz é XFS (criado com ftype=0 , a configuração padrão do CentOS no momento em que o sistema foi instalado). Infelizmente, o driver de armazenamento overlay2 do Docker requer que o sistema de arquivos tenha sido criado com ftype=1 :

link

Agora, gostaria de recriar o FS raiz com ftype=1 . Eu estava pensando em fazer isso da seguinte maneira:

1. Inicialize em uma imagem de resgate de algum tipo.
2. xfsdump do FS raiz para um local remoto.
3. Recrie o FS raiz com ftype=1 .
4. xfsrestore do FS raiz do dump remoto.

Uma coisa que não tenho certeza é se a saída xfsdump carrega qualquer coisa relacionada à configuração ftype . Ou seja, haveria algum problema fazendo o xfsrestore em um sistema de arquivos XFS com uma configuração ftype diferente?

Ou existe uma abordagem melhor para resolver esse problema específico (que não envolve a reinstalação de todo o sistema, reparticionamento, etc.)?

    

Answer 1

Meu método proposto parecia funcionar bem. Aqui está o meu procedimento:

1. Inicialize em CentOS-7-x86_64-LiveGNOME-1804.iso .
2. Abra um terminal e sudo -s .
3. Verificar volumes de LVM: vgscan
4. Altere para o grupo de volumes apropriado ( centos no meu caso): vgchange -ay centos
5. Verifique os volumes lógicos nesse grupo: lvscan
6. Crie um ponto de montagem para o FS raiz: mkdir /mnt/root
7. Monte o volume lógico correspondente ao FS raiz: mount /dev/centos/root /mnt/root
8. Dump to host remoto: xfsdump -J - /mnt/root | ssh <host> 'cat >/data/rootfs.dump'
9. Desmontar o FS raiz: umount /mnt/root
10. Recrie a FS raiz: mkfs.xfs -f -n ftype=1 /dev/centos/root
11. Monte o FS raiz recriado: mount /dev/centos/root /mnt/root
12. Restaurar do host remoto: ssh <host> 'cat /data/rootfs.dump' | xfsrestore -J - /mnt/root
13. Reinicie. Tudo deve estar como estava antes, exceto que xfs_info / deve mostrar ftype=1 .

Observação: minha chamada xfsdump resultou em vários avisos do formulário

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

De acordo com alguém que parece ser um desenvolvedor do XFS ( link ):

They can be ignored - they are inodes that were previously unlinked, but are still partially there on the snapshot volume, and visible to the by-handle interfaces that xfsdump is using to extract all of the inodes in the snapshot.