Ricreare un file system XFS con `ftype = 1`

Ho un sistema CentOS 7 in cui il file system radice è XFS (creato con ftype=0, l'impostazione CentOS predefinita al momento dell'installazione del sistema). Sfortunatamente, il overlay2driver di archiviazione Docker richiede che il file system sia stato creato con ftype=1:

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

Quindi ora vorrei ricreare il root FS con ftype=1. Stavo pensando di farlo come segue:

Avvia in un'immagine di salvataggio di qualche tipo.
xfsdump il root FS in una posizione remota.
Ricreare il root FS con ftype=1.
xfsrestore il root FS dal dump remoto.

Una cosa di cui non sono sicuro, tuttavia, è se l' xfsdumpoutput abbia qualcosa di correlato ftypeall'impostazione. Cioè, ci sarebbero problemi a fare xfsrestoreun file system XFS con un'impostazione diversa ftype?

Oppure esiste un approccio migliore per risolvere questo problema specifico (che non comporta la reinstallazione dell'intero sistema, il ripartizionamento, ecc.)?

— jjlin
fonte

Il mio metodo proposto sembrava funzionare bene. Ecco la mia procedura:

Avvia in CentOS-7-x86_64-LiveGNOME-1804.iso.
Aprire un terminale e sudo -s.
Scansione per volumi LVM: vgscan
Passare al gruppo di volumi appropriato ( centosnel mio caso):vgchange -ay centos
Cerca i volumi logici in quel gruppo: lvscan
Crea un mount point per il root FS: mkdir /mnt/root
Montare il volume logico corrispondente all'FS principale: mount /dev/centos/root /mnt/root
Dump su host remoto: xfsdump -J - /mnt/root | ssh <host> 'cat >/data/rootfs.dump'
Smonta il root FS: umount /mnt/root
Ricrea il root FS: mkfs.xfs -f -n ftype=1 /dev/centos/root
Montare la radice ricreata FS: mount /dev/centos/root /mnt/root
Ripristina da host remoto: ssh <host> 'cat /data/rootfs.dump' | xfsrestore -J - /mnt/root
Reboot. Tutto dovrebbe essere come prima, tranne xfs_info /che ora dovrebbe mostrare ftype=1.

Nota: la mia xfsdumpchiamata ha comportato una serie di avvisi del modulo

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

Secondo qualcuno che sembra essere uno sviluppatore XFS ( http://xfs.9218.n7.nabble.com/xfs-and-lvm-snapshots-td1241.html ):

Possono essere ignorati: sono inode precedentemente non collegati, ma sono ancora parzialmente presenti sul volume dell'istantanea e sono visibili alle interfacce gestite da xfsdump per estrarre tutti gli inode nell'istantanea.

— jjlin
fonte

Non dimenticare di controllare i tuoi initramfs dracut e / o la configurazione di GRUB per i riferimenti UUID: mkfs.xfsgenera un nuovo UUID e grub / initramfs non sarà in grado di trovarlo con il vecchio riferimento. Ricostruisci se necessario!

— Alex Mazzariol,

@AlexMazzariol Non ho riscontrato questo problema e sono curioso di sapere perché. La tua installazione è piuttosto standard? Ad ogni modo, suppongo che potrebbe essere una buona idea usare xfs_adminper ottenere ( -u) l'UUID prima di ricreare e, se necessario, riportare ( ) l'UUID -Unell'FS ricreato all'originale.

— jjlin,

Sì, ho provato sia su LVM che sul semplice partizionamento, sulla semplice installazione di CentOS. In entrambi i casi /etc/fstable partizioni sono identificate da UUID e dracut non riesce a riconoscere la radice dopo il mkfs.xfs; quando non si usa LVM anche GRUB ha passato i vecchi UUID root=al kernel. Può essere risolto rifacendo grub-options e dracut, o come hai detto, ripristinando l'UUID precedente con xfs_admin.

— Alex Mazzariol,

Posso confermare autonomamente che questa procedura funziona su Rhel7 ed è sicura da usare. Ho salvato e ripristinato l'UUID con xfs_admin per ogni evenienza. Ho usato un'unità USB locale piuttosto che ssh e il salvataggio e il ripristino sono stati piuttosto rapidi.

— Bruce Adams,