14

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.)?

jjlin
  • 16,120

2 Answers2

17

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 (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.

jjlin
  • 16,120
0

I can confirm this worked for me too! Thank you. I pulled the original UUID using xfs_admin -u /dev/centos/root after step 5. I then used xfs_admin -U UUID /dev/centos/root after step 10. One additional step I did was after step 11, I set selinux to permissive (setenforce 0) as my first attempt produced selinux warnings or errors. I don't know if this was necessary but the errors went away.

George
  • 9