{"id":12582,"date":"2025-11-20T01:03:00","date_gmt":"2025-11-20T06:03:00","guid":{"rendered":"https:\/\/www.both.org\/?p=12582"},"modified":"2026-01-20T13:27:53","modified_gmt":"2026-01-20T18:27:53","slug":"converting-to-btrfs-episode-2","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=12582","title":{"rendered":"Converting to BtrFS — Episode 2"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

I mentioned in Episode 1<\/a>, that I was going to start my conversion of at least a few of my physical systems to BtrFS by testing on a VM, but I decided there’s not really any point to that. A simple VM with no real work to do is a crap test. Besides, I do have a system sitting there, doing almost nothing. Well, except for serving our family pictures to the other systems on my network. That’s another story<\/a>, but it’s part of my long-term testing strategy.<\/p>\n\n\n\n

The system I chose is bunkerhill and it has a decent set of specs as you can see in Figure 1. With an Intel i9, 8 core and 16 CPUs at nearly 5GHz, and 32GB of RAM. It’s a fast system with lots of resources.<\/p>\n\n\n\n

#######################################################################\n# MOTD for Tue Nov 18 05:24:03 PM EST 2025\n# HOST NAME:            bunkerhill.both.org\n# Machine Type:         physical machine.\n# Host architecture:    X86_64\n#----------------------------------------------------------------------\n# System Serial No.:    Default string\n# System UUID:          3b702977-a782-a01e-a08f-2cf05d26c209\n# Motherboard Mfr:      Micro-Star International Co., Ltd.\n# Motherboard Model:    Z390-A PRO (MS-7B98)\n# Motherboard Serial:   K316882609\n# BIOS Release Date:    12\/25\/2019\n#----------------------------------------------------------------------\n# CPU Model:            Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz\n# CPU Data:             1 Eight Core package with 16 CPUs\n# CPU Architecture:     x86_64\n# HyperThreading:       Yes\n# Max CPU MHz:          5000.0000\n# Current CPU MHz:      4699.956\n# Min CPU MHz:          800.0000\n#----------------------------------------------------------------------\n# RAM:                  31.209 GB\n# SWAP:                 7.999 GB\n#----------------------------------------------------------------------\n# Install Date:         Wed 22 Oct 2025 11:50:12 PM EDT\n# Linux Distribution:   Fedora 43 (Forty Three) X86_64\n# Kernel Version:       6.17.7-300.fc43.x86_64\n#----------------------------------------------------------------------\n# Disk Partition Info\n# Filesystem      Size  Used Avail Use% Mounted on\n# \/dev\/nvme0n1p3  475G   10G  464G   3% \/\n# \/dev\/nvme0n1p3  475G   10G  464G   3% \/home\n# \/dev\/nvme0n1p2  2.0G  450M  1.4G  25% \/boot\n#----------------------------------------------------------------------\n# LVM Physical Volume Info\n# PV            VG              Fmt     Attr    PSize   PFree\n# \/dev\/sda      vg02    lvm2    a--     <465.76g        56.00m\n#######################################################################\n# Note: This MOTD file gets updated automatically every day.\n#       Changes to this file will be automatically overwritten!\n#######################################################################<\/code><\/pre>\n\n\n\n
Figure 1: My BtrFS test system has an excellent set of specs for this project.<\/p>\n\n\n\n
This system also has a hard drive that I use for storing and serving my family pictures. It will make a good test bed.<\/p>\n\n\n\n
The current test<\/h2>\n\n\n\n
I recently found a new way to stress-test my Linux hosts and this is a perfect example of how the stress<\/a> command can be used. I wanted to make this test realistic while concentrating on I\/O and the storage device, in this case, a 500GB NVMe device. In addition to the I\/O test, I’m also stressing the CPUs to about 67%. <\/p>\n\n\n\n
I used the command in Figure 2 to launch stress<\/strong>. The -c option specifies 10 CPU worker threads, -i spawns 8 I\/O threads which simply flush the buffers to disk, and -d launches 15 disk worker threads to maintain a high level of activity. Overall disk I\/O is running at about 95 percent. <\/p>\n\n\n\n
# stress -c 10 -i 8 -d 15 -v<\/strong><\/code><\/pre>\n\n\n\n
Figure 2: The command I used for stress testing BtrFS on my system.<\/p>\n\n\n\n
The -v (verbose) option causes stress<\/strong> to display the status messages seen in the right pane of the Konsole<\/a> window in Figure 3. The left pane in Figure 3 is the system monitor btop, which I like because it shows a graphical representation of the system resource usage over time. This gives an excellent picture of recent events in the system. <\/p>\n\n\n\n
\"\"<\/a>
Figure 3: Testing my BtrFS system using the stress<\/strong> command line utility. Click the image to enlarge for more detail.<\/figcaption><\/figure>\n\n\n\n
You can see in Figure 3, the CPU and disk I\/O loads in more detail if you click on the image to enlarge it. <\/p>\n\n\n\n
I plan to continue this stress test for about a week.<\/p>\n\n\n\n
Next steps in the test plan<\/h2>\n\n\n\n
You may notice the LVM data for \/dev\/sda near the bottom of Figure 1. That’s the device that contains my pictures. After I’ve run this basic test for a few more days, I’ll convert it to BtrFS using the btrfs-convert<\/strong> tool. Then after a few more days of heavy testing, I’ll wipe out that sda device, convert it to BtrFS on a Linux type 83 partition, and test some more. I’m already keeping a good set of multiple backups of my data so I can revert to LVM\/EXT4 and restore at any time.<\/p>\n\n\n\n
Then I’ll move on to creating subvolumes. One step at a time for critical new things like filesystems.<\/p>\n\n\n\n
\n\n\n\n
The Full Series<\/h2>\n\n\n\n