Conversion of an existing ext4 Fedora 32 system completely to btrfs?

Is there a smart and easy way to convert a whole Fedora 32 system with ext4 file-system, LUKS2 encrypted excepted /boot partition, to the new btrfs file-system upcoming with Fedora 33? What’s about the grub-bindings with btrfs? Is a fresh install recommended to get all btrfs benefits? My machines are all dual-boot systems with Windows 10. The partition layout is /root, /boot, /home and SWAP. Thank you.

1 Like

I 'd be interested in trying this before I nuke and install Fedora 33 :stuck_out_tongue: If It works I could stay, but I m tempted to move to Silverblue 33.

1 Like

btrfs-convert just converts ext4 to Btrfs, no post-install adjustments to give it the subvolume layout we’re using in new clean Btrfs installations. While it’s possible to do all of that post-install, it’s something of an adventure to write up and follow the steps, and it’s just easier to recommend fully backing up your data and doing a clean install. If you’re not ready for that, no problem, just stick with what you have and upgrade in place - and postpone moving to Btrfs to a more convenient time for you.

btrfs-convert does create a Btrfs file system with a new filesystem UUID and label. This will surely differ from what’s in /etc/fstab and also in the /boot/loader/entries drop-in snippets for GRUB. If you do the conversion with Fedora 32, you also need a new initramfs that has the btrfs kernel module in it. Fedora 33 kernels have the btrfs driver built-in.

So yeah there are a few hoops to jump through.

3 Likes

Thanks to all for your answers. For me it’s clear now to do a fresh install when I want to use btrfs.

What are the practical advantages using btrfs on a normal notebook using it every day for all my stuff? Is it generally right that btfrs has it biggest impact on huge storages under enterprise systems (e.g. IBM System Z etc.)? Please tell me something about your practical experiences with btrfs. :smiley:

You’ll have a much easier time by reinstalling, because to actually take advantage of btrfs features, you’ll need to merge /root, /home and potentially /boot into one btrfs partition, so simply converting the individual partitions (which btrfs CAN do) doesn’t really help you. Much more discussion of all this in the thread @vgaetera linked.

However, you can streamline that process a lot with a bit of planning:

  • backup any files you modified in /etc (probably not many)
  • save your list of installed packages using dnf history userinstalled > packagelist
  • backup your home elsewhere using cp -a, rsync or a dedicated backup program
  • (if applicable: backup anything you saved/changed elsewhere in the filesystem)

You can then simply copy home and etc-files back and let dnf install everything from your saved history*. That should leave very little cleanup to do.

*dnf install $(cat <packagelist> | sed -E 's/-[^-]+-[^-]+$//' to get rid of the package versions

Why not try both of them in a virtual machine via e.g. Gnome Boxes and then install whichever works better for you?

7 Likes

@lcts Thank you very much for your rich answer and your tips. I will follow your advise and I will make a fresh install after Fedora 33 is released. It’s a very good shortlist for saving an existing system. :smiley:

2 Likes

I already have SilverBlue 32 in a GnomeBoxes VM. I ve figured out how to configure most of the things I need. That’s why I feel confident and eager enough to migrate to it once I have the time. There are some kinks yet with flatpak which means some packages needed to be layered in but it’s good that that solution exists until flatpaks mature more.

Thanks for the backup shortlist :smiley:

What are the practical advantages using btrfs on a normal notebook using it every day for all my stuff? Is it generally right that btfrs has it biggest impact on huge storages under enterprise systems (e.g. IBM System Z etc.)? Please tell me something about your practical experiences with btrfs.

It’s not any one thing, it’s this long list of nice to have features, maybe not any single one of which is the killer feature for any single user. What’s a strong case for Btrfs for one user, may be a weak argument for another. And even vice versa. But it’s a benefit both users can be on Btrfs, because now both of their use cases can be met, and it’s under the umbrella of one file system.

A short list of benefits to Fedora is listed in the change proposall.

I like having “one big file system” rather than partitions that can run out of space. My use cases vary so sometimes I need lots of free space in /var, and then in another case in ~/. And even lately I’ve been working on making it easier to have multiple Fedora’s installed in separate subvolumes but on a single Btrfs file system - a space efficient way for some Fedora users to e.g. use a release version of Fedora as well as Rawhide; or Workstation and Silverblue. Also, I use transparent compression most everywhere.

More substantial lists of features:

Wikipedia: Btrfs features

Btrfs Wiki: Features

2 Likes

Would you say that a user on an older machine experiences a greater latency with btrfs standard layout as on ext4 with recommended partitions? Thank you for clear explanation. :smiley:

Depends on the workload. Btrfs is faster for some things and slower at others. One particular combination that’s not great for Btrfs are certain databases on (spinning) hard drives.

For the desktop user + spinning hard drive + webbrowser database (sqlite), you might benefit from adding autodefrag to fstab options for /home. It is currently a file system wide option.

Note for more substantial databases (many gigabytes, and very busy), that autodefrag can actually slow things down. The autodefrag mount option was designed with the desktop Firefox database type use case in mind.

1 Like

I created a spare (work partition) formatted as btrfs , and created a subvolume bearing the same name as the source directory In the example below, convert /mountname from ext4 to btrfs
sudo btrfs subvol create /workname/mountname

Create a work partition resident in the same directory as the where /mountname is identified.
sudo btrfs subvol create /workname/mountname
commented out the first.
for the duplicated line, I changed ext4 to btrfs and added the following to the fstab

UUID=xxxxxxxxxxxxxxxxxxxxxxxx /workname btrfs defaults,subvol=mountname,noatime 0 0
and then mounted the /workname.
With both online, I did a sudo cp -ra /source /workname
When done, edit the fstab and revise the two lines therein
The commented line refers to the original directory
make the btrfs entry have the same mount point (refer to the UUID… above
reboot
If all goes well, there is no need to undo the fstab entries
just leave the ext4 file around for a day, and then rm -rf that entry.

By the way, I believe that a btrfs utility exists to do automatically what I did manually.