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:


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


2 Answers 2


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.

  • 2
    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! Commented Aug 20, 2018 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
    Commented Aug 21, 2018 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. Commented Aug 21, 2018 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. Commented Jul 15, 2019 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)?
    – Richard
    Commented Jan 30, 2020 at 2:46

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.

  • 2
    Consider editing the larger answer rather than "confirming" as "me too" answers can often get voted to be deleted. If you intend this to stand alone as a complete answer - please be sure to edit all the information needed or explain a bit why / how this differs from the accepted answer.
    – bmike
    Commented Sep 13, 2023 at 19:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .