Can btrfs be converted to ext4


Gemini

Directly converting a Btrfs filesystem to ext4 in-place (without formatting) is not possible.

While tools exist to convert from ext2/3/4 to Btrfs (btrfs-convert), there is no inverse conversion utility because Btrfs features—such as copy-on-write (CoW), dynamic inode allocation, internal chunk trees, and subvolumes—cannot be mapped back onto the fixed structural metadata of an ext4 block layout.

To migrate a partition or drive from Btrfs to ext4, you must perform a standard backup, reformat, and restore procedure.

Standard Migration Procedure

1

Back up all data

Critical step — reformatting destroys all existing data

Copy all required files and subvolume contents to an external drive, secondary local volume, or network share using rsync or your preferred backup tool:

rsync -aHAXv /path/to/btrfs/mount/ /path/to/backup/

2

Unmount the Btrfs partition

Ensure no processes are using the filesystem, then unmount it:

sudo umount /dev/sdXN

(Replace /dev/sdXN with your actual drive/partition designation)

3

Format the partition to ext4

Create the new ext4 filesystem on the target partition:

sudo mkfs.ext4 /dev/sdXN

4

Update /etc/fstab

Update your /etc/fstab file with the new UUID and filesystem type (ext4) so the system mounts it correctly at boot:

sudo blkid /dev/sdXN

Replace the old Btrfs entry in /etc/fstab with the new UUID and standard ext4 mount options (e.g., defaults).

5

Restore your data

Mount the new ext4 partition and restore your files:

sudo mount /dev/sdXN /mnt
rsync -aHAXv /path/to/backup/ /mnt/

Want help crafting an rsync command or fstab entry for your specific drive setup?


You

Help me write an rsync command and fstab entry to migrate a Btrfs partition to ext4.


Gemini

To migrate a partition smoothly, you will run an rsync backup phase first, followed by updating your /etc/fstab configuration once the partition is reformatted to ext4.

1. rsync Transfer Command

Use this command to copy all data from your mounted Btrfs volume to your backup location while preserving permissions, extended attributes, ownership, and hard/symlinks:

sudo rsync -aHAXv --numeric-ids --progress /mnt/btrfs-source/ /mnt/backup-destination/

Flag breakdown:

  • -a (archive): Recurses through directories while preserving file modifications, symlinks, permissions, and ownership.
  • -H (hard links): Preserves hard-linked files.
  • -A (ACLs): Preserves Access Control Lists.
  • -X (xattrs): Preserves extended filesystem attributes (essential if backing up system directories or SELinux attributes).
  • -v (verbose): Prints transferred files to stdout.
  • --numeric-ids: Prevents rsync from mapping numeric UID/GID values to user/group names during the transfer (prevents ownership shifts across mounts).
  • --progress: Shows file progress during transfer.

Note on Trailing Slashes: Putting a trailing slash on the source directory (/mnt/btrfs-source/) ensures rsync copies the contents of the folder into the destination, rather than creating a nested folder.

2. /etc/fstab Configuration Entry

Once you format the target partition with sudo mkfs.ext4 /dev/sdXN, locate its new UUID:

sudo blkid /dev/sdXN

Example /etc/fstab Line:

Replace the old Btrfs line in /etc/fstab with the updated ext4 entry:

# <file system>                            <mount point>    <type>  <options>       <dump>  <pass>
UUID=12345678-abcd-1234-abcd-123456789abc  /mnt/data        ext4    defaults,noatime    0       2

Standard ext4 Options:

  • defaults: Uses standard mount options (rw, suid, dev, exec, auto, nouser, async).
  • noatime: Disables writing file access times upon reading files, reducing disk write wear and improving performance.
  • 0 (dump): Disables dump backups for this filesystem.
  • 2 (pass): Tells fsck to check this partition during boot after the root filesystem (use 1 for root /, 2 for data drives, 0 to disable auto-checking).

Need help setting up a system migration or testing your fstab file safely before rebooting?


You

How do I safely test my /etc/fstab file before rebooting?


Gemini

Testing your /etc/fstab file before rebooting is critical to prevent boot failures, drops into emergency rescue shells, or system hangs.

You can safely validate syntax, verify UUIDs, and test mounts using built-in system tools.

Step 1: Check Syntax and Structure (findmnt)

Run findmnt --verify to catch syntax errors, non-existent mount points, or invalid mount options:

sudo findmnt --verify
  • Pass: Returns clean output or minor warnings.
  • Fail: Displays explicit errors highlighting invalid lines, broken UUID syntax, or incorrect filesystem types.

Step 2: Test Mount without Rebooting (mount -a)

The mount -a command reads /etc/fstab and attempts to mount all configured filesystems that are not currently mounted and do not have the noauto option set.

  1. Unmount the target drive first (if it's already mounted):
    sudo umount /path/to/mountpoint
    
  2. Run mount -a with verbose output:
    sudo mount -a -v
    
  3. Check the result: If mount -a outputs nothing (or shows explicit mount confirmations with -v) and returns to the prompt without errors, your /etc/fstab entry works.

Step 3: Verify Active Mounts

Confirm that the filesystem actually mounted to the correct path with the intended flags:

findmnt /path/to/mountpoint

You can also check available space on the newly mounted filesystem:

df -h /path/to/mountpoint

Step 4: Safety Safeguard (Optional Systemd Timeout)

If you are modifying a critical system path (or want extra protection against typos), add x-systemd.mount-timeout to your fstab options for that line:

UUID=12345678-abcd-1234-abcd-123456789abc /mnt/data ext4 defaults,noatime,x-systemd.mount-timeout=10s 0 2

This prevents systemd from hanging indefinitely during boot if the partition cannot be found or mounted.