Recreating an XFS file system with `ftype=1`

Question

I have a CentOS 7 system where the root file system is XFS (created with ftype=0, the default CentOS setting at the time the system was installed). Unfortunately, the Docker overlay2 storage driver requires that file system to have been created with ftype=1:

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

So now I'd like to recreate the root FS with ftype=1. I was thinking of doing that as follows:

1. Boot into a rescue image of some sort.
2. xfsdump the root FS to a remote location.
3. Recreate the root FS with ftype=1.
4. xfsrestore the root FS from the remote dump.

One thing I'm not sure about, though, is whether the xfsdump output carries anything related to the ftype setting. That is, would there be any issues doing the xfsrestore onto an XFS file system with a different ftype setting?

Or is there a better approach to solving this specific problem (that doesn't involve reinstalling the whole system, repartitioning, etc.)?

Solution

My proposed method seemed to work fine. Here's my procedure:

1. Boot into CentOS-7-x86_64-LiveGNOME-1804.iso.
2. Open a terminal and sudo -s.
3. Scan for LVM volumes: vgscan
4. Change into the appropriate volume group (centos in my case): vgchange -ay centos
5. Scan for the logical volumes in that group: lvscan
6. Create a mount point for the root FS: mkdir /mnt/root
7. Mount the logical volume corresponding to the root FS: mount /dev/centos/root /mnt/root
8. Dump to remote host: xfsdump -J - /mnt/root | ssh <host> 'cat >/data/rootfs.dump'
9. Unmount the root FS: umount /mnt/root
10. Recreate the root FS: mkfs.xfs -f -n ftype=1 /dev/centos/root
11. Mount the recreated root FS: mount /dev/centos/root /mnt/root
12. Restore from remote host: ssh <host> 'cat /data/rootfs.dump' | xfsrestore -J - /mnt/root
13. Reboot. Everything should be as it was before, except xfs_info / should now show ftype=1.

Note: My xfsdump call resulted in a number of warnings of the form

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

According to someone who appears to be an XFS developer (http://xfs.9218.n7.nabble.com/xfs-and-lvm-snapshots-tp1241p1246.html):

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.

Comments

[Alex Mazzariol]

Don't forget to check your dracut initramfs and/or GRUB config for UUID references: mkfs.xfs generates a new UUID, and grub/initramfs will not be able to find it with the old reference. Rebuild if needed!

[jjlin]

@AlexMazzariol I didn't run into this issue, and I'm kind of curious why. Is your install pretty standard? Anyway, I guess it might be a good idea to use xfs_admin to get (-u) the UUID before recreating, and if needed, set (-U) the UUID in the recreated FS back to the original.

[Alex Mazzariol]

Yes, tried on both LVM and plain partitioning, plain CentOS installation. In both cases on /etc/fstab the partitions are identified by UUID, and dracut fails to recognize the root after the mkfs.xfs; when not using LVM also GRUB passed the old UUIDs as root= to the kernel. Can be solved by remaking grub-options and dracut, or as you said, by restoring the previous UUID with xfs_admin.

[Bruce Adams]

I can independently confirm this procedure works on Rhel7 and is safe to use. I saved and restored the uuid with xfs_admin just in case. I used a local usb drive rather than ssh myself and save and restore was pretty quick.

[Richard]

Thanks for working out the detailed procedure, but why would you do this for Docker, since when you switch storage drivers you lose all existing containers/images installed anyway (under ./devicemapper they will not be visible in the new overlay2 mode which will have its own subdir ./overlay2)?

[jjlin]

@RichK. Your Docker state likely won't be too hard to recreate, but if your Docker host is also used for other things, recreating all that configuration could be painful.