Commands
Learn how to configure LVM on multipath devices in RHEL with this comprehensive step-by-step guide. Improve storage performance, ensure high availability, and master enterprise-level disk
Self-explanatory placeholder (typically) matches the keyword catch phrase statement.
Migrating from Ext4 to Btrfs has become a common objective for Linux administrators who want advanced features—snapshots, transparent compression, checksumming, incremental send/receive, and more—without sacrificing stability. While Ext4 remains a reliable, mature filesystem, Btrfs brings modern capabilities that support better data integrity, more flexible storage management, and simplified backup workflows.
Yet, one lingering misconception persists: switching from Ext4 to Btrfs requires major downtime and painful data migrations. |
In reality, with sensible preparation and the right tools, you can perform the conversion surprisingly quickly and with minimal interruption to running services.
This guide presents a structured, clear, and inclusive walkthrough for converting Ext4 filesystems to Btrfs safely and efficiently. You’ll learn best practices, pre-conversion validation steps, backup strategies, post-conversion tuning, and techniques for keeping downtime low. CLI examples and tables are included to support clarity, and all steps are distribution-agnostic unless noted.
Before jumping into commands, it helps to understand the tangible benefits your system gains from conversion. While Ext4 is robust, Btrfs offers:
🟢 Key Advantages of Btrfs |
| Feature | Ext4 | Btrfs |
|---|---|---|
| Copy-on-write | No | Yes |
| Built-in snapshots | No | Yes |
| Subvolumes | No | Yes |
| Transparent compression | No | Yes (zstd, lzo) |
| Deduplication support | No | Yes (out-of-band) |
| Send/receive for replication | No | Yes |
| Checksummed data + metadata | Metadata only | Full checksumming |
| Online balancing | No | Yes |
If you manage environments with containers, databases, VMs, or high-churn workloads, these enhancements can meaningfully improve operations. Even on personal systems, snapshots and compression make Btrfs attractive.
Yes, you can, but there’s an important nuance:
|
|
|
However, in-place conversion has limits:
|
|
|
Minimal downtime is possible because:
|
|
|
Approximate downtime windows:
| Scenario | Expected Downtime |
|---|---|
| Converting non-root filesystem | 1–5 minutes |
| Converting root filesystem (recovery/live environment) | 5–20 minutes |
| Very large drives (4TB+) | Up to 30 minutes |
Downtime primarily depends on the partition size and speed, not the data volume.
Even though the conversion tool is stable, it’s vital to prepare your environment to protect data and maintain system integrity.
▶️ Check tool availability |
Most modern distributions include the Btrfs utilities package:
sudo apt install btrfs-progs # Debian/Ubuntu
sudo dnf install btrfs-progs # Fedora/RHEL
sudo pacman -S btrfs-progs # Arch Linux
▶️ Ensure the filesystem is clean |
Ext4 must be in a consistent state:
sudo umount /dev/sdXN
sudo e2fsck -f /dev/sdXN
If you are converting the root filesystem:
sudo touch /forcefsck
reboot
▶️ Back up essential data |
While in-place conversion is safe, backups are non-negotiable. Suggested backup targets:
|
|
|
Quick snapshot-style backup (rsync-based):
sudo rsync -aAXHv /source/ /backup/location/
▶️ Verify storage layout |
Use lsblk to identify the correct devices:
lsblk -f
Take note of:
|
|
|
|
The conversion sequence is designed to be predictable and reversible.
▶️ Step 1: Unmount the Ext4 Partition |
For non-root partitions:
sudo umount /dev/sdXN
If busy, identify processes with:
sudo lsof /mountpoint
Kill or stop services temporarily (database servers, VMs, containers, etc.). This is typically where the short downtime window begins.
▶️ Step 2: Validate and Repair the Ext4 Filesystem |
Always validate with fsck:
sudo e2fsck -f /dev/sdXN
This step ensures metadata consistency before conversion.
▶️ Step 3: Perform the Conversion |
Start the conversion:
sudo btrfs-convert /dev/sdXN
What this does:
|
|
|
Conversion progress will display in your terminal. If you experience interruptions (power loss, system crash), the tool is designed to be resilient, but you should repeat the fsck and start the process over.
▶️ Step 4: Mount the New Btrfs Filesystem |
Create a mount point if needed:
sudo mkdir -p /mnt/newbtrfs
sudo mount -t btrfs /dev/sdXN /mnt/newbtrfs
Verify:
sudo btrfs filesystem df /mnt/newbtrfs
If all looks correct, you can safely continue.
▶️ Step 5: Evaluate or Remove the Ext4 Snapshot |
You can revert to Ext4 if problems arise:
sudo btrfs subvolume list /mnt/newbtrfs
You’ll see:
ID 256 gen 5 top level 5 path ext2_saved
To revert:
sudo umount /mnt/newbtrfs
sudo btrfs-convert --rollback /dev/sdXN
If you are satisfied with Btrfs and want to reclaim space, delete the snapshot:
sudo btrfs subvolume delete /mnt/newbtrfs/ext2_saved
sudo btrfs balance start -m /mnt/newbtrfs
This commits you permanently to Btrfs.
▶️ Step 6: Add Btrfs Options to fstab |
Edit /etc/fstab:
sudo vim /etc/fstab
Example recommended config:
UUID=xxxx-xxxx /mnt/newbtrfs btrfs defaults,noatime,compress=zstd,space_cache=v2 0 0
Key options explained:
|
|
|
Converting the root filesystem involves more steps, but downtime can still be kept low.
▶️ Boot From a Live ISO |
Use a USB bootable image from your distro:
|
▶️ Install btrfs-progs in the live environment |
Some ISOs include it; if not:
sudo apt install btrfs-progs
(or equivalent for your distro)
▶️ Repeat the Conversion Steps |
|
|
|
|
▶️ Update your bootloader |
Most systems with systemd-boot or GRUB detect Btrfs automatically. For GRUB:
sudo update-grub
Fedora:
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
▶️ Reboot Into Btrfs |
Once your fstab is updated and GRUB recognizes the filesystem, reboot normally.
💡NOTE: Total downtime: typically 10–20 minutes. |
Once your system is running on Btrfs, you can optimize further.
✅ Enable Compression (If Not Already) |
If compression wasn’t enabled in fstab initially, apply it retroactively:
sudo btrfs property set / compress zstd
✅ Run a Full Balance |
To reorganize the filesystem post-conversion:
sudo btrfs balance start -dconvert=single -mconvert=single /mnt/newbtrfs
Why this matters:
|
|
✅ Create Subvolumes |
At minimum, create subvolumes for:
/home
/var
/.snapshots
Example:
sudo btrfs subvolume create /mnt/newbtrfs/home
✅ Set Up Snapshots |
If using Snapper:
sudo snapper -c root create-config /
If using Btrbk or Timeshift, configure according to your tool’s documentation.
✅ Test Recovery and Scrubbing |
Monthly scrubbing protects against bit rot:
sudo btrfs scrub start /
✅ Conversion fails with “not enough free space” |
You need roughly 15–20% free space before conversion. Delete unused files or expand the partition.
✅ System won’t boot after root conversion |
Common causes:
|
|
Rebuild initramfs from the live ISO:
sudo chroot /mnt/newbtrfs
sudo update-initramfs -u
exit
✅ Slow performance after conversion |
Run a full balance:
sudo btrfs balance start /mnt/newbtrfs
Enable compression and mount options as described above.
While Btrfs suits many workloads, avoid conversion if:
|
|
|
|
Learn how to configure LVM on multipath devices in RHEL with this comprehensive step-by-step guide. Improve storage performance, ensure high availability, and master enterprise-level disk
In this article, “Useful LVM commands with examples,” we will explore a selection of essential LVM commands commonly encountered by Linux sysadmins, engineers, and enthusiasts
In this article, we will compare Btrfs and LVM and determine which filesystem is better. This should be an interesting read…why you ask? Table of