About The Project
I’ve wanted to get more involved in the Linux kernel community, and I think building and testing Release Candidate (RC) kernels is a good way to do this. RC kernels contain new patches submitted to the upstream Linux kernel prior to the next kernel release. This is well documented in “2.1 The big picture” as follows:
The merge window lasts for approximately two weeks. At the end of this time, Linus Torvalds will declare that the window is closed and release the first of the “rc” kernels. For the kernel which is destined to be 9.x, for example, the release which happens at the end of the merge window will be called 9.x-rc1. The -rc1 release is the signal that the time to merge new features has passed, and that the time to stabilize the next kernel has begun.
My goal is to test new patches, identify potential bugs, and report them before they make it into the mainstream. A key focus of my testing is around the BTRFS file system. As mentioned in previous blog posts, I heavily use BTRFS in my doctorate research workflow so identifying bugs earlier is essential to avoiding them in my homelab. This blog post outlines that process via Arch Linux on a Framework 13 Laptop with a key focus on BTRFS regression testing.
BTRFS As The Foundation of Backups for Arch Cloud Labs
I recently migrated away from TrueNAS and ZFS in favor of Arch Linux and BTRFS. My primary motivation was to have consistency with BTRFS across my laptop, server, and now NAS.
The ability to easily snapshot and send BTRFS subvolumes to a NAS for long term storage was appealing over having split ZFS and BTRFS systems. Btbrk backs up the subvolumes as they change to external drives which can then be sent off to another location for a remote backup. The snippet below shows all /mnt/Ironwolf volumes being sent to an external drive (/mnt/backup/Ironwolf) on a regular interval set by a systemd-timer.
# Don't generate another snapshot if the subvolume hasn't changed.
snapshot_create onchange
# Keep everything created during the last 24 hours.
snapshot_preserve_min 24h
# After that retain:
# - hourly snapshots for 48 hours
# - daily snapshots for 14 days
# - weekly snapshots for 8 weeks
# - monthly snapshots for 12 months
snapshot_preserve 48h 14d 8w 12m
volume /mnt/Ironwolf
snapshot_dir .snapshots
target send-receive /mnt/backup/Ironwolf
subvolume research
subvolume org
subvolume Pictures
subvolume ghidra_projects
subvolume Development
subvolume Books
This migration now comes on the extra burden of maintaining a system. This is where the testing for BTRFS issues on emerging kernels comes into play in order to avoid historical issues123.
Quickly Building & Booting Release Candidate kernels
Arch Linux typically leverages the kernel PKGFILE for installing Linux kernels. However, “traditional” compilation, that is compilation that can be done on any Linux machine, is my preferred way. I tend to distro-hop between RHEL based systems and Arch Linux in my homelab. Having a consistent way to configure the kernel is nice, and I don’t want to switch between pkgfiles for Arch and fedpkg for Fedora. Following the typical Linux building ssteps below, I clone Linus’ upstream, checkout the tagged releaes candidate of the week, and leverage my current kernel configuration as the basis to build off of.
$> git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/ linux-torvalds-upstream` && cd ./linux-torvalds-upstream
$> git checkout v7.3-rc3
Taking a quick look at the git log, recently merged fixes, relevant hardware changes, and features can be seen in the commit messages.
Head: fd73f4a66598 Linux 7.3-rc3
Tag: v7.3-rc3
Recent commits
fd73f4a66598 @ v7.3-rc3 Linux 7.3-rc3
22098763a10d Merge tag 'trace-v7.3-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace
d681d7ef617e Merge misc regression fixes that seem to have fallen through the cracks
856c562c9496 media: ipu-bridge: do not use the CVS device lookup for IVSC
7825de3f75d1 wifi: mt76: mt792x: fix NULL dereference in ACPI SAR init during probe
1a296bfd3e77 wifi: mt76: mt7921: skip unknown CLC firmware records
d860c67c0516 ring-buffer: Check resize_disabled before publishing the new subbuf order
d059d8bf2c9b tracing/remotes: Catch nr_page_va overflow in ring_buffer_desc sizing
442ffa742daa tracing/remotes: Account for ring buffer page header in size calculation
180534c09b2d Merge tag 'rust-fixes-7.3-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ojeda/linux
The make olddefconfig command updates the current configuration (obtained via zcat /proc/config.gz > .config) with the new configurations (if applicable) setting the default values set by the developers. The following commands are run prior to building the kernel, with the additional configurations being explicitly mentioned in the BTRFS developer documentation.
$> zcat /proc/config.gz > .config # Get current kernel configuration
$> make olddefconfig # Apply default for new configuration settings
CONFIG_FAULT_INJECTION=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
CONFIG_FAIL_MAKE_REQUEST=y
CONFIG_DM_FLAKEY=m or y
CONFIG_DM_THIN_PROVISIONING=m or y
CONFIG_DM_SNAPSHOT=m or y
CONFIG_DM_DELAY=m or y
CONFIG_DM_ERROR=m or y
CONFIG_DM_LOG_WRITES=m or y
CONFIG_DM_DUST=m or y
CONFIG_DM_ZERO=m or y
CONFIG_BLK_DEV_LOOP=m or y
CONFIG_EXT4_FS=m or y
CONFIG_SCSI_DEBUG=m
CONFIG_BLK_DEV_ZONED=y for zoned mode test coverage
CONFIG_IO_URING=y
CONFIG_NUMA=y lack of get_mempolicy() syscall spills to test results
CONFIG_USER_NS=y
CONFIG_FS_VERITY_BUILTIN_SIGNATURES=y
Now, to build the kernel, and associated modules:
$> make -j$(nproc); # Use all available cores
$> sudo make modules_install
$> sudo make install
I’m currently using systemd-boot as my bootloader for my Arch Linux laptop. The make install will automatically create a boot entry. The systemd-boot command line utility “bootctl” manages the boot environment. Bootctl has a handful of useful command line flags to list available kernels and briefly booting into other kernels via bootctl set-oneshot. I think it’s easier to use than grub, but that’s just my opinion.
$> bootctl list
...truncated....
type: Boot Loader Specification Type #1 (.conf)
title: Arch Linux (7.3.0-rc3)
id: c9acc43d21f949dfa9365e4ddafec16a-7.3.0-rc3.conf # <-- use this id for set-oneshot commands
source: /boot//loader/entries/c9acc43d21f949dfa9365e4ddafec16a-7.3.0-rc3.conf (on the EFI System Partition)
sort-key: arch
version: 7.3.0-rc3
...truncated....
The Many Ways To Test
There are several different ways to test the kernel. Simply just using the RC kernel with your normal workloads can be sufficient for testing.
Some distributions have their own testing instructions. For example, Fedora has “kernel test days” which specifies how end users can fetch and build kernels that will be used in the next release or upcoming update.
The upstream Linux Kernel source has kselftest. Per the documentation:
These are intended to be small tests to exercise individual code paths in the kernel. Tests are intended to be run after building, installing and booting a kernel.
After booting into the new rc-kernel, return to the kernel git repo and execute make kselftest to begin a suite of testing of ALL the kernel tests.
A subset can be specifies via make -C tools/testing/selftests TARGETS=<SUBSYSTEM> run_tests. The subsystems are found underneath the ./tools/testing/selftests:
dllcoolj@thonkpad ~/s/l/t/t/selftests> pwd
/home/dllcoolj/src/linux-7.1.3/tools/testing/selftests
dllcoolj@thonkpad ~/s/l/t/t/selftests> ls
acct/ drivers/ kcmp/ lsm/ ntb/ rlimits/ tdx/
alsa/ dt/ kexec/ Makefile openat2/ rseq/ thermal/
amd-pstate/ efivarfs/ kho/ media_tests/ pcie_bwctrl/ rtc/ timens/
arm64/ exec/ kmod/ membarrier/ pci_endpoint/ run_kselftest.sh* timers/
bpf/ fchmodat2/ kselftest/ memfd/ perf_events/ rust/ tmpfs/
breakpoints/ filelock/ kselftest_deps.sh* memory-hotplug/ pidfd/ safesetid/ tpm2/
cachestat/ filesystems/ kselftest.h mincore/ pid_namespace/ sched/ tty/
capabilities/ firmware/ kselftest_harness/ mm/ powerpc/ sched_ext/ turbostat/
cgroup/ fpu/ kselftest_harness.h module/ power_supply/ seccomp/ ublk/
clone3/ ftrace/ kselftest_install.sh* mount/ prctl/ sgx/ uevent/
connector/ futex/ kselftest_module.h mount_setattr/ proc/ signal/ user_events/
core/ gen_kselftest_tar.sh* kvm/ move_mount_set_group/ pstore/ size/ vDSO/
coredump/ gpio/ landlock/ mqueue/ ptp/ sparc64/ verification/
cpufreq/ hid/ lib/ mseal_system_mappings/ ptrace/ splice/ vfio/
cpu-hotplug/ ia64/ lib.mk namespaces/ rcutorture/ static_keys/ vsock/
damon/ intel_pstate/ livepatch/ nci/ rdma/ sync/ watchdog/
devices/ iommu/ liveupdate/ net/ resctrl/ syscall_user_dispatch/ wireguard/
dmabuf-heaps/ ipc/ lkdtm/ nolibc/ ring-buffer/ sysctl/ x86/
dm-verity/ ir/ locking/ nsfs/ riscv/ tc-testing/ zram/
However, I am particularly interested in BTRFS testing which ksefltest does not cover.
The official BTRFS documentation recommends xfstests which despite the name actually includes tests for multiple filesystems. Their recommendation has additional notes for kernel configurations as well. These additional configuration options allow for “complete coverage” while testing BTRFS.
Some of these settings are modules that can be loaded, others have to be enabled, have the kernel be re-compiled and ultimately booted into. After configuring to your liking, testing can begin within the xfstests directory. Running the xfstests for BTRFS requires a configuration file that specifies the BTRFS block device, mount device and “dev pool” to interact with. My configuration file is set as follows with the /dev/loop devices being created from fallocate commands and provisioned via mkfs.btrfs.
#local.config
export FSTYP=btrfs
export TEST_DEV=/dev/loop1
export TEST_DIR=/tmp/test
#export SCRATCH_DEV=/dev/loop0
export SCRATCH_MNT=/tmp/scratch
export SCRATCH_DEV_POOL="/dev/loop0 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5"
Testing can begin via executing ./sudo check.
Some tests fail if specific features are not enabled in the kernel like SELinux or if there aren’t enough devices within the “SCRATCH_DEV_POOL” configuration.
dllcoolj@thonkpad ~/s/xfstests-dev ((v2026.08.17))> sudo ./check
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 thonkpad 7.3.0-rc3 #1 SMP PREEMPT_DYNAMIC Wed Sep 16 19:31:24 EDT 2026
MKFS_OPTIONS -- /dev/loop0
MOUNT_OPTIONS -- /dev/loop0 /tmp/scratch
btrfs/001 1s ... 1s
btrfs/002 4s ... 4s
btrfs/003 [not run] this test requires a valid $SCRATCH_DEV_POOL
btrfs/004 17s
btrfs/005 6s
btrfs/006 [not run] this test requires a valid $SCRATCH_DEV_POOL
btrfs/007 1s
btrfs/008 1s
btrfs/009 0s
...truncated...
These BTRFS tests are all bash scripts that perform a set of file system operations. As an example btrfs/001 performs routine snapshotting, subvolume, and file system creation.
# First test basic snapshotting
echo "Creating file foo in root dir"
dd if=/dev/zero of=$SCRATCH_MNT/foo bs=1M count=1 &> /dev/null
echo "List root dir"
ls $SCRATCH_MNT
echo "Creating snapshot of root dir"
_btrfs subvolume snapshot $SCRATCH_MNT $SCRATCH_MNT/snap
echo "List root dir after snapshot"
ls $SCRATCH_MNT
echo "List snapshot dir"
ls $SCRATCH_MNT/snap
rm -f $SCRATCH_MNT/foo
echo "List root dir after rm of foo"
ls $SCRATCH_MNT
echo "List snapshot dir"
ls $SCRATCH_MNT/snap
# Test creating a normal subvolme
$BTRFS_UTIL_PROG subvolume create $SCRATCH_MNT/subvol | _filter_scratch
echo "Listing root dir"
ls $SCRATCH_MNT
echo "Listing subvol"
ls $SCRATCH_MNT/subvol
After tests are complete, dumping the dmesg buffer to examine failures, warnings and other errors will help identify bugs.
Note that some tests are meant to fail, so just inherently seeing warnings may be fine.
[ 1216.789834] BTRFS info (device loop1): enabling free space tree
[ 1216.879356] run fstests btrfs/295 at 2026-09-20 21:16:34
[ 1217.225032] BTRFS: device fsid 3b8581a4-94e0-41e3-a225-889e9e650441 devid 1 transid 8 /dev/loop0 (7:0) scanned by mount (822025)
[ 1217.225435] BTRFS info (device loop0): first mount of filesystem 3b8581a4-94e0-41e3-a225-889e9e650441
[ 1217.225442] BTRFS info (device loop0): using crc32c checksum algorithm
[ 1217.227223] BTRFS warning (device loop0): checksum verify failed on logical 5242880 mirror 1 wanted 0x00000000 found 0x6969acda level 0
[ 1217.227238] BTRFS warning (device loop0): couldn't read tree root
[ 1217.227457] BTRFS error (device loop0): open_ctree failed: -EIO
[ 1217.306112] BTRFS info (device loop1): last unmount of filesystem 3ff6fe6f-9203-409a-951a-14be611848d3
[ 1217.369748] run fstests btrfs/296 at 2026-09-20 21:16:35
[ 1217.591500] BTRFS: device fsid 3ff6fe6f-9203-409a-951a-14be611848d3 devid 1 transid 170 /dev/loop1 (7:1) scanned by mount (822263)
[ 1217.592295] BTRFS info (device loop1): first mount of filesystem 3ff6fe6f-9203-409a-951a-14be611848d3
[ 1217.592301] BTRFS info (device loop1): using crc32c checksum algorithm
[ 1217.594705] BTRFS info (device loop1): enabling ssd optimizations
[ 1217.594709] BTRFS info (device loop1): turning on async discard
[ 1217.594710] BTRFS info (device loop1): enabling free space tree
For failures, you’ll have messages from the test suite get printed like below. Here there’s an issue where the output that was expected was not found, thus the test has failed. In this case, it was due to a test disk created via falloc not being appropriately mounted, and not an actual issue in upstream BTRFS itself.
btrfs/003 5s ... [failed, exit status 1]- output mismatch (see /home/dllcoolj/src/xfstests-dev/results//btrfs/003.out.bad)
--- tests/btrfs/003.out 2026-09-20 20:12:55.128819493 -0400
+++ /home/dllcoolj/src/xfstests-dev/results//btrfs/003.out.bad 2026-09-22 20:38:20.426963963 -0400
@@ -1,2 +1,3 @@
QA output created by 003
-Silence is golden
+mkfs failed
+(see /home/dllcoolj/src/xfstests-dev/results//btrfs/003.full for details)
...
(Run 'diff -u /home/dllcoolj/src/xfstests-dev/tests/btrfs/003.out /home/dllcoolj/src/xfstests-dev/results//btrfs/003.out.bad' to see the entire diff)
Additionally I have configured my RC kernel with KASAN , and am inspecting dmesg for any output that might indicate a regression in the BTRFS support for a kernel.
However, the errors below are actually intentional as test 100 assesses for errors. It’s important to review the tests that fail to understand if it was intentional or if an actual bug has been found.
dllcoolj@thonkpad ~/s/xfstests-dev ((v2026.08.17)) [SIGINT]> sudo dmesg | grep -i error
[sudo] password for dllcoolj:
[ 1321.085268] BTRFS: device fsid 53628c66-ebce-4369-a580-ae169272bd77 devid 2 transid 8 /dev/mapper/error-test.100 (253:2) scanned by mkfs.btrfs (3
03145)
[ 1326.274695] Buffer I/O error on dev dm-2, logical block 0, async page read
[ 1326.274867] Buffer I/O error on dev dm-2, logical block 0, async page read
[ 1326.445872] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 1, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445888] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 2, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445910] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 3, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445927] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445929] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 5, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445938] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 6, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445947] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 7, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445955] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 8, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445958] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 9, rd 0, flush 0, corrupt 0, gen 0
[ 1326.445961] BTRFS error (device loop3): bdev /dev/mapper/error-test.100 errs: wr 10, rd 0, flush 0, corrupt 0, gen 0
[ 1326.455845] BTRFS warning (device loop3): lost super block write due to IO error on /dev/mapper/error-test.100 (-5)
Reviewing Completed Cases
The results of testing are stored within the xfstests’ “results” directory and the failed tests can be inspected to understand the underlying issues.
Kernel version: 7.3.0-rc3
Tue Sep 22 21:27:01 EDT 2026
Ran: btrfs/001 btrfs/002 btrfs/003 btrfs/004 btrfs/005 btrfs/006 btrfs/007 btrfs/008 btrfs/009 btrfs/010 btrfs/011 btrfs/012 btrfs/013 btrfs/014 btrfs/015 btrfs/016 btrfs/017 btrfs/018 btrfs/019 btrfs/020 btrfs/021 btrfs/022 btrfs/023 btrfs/024 btrfs/025 btrfs/026 btrfs/027 btrfs/028 btrfs/029 btrfs/030 btrfs/031 btrfs/032 btrfs/033 btrfs/034 btrfs/035 btrfs/036 btrfs/037 btrfs/038 btrfs/039 btrfs/040 btrfs/041 btrfs/042 btrfs/043 btrfs/044 btrfs/045 btrfs/046 btrfs/047 btrfs/048 btrfs/049 btrfs/050 btrfs/051 btrfs/052 btrfs/053 btrfs/054 btrfs/055 btrfs/056 btrfs/057 btrfs/058 btrfs/059 btrfs/060 btrfs/061 btrfs/062 btrfs/063 btrfs/064 btrfs/065 btrfs/066 btrfs/067 btrfs/068 btrfs/069 btrfs/070 btrfs/071 btrfs/072 btrfs/073 btrfs/074 btrfs/075 btrfs/076 btrfs/077 btrfs/078 btrfs/079 btrfs/080 btrfs/081 btrfs/082 btrfs/083 btrfs/084 btrfs/085 btrfs/086 btrfs/087 btrfs/088 btrfs/089 btrfs/090 btrfs/091 btrfs/092 btrfs/093 btrfs/094 btrfs/095 btrfs/096 btrfs/097 btrfs/098 btrfs/099 btrfs/100 btrfs/101 btrfs/102 btrfs/103 btrfs/104 btrfs/105 btrfs/106 btrfs/107 btrfs/108 btrfs/109 btrfs/110 btrfs/111 btrfs/112 btrfs/113 btrfs/114 btrfs/115 btrfs/116 btrfs/117 btrfs/118 btrfs/119 btrfs/120 btrfs/121 btrfs/122 btrfs/123 btrfs/124 btrfs/125 btrfs/126 btrfs/127 btrfs/128 btrfs/129 btrfs/130 btrfs/131 btrfs/132 btrfs/133 btrfs/134 btrfs/135 btrfs/136 btrfs/137 btrfs/138 btrfs/139 btrfs/140 btrfs/141 btrfs/142 btrfs/143 btrfs/144 btrfs/145 btrfs/146 btrfs/147 btrfs/148 btrfs/149 btrfs/150 btrfs/151 btrfs/152 btrfs/153 btrfs/154 btrfs/155 btrfs/156 btrfs/157 btrfs/158 btrfs/159 btrfs/160 btrfs/161 btrfs/162 btrfs/163 btrfs/164 btrfs/165 btrfs/166 btrfs/167 btrfs/168 btrfs/169 btrfs/170 btrfs/171 btrfs/172 btrfs/173 btrfs/174 btrfs/175 btrfs/176 btrfs/177 btrfs/178 btrfs/179 btrfs/180 btrfs/181 btrfs/182 btrfs/183 btrfs/184 btrfs/185 btrfs/186 btrfs/187 btrfs/188 btrfs/189 btrfs/190 btrfs/191 btrfs/192 btrfs/193 btrfs/194 btrfs/195 btrfs/196 btrfs/197 btrfs/198 btrfs/199 btrfs/200 btrfs/201 btrfs/202 btrfs/203 btrfs/204 btrfs/205 btrfs/206 btrfs/207 btrfs/208 btrfs/209 btrfs/210 btrfs/211 btrfs/212 btrfs/213 btrfs/214 btrfs/215 btrfs/216 btrfs/217 btrfs/218 btrfs/219 btrfs/220 btrfs/221 btrfs/222 btrfs/223 btrfs/224 btrfs/225 btrfs/226 btrfs/227 btrfs/228 btrfs/229 btrfs/230 btrfs/231 btrfs/232 btrfs/233 btrfs/234 btrfs/235 btrfs/236 btrfs/237 btrfs/238 btrfs/239 btrfs/240 btrfs/241 btrfs/242 btrfs/243 btrfs/244 btrfs/245 btrfs/246 btrfs/247 btrfs/248 btrfs/249 btrfs/250 btrfs/251 btrfs/252 btrfs/253 btrfs/254 btrfs/255 btrfs/256 btrfs/257 btrfs/258 btrfs/259 btrfs/260 btrfs/261 btrfs/262 btrfs/263 btrfs/264 btrfs/265 btrfs/266 btrfs/267 btrfs/268 btrfs/269 btrfs/270 btrfs/271 btrfs/272 btrfs/273 btrfs/274 btrfs/275 btrfs/276 btrfs/277 btrfs/278 btrfs/279 btrfs/280 btrfs/281 btrfs/282 btrfs/283 btrfs/284 btrfs/285 btrfs/286 btrfs/287 btrfs/288 btrfs/289 btrfs/290 btrfs/291 btrfs/292 btrfs/293 btrfs/294 btrfs/295 btrfs/296 btrfs/297 btrfs/298 btrfs/299 btrfs/300 btrfs/301 btrfs/302 btrfs/303 btrfs/304 btrfs/305 btrfs/306 btrfs/307 btrfs/308 btrfs/309 btrfs/310 btrfs/311 btrfs/312 btrfs/313 btrfs/314 btrfs/315 btrfs/316 btrfs/317 btrfs/318 btrfs/319 btrfs/320 btrfs/321 btrfs/322 btrfs/323 btrfs/324 btrfs/325 btrfs/326 btrfs/327 btrfs/328 btrfs/329 btrfs/330 btrfs/331 btrfs/332 btrfs/333 btrfs/334 btrfs/335 btrfs/336 btrfs/337 btrfs/338 btrfs/339 btrfs/340 btrfs/341 btrfs/342 btrfs/343 btrfs/344 btrfs/345 btrfs/346 btrfs/347 btrfs/348 btrfs/349 btrfs/350 btrfs/351 btrfs/352 btrfs/353
Not run: btrfs/011 btrfs/027 btrfs/064 btrfs/065 btrfs/069 btrfs/070 btrfs/071 btrfs/075 btrfs/079 btrfs/131 btrfs/167 btrfs/172 btrfs/190 btrfs/192 btrfs/196 btrfs/206 btrfs/237 btrfs/253 btrfs/273 btrfs/277 btrfs/290 btrfs/291 btrfs/292 btrfs/294 btrfs/301 btrfs/304 btrfs/305 btrfs/306 btrfs/307 btrfs/308 btrfs/317
Failures: btrfs/003 btrfs/006 btrfs/023 btrfs/060 btrfs/061 btrfs/062 btrfs/063 btrfs/066 btrfs/067 btrfs/068 btrfs/072 btrfs/073 btrfs/074 btrfs/090 btrfs/146 btrfs/160 btrfs/175 btrfs/179 btrfs/197 btrfs/207 btrfs/286 btrfs/321 btrfs/326 btrfs/327 btrfs/328 btrfs/329 btrfs/330 btrfs/331 btrfs/332 btrfs/333 btrfs/334 btrfs/335 btrfs/336 btrfs/337 btrfs/338 btrfs/339 btrfs/340 btrfs/341 btrfs/342 btrfs/343 btrfs/344 btrfs/345 btrfs/346 btrfs/347 btrfs/348 btrfs/349 btrfs/350 btrfs/351 btrfs/352 btrfs/353
Failed 50 of 353 tests
A significant number of the later failures stem from issues with the volumes being mounted incorrectly. However, there were no indiciations of BTRFS support issues in the version of the release kernel that I am currently running.
...truncated...
/dev/loop0 /tmp/test/subvol2_mount /dev/loop0 /tmp/test/subvol2_mount
QA output created by 350
SCRATCH_DEV=/dev/loop0 is mounted but not on SCRATCH_MNT=/tmp/scratch - aborting
Already mounted result:
/dev/loop0 /tmp/test/subvol2_mount /dev/loop0 /tmp/test/subvol2_mount
QA output created by 351
SCRATCH_DEV=/dev/loop0 is mounted but not on SCRATCH_MNT=/tmp/scratch - aborting
Already mounted result:
/dev/loop0 /tmp/test/subvol2_mount /dev/loop0 /tmp/test/subvol2_mount
QA output created by 352
...truncated...
Upon re-mounting and re-executing the previously failed tests, there were no issues observed. At this point no regression bugs have been identified, thus I can comfortable plan an upgrade for my NAS for the next kernel release, post RC testing.
Conclusion
Diving into building and testing kernel features or subsystems is a great way to gain the depth necessary to contribute back upstream. In my case it also exposed to me to various mailing lists and testing frameworks that I otherwise would not have encountered. Since moving pivoting my NAS from FreeBSD with ZFS to Linux with BTRFS, the additional in-depth background on how to test BTRFS with new kernels is becoming more critical. By having an actual reason to study this in-depth outside of my research projects into kernel and file system testing, it gives a deeper sense of ownership of my entire homelab stack.
Thank you for reading!
glibc Fix for Building xfstests
The current version of glibc has a bug with xfstests, and a small fix is necessary.