8

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

10

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.

| improve this answer | |
  • 1
    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! – Alex Mazzariol Aug 20 '18 at 20:46
  • @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. – jjlin Aug 21 '18 at 1:51
  • 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. – Alex Mazzariol Aug 21 '18 at 7:42
  • 2
    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. – Bruce Adams Jul 15 '19 at 16:05
  • 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)? – Rich K. Jan 30 at 2:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.