SUMMARY Simple method to convert EXT4 to XFS without data restore

Latest response

Hello esteemed forum members.

For a specific project, I was asked to test if conversion of EXT4 to XFS could work without data restores on RHEL 7.9.

I did it by using EPEL tool fstransform (available in RHEL repositories).

Maybe this information helps someone else in the future.

Step 1
Install tool from EPEL repository:

$ sudo yum -y install fstransform

Step 2
Check current setup for file system /myfs:

$ uname -a && sudo lsblk -f | awk '$NF=="/myfs" {print $NF,"is file system type",$2}' 
Linux myhost.domain.dom 3.10.0-1160.25.1.el7.x86_64 #1 SMP Tue Apr 13 18:55:45 EDT 2021 x86_64 x86_64 x86_64 GNU/Linux
/myfs is file system type ext4

$ sudo mount | grep myfs
/dev/mapper/myvg-mylv on /myfs type ext4 (rw,noatime,data=ordered)

Step 3
Unmount file system /myfs and run the conversion:

$ sudo umount /myfs

$ sudo fstransform /dev/mapper/myvg-mylv xfs

Step 4
Change file system type in /etc/fstab and remount /myfs:

$ sudo sed -i -e "s#/myfs.*ext4#/myfs xfs#" /etc/fstab

$ sudo mount /myfs

$ uname -a && sudo lsblk -f | awk '$NF=="/myfs" {print $NF,"is file system type",$2}'
Linux myhost.domain.dom 3.10.0-1160.25.1.el7.x86_64 #1 SMP Tue Apr 13 18:55:45 EDT 2021 x86_64 x86_64 x86_64 GNU/Linux
/myfs is file system type xfs

Yes, certainly there are some caveats and backups are important in case something goes wrong.


Dusan Baljevic (amateur radio VK2COT)


Hi Dusan,

Thanks for sharing ! I want to point out that this method is only applicable for filesystems containing "normal data". :)
What's not possible is to achieve the same for the root filesystem - there is no safe way to convert from ext4 to XFS.


Hi Dusan and Christian,

The below list contains file systems I would not convert this way:

  • / (root)
  • /boot
  • /var
  • /var/lib
  • /usr

It is a nice concept.

Hints to add:

  • Make a copy of the /etc/fstab before starting the activities.
  • make a snapshot if you do this on a virtual machine.
  • run a rear backup of compatible backup (e.g. clonezilla) if you want to do this on a physical machine.

Warning: if it fails and you have no disklevel backup, you are on your own

Red Hat does not support EPEL related tools.


Jan Gerrit

P.S. in the past an "upgrade" from ext3 to ext4 was not supported either.

Hi Jan,

Thanks for adding these details and hints ! Couldn't agree more ... And to be honest, I wouldn't do that on a
production system at all ... following the motto "not everything that is possible must necessarily be done". :)



Your comments are valid and correct. COmpletely in sync with my views.

As I stated, there were caveats with this method and backups are important.

POC was done to test if it was possible to convert and verify how long it took :)

In my view, as of 2021, there should be only DevOps style method for RHEL package (or any other type of) updates. Replace in-place updates with in-place swap.

There are basically two ways to handle Linux server patch management:

• In-place update (apply patches on current server and hope it works), or
• In-place swap (build server with latest patches and features and replace the old one).


Dusan Baljevic (amateur radio VK2COT)

Thanks for sharing Baljevic. To me it looks it is worth to try conversion of EXT4 to XFS and obviously need to either have full backup or snapshots in case of virtual machines or even azure linux vms especially you can take os disk snapshot. As in general practice xfs is being used for large file systems not likely for / and /boot and /var.If anything goes wrong you can revert back. Easy in case of virtual machine little difficult in case of physical servers.

I'd only recommend trying this on a system you don't care if it crashes first.

Next, if you do perform this, consider all the good tips from Christian, Dusan, and Jan above.

However, I am here to just simply reinforce what's been said, please... please - if you don't have a backup, and a means to restore, please get one, especially before trying something ultra-risky as above.

Ask yourself, what would happen if the system i care about would no longer work? Ask yourself what steps you could have taken in advance to have a solid back and a means to restore. Please consider this regardless if you try the risky method that none of us recommend.

Consider building a new system, create the services, migrate the data.


fstransform /dev/datavg/lv01 xfs fstransform: starting version 0.9.3, checking environment fstransform: checking for which... '/bin/which' fstransform: checking for expr... '/bin/expr' fstransform: checking for id... '/bin/id' fstransform: parsing command line arguments fstransform: checking for stat... '/bin/stat' fstransform: checking for mkfifo... '/bin/mkfifo' fstransform: checking for blockdev... '/sbin/blockdev' fstransform: checking for losetup... '/sbin/losetup' fstransform: checking for fsck... '/sbin/fsck' fstransform: checking for mkfs... '/sbin/mkfs' fstransform: checking for mount... '/bin/mount' fstransform: checking for umount... '/bin/umount' fstransform: checking for mkdir... '/bin/mkdir' fstransform: checking for rmdir... '/bin/rmdir' fstransform: checking for rm... '/bin/rm' fstransform: checking for dd... '/bin/dd' fstransform: checking for sync... '/bin/sync' fstransform: checking for fsmove... '/sbin/fsmove' fstransform: checking for fsremap... '/sbin/fsremap' fstransform: checking for fsck(source file-system)... '/sbin/fsck' fstransform: checking for fsck(target file-system)... '/sbin/fsck' fstransform: looking for optional commands fstransform: checking for sleep... '/bin/sleep' fstransform: checking for date... '/bin/date' 11:03:21 fstransform: environment check passed. 11:03:21 fstransform: saving output of this execution into /var/tmp/fstransform/fstransform.log.50424 11:03:21 fstransform: preparing to transform device '/dev/datavg/lv01' to file-system type 'xfs' 11:03:21 fstransform: device '/dev/datavg/lv01' not found in the output of command /bin/mount, assuming it is not mounted

11:03:21 ERROR! fstransform: just mounted device '/dev/datavg/lv01' at mount point '/tmp/fstransform.mount.50424' but still cannot find it in the output of command /bin/mount I give up, sorry

Hi Lorak,

I have not used fstransform since my proof-of-concept test in 2021.

Note that all of us in this forum strongly advise against using it in any production-like environment. This is really more like a "toy" for enthusiasts :)

Without having more details of your problem, I can make the following summary for the moment:

a) fstransform failed to mount the file system in question.

This happened in the following part of Shell script (yes, fstransform is a plain old Shell script):

find_device_mount_point_and_fstype() {
  local my_dev="$DEVICE"
  local my_mount_point= my_fstype= my_now=
  local ret="`echo_device_mount_point_and_fstype \"$my_dev\"`"
  if test "$ret" = ""; then
    log_info "device '$my_dev' not found in the output of command $CMD_mount, assuming it is not mounted"
    local ret="`echo_device_mount_point_and_fstype \"$my_dev\"`"
    if test "$ret" = ""; then
      log_err "just mounted device '$my_dev' at mount point '$DEVICE_MOUNT_POINT'"
      log_err_add "but still cannot find it in the output of command $CMD_mount"
      log_err_add "I give up, sorry"
      exit 1

b) find_device_mount_point_and_fstype calls initial_mount_device, which is defined as:

initial_mount_device() {
  "$CMD_mkdir" -p "$DEVICE_MOUNT_POINT" >/dev/null 2>&1


  if test "$DEVICE_FSTYPE" != ""; then
    exec_cmd "$CMD_mount" -t "$DEVICE_FSTYPE" "$DEVICE" "$DEVICE_MOUNT_POINT"
    exec_cmd "$CMD_mount" "$DEVICE" "$DEVICE_MOUNT_POINT"
  CLEANUP_0="'$CMD_umount' '$DEVICE'; $CLEANUP_0"

c) So, it is obvious that mounting of file system /dev/datavg/lv01 failed.

May I ask a few questions:

  1. Is /tmp file system mounted with "noexec" option?

  2. Did you use any command-line option for fstransform:

Usage: /sbin/fstransform [OPTION]... DEVICE NEW-FILE-SYSTEM-TYPE
Transform file system inside DEVICE to NEW-FILE-SYSTEM-TYPE,
preserving its contents and without need for backup

  --help                        Print this help and exit
  --new-size=SIZE               Set new file system length. default: device length
  --old-file-system=OLD-TYPE    Override current (old) file system type autodetection
  --force-untested-file-systems Transform also untested file systems (DANGEROUS)
  --list-source-file-systems    Print list of file systems supported as source
  --list-target-file-systems    Print list of file systems supported as target
  --reversible[=yes|no]   Create zero-file, fsremap will do a reversible transformation
                                default: no
  --no-questions          Never ask any question or confirmation
  --show-time[=yes|=no]   Show current time before each message. default: yes
  --loop-file=LOOP-FILE   Override loop-file path
  --loop-mount-point=PATH Override loop-file mount point
  --zero-file=ZERO-FILE   Override zero-file path
  --cmd-CMD-NAME=CMD-PATH Set external command CMD-NAME to use. default: autodetected
  --opts-fsmove=OPTS      Pass OPTS as additional options to 'fsmove'
  --opts-fsremap=OPTS     Pass OPTS as additional options to 'fsremap'
  --opts-mkfs=OPTS        Pass OPTS as options to 'mkfs'. default: '-q'
  --opts-fsck-source=OPTS Override 'fsck' options for old file system. default: '-p -f'
  --opts-fsck-target=OPTS Override 'fsck' options for new file system. default: '-p -f'
  --x-OPTION=VALUE        Set internal, undocumented option. For maintainers only.
  1. Were there any other errors before the script failed?


Dusan Baljevic (amateur radio VK2COT)