Converting to BtrFS — Episode 3

Today — after running some tests on my newly installed Fedora 43 system using BtrFS — I decided that everything seemed to be working well enough that I’d try to migrate the LVM/EXT4 filesystem I use to store and share my personal pictures with the other hosts on my home lab network.

Unfortunately I think there was a problem with an unfinished update. The system wouldn’t boot into either of the first 2 kernels available in the GRUB menu. It did boot into the third, however I was reluctant to continue my test conversion to BtrFS with a compromised system. Nor did I want to spend a lot of time trying to resolve the boot issues — and the possibility that there might be other, deeper ones.

So I reinstalled the Fedora 43 Xfce spin and used my personal tools to install all of the packages and tools I use, as well as to make several interesting configuration mods to the system. I then ensured that I have a current backup of my pictures; and I do.

I thought about wiping out the drive I store my pictures on but decided that I might as well try the in-place conversion tool, btrfs-convert, which is supposed to convert EXT filesystems to BtrFS.

I first unmounted the filesystem, and then followed the recommended procedure by running the fsck utility against it. That’s supposed to ensure that the filesystem is in a consistent state before starting the conversion.

Then I ran the following command to perform the actual conversion. I didn’t use any of the options available for this command because most of them seem to be for unique or edge cases. I figured I’d go simple to start and if there were problems I could check out the options. But the conversion went well as you can see.

# btrfs-convert /dev/mapper/vg02-Pictures
btrfs-convert from btrfs-progs v6.17.1

Source filesystem:
Type:           ext2
Label:
Blocksize:      4096
UUID:           2a7ab07d-582d-4a1f-a001-53086c8dd045
Target filesystem:
Label:
Blocksize:      4096
Nodesize:       16384
UUID:           3e519ee9-360c-4398-99d5-80ea4c506355
Checksum:       crc32c
Features:       extref, skinny-metadata, no-holes, free-space-tree (default)
Data csum:    yes
Inline data:  yes
Copy xattr:   yes
Reported stats:
Total space:    500044922880
Free space:     469101375488 (93.81%)
Inode count:        30523392
Free inodes:        30516489
Block count:       122081280
Create initial btrfs filesystem
Create ext2 image file
Create btrfs metadata
Copy inodes [o] [         0/      6903]
Free space cache cleared
Conversion complete

After the conversion, I mounted the filesystem at /mnt and started a few tests to verify that it was working, which it seemed to be.

# mount /dev/mapper/vg02-Pictures -t btrfs /mnt

Some of my simple tests were just to see how the system tools view the converted filesystem. Note that lsblk still shows it as a logical volume, while adding the -f option lists all filesystem types. And it is a LVM/BtrFS filesystem That’s not an optimal setup, but it verifies for me that the actual conversion can work.

The dfc command also shows this as a BtrFS filesystem.

# lsblk
NAME            MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda               8:0    0 465.8G  0 disk
└─vg02-Pictures 252:0    0 465.7G  0 lvm  /mnt
zram0           251:0    0     8G  0 disk [SWAP]
nvme0n1         259:0    0 476.9G  0 disk
├─nvme0n1p1     259:1    0     1M  0 part
├─nvme0n1p2     259:2    0     2G  0 part /boot
└─nvme0n1p3     259:3    0 474.9G  0 part /home
                                          /

# lsblk -f
NAME            FSTYPE      FSVER    LABEL  UUID                                   FSAVAIL FSUSE% MOUNTPOINTS
sda             LVM2_member LVM2 001        lk2cd5-8df2-v1f8-CwO2-nAHe-oGUk-8sxs8i
└─vg02-Pictures btrfs                       3e519ee9-360c-4398-99d5-80ea4c506355    439.4G     6% /mnt
zram0           swap        1        zram0  a0636f66-c6f1-4feb-9b37-24dcc8e9914f                  [SWAP]
nvme0n1
├─nvme0n1p1
├─nvme0n1p2     ext4        1.0             055aba03-17f1-4cb7-92ec-3af8233bf5a4      1.3G    23% /boot
└─nvme0n1p3     btrfs                fedora 02cae19f-3e4d-479e-a0da-ffeea8afb512    467.2G     1% /home
                                                                                                  /

# dfc -T
FILESYSTEM               TYPE     (=) USED      FREE (-)  %USED AVAILABLE  TOTAL MOUNTED ON
/dev/nvme0n1p3           btrfs    [=-------------------]   1.6%    467.4G 474.9G /
devtmpfs                 devtmpfs [--------------------]   0.0%     15.6G  15.6G /dev
tmpfs                    tmpfs    [--------------------]   0.0%     15.6G  15.6G /dev/shm
tmpfs                    tmpfs    [=-------------------]   0.0%      6.2G   6.2G /run
tmpfs                    tmpfs    [--------------------]   0.0%      1.0M   1.0M +ystemd-journald.service
tmpfs                    tmpfs    [=-------------------]   0.0%     15.6G  15.6G /tmp
/dev/nvme0n1p3           btrfs    [=-------------------]   1.6%    467.4G 474.9G /home
/dev/nvme0n1p2           ext4     [======--------------]  29.2%      1.3G   1.9G /boot
tmpfs                    tmpfs    [=-------------------]   0.0%      3.1G   3.1G /run/user/980
tmpfs                    tmpfs    [=-------------------]   0.0%      3.1G   3.1G /run/user/0
+ev/mapper/vg02-Pictures btrfs    [==------------------]   5.6%    439.4G 465.7G /mnt

I unmounted the filesystem, created a new mountpoint, /var/Pictures, and added a line to /etc/fstab so that it will now mount on boot.

/dev/mapper/vg02-Pictures /var/Pictures btrfs

I use the directions in my article, How I use SSHFS to access remote filesystems, to configure both the server and the clients so that I can share these pictures to all the systems on my network.

Now that I know the conversion works, my next step is to reformat the drive to wipe out the logical volume and make it completely BtrFS. I’ll have an update for you, probably next week.

Meanwhile, I’m still concerned that it was BtrFS that borked the update.