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: Preventsrsyncfrom 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/) ensuresrsynccopies 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): Tellsfsckto check this partition during boot after the root filesystem (use1for root/,2for data drives,0to 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.
- Unmount the target drive first (if it's already mounted):
sudo umount /path/to/mountpoint - Run
mount -awith verbose output:sudo mount -a -v - Check the result: If
mount -aoutputs nothing (or shows explicit mount confirmations with-v) and returns to the prompt without errors, your/etc/fstabentry 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.