Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

prtigger1 · Jan 9th 2026

Hi folks

I find a fundamental degraded Btrfs performance (srub+filesystem write) with the bpo kernel 6.17.13. Compared with the stable 6.12.57 kernel

on my Supermicro server. No change on system, just change the boot kernel in Grub. Filesystem is a Btrfs raid 1 over 3 Samsung SSDs

Scrub with 6.17.13:

Code

root@pr-srv-01:~# btrfs scrub start -B -d /srv/dev-disk-by-uuid-a8a06053-0cc4-491d-adf2-01bb8a02fb44
Starting scrub on devid 1
Starting scrub on devid 2
Starting scrub on devid 3

Scrub device /dev/sdc (id 1) done
Scrub started:    Thu Jan  8 21:26:19 2026
Status:           finished
Duration:         1:07:10
Total to scrub:   456.26GiB
Rate:             115.93MiB/s
Error summary:    no errors found

Scrub device /dev/sdb (id 2) done
Scrub started:    Thu Jan  8 21:26:19 2026
Status:           finished
Duration:         1:07:15
Total to scrub:   457.12GiB
Rate:             116.01MiB/s
Error summary:    no errors found

Scrub device /dev/sdd (id 3) done
Scrub started:    Thu Jan  8 21:26:19 2026
Status:           finished
Duration:         1:07:10
Total to scrub:   455.78GiB
Rate:             115.81MiB/s
Error summary:    no errors found
root@pr-srv-01:~#

Display More

Scrub with 6.12.57

Code

root@pr-srv-01:~# btrfs scrub start -B -d /srv/dev-disk-by-uuid-a8a06053-0cc4-491d-adf2-01bb8a02fb44
Starting scrub on devid 1
Starting scrub on devid 2
Starting scrub on devid 3

Scrub device /dev/sdc (id 1) done
Scrub started:    Fri Jan  9 07:29:23 2026
Status:           finished
Duration:         0:33:00
Total to scrub:   457.41GiB
Rate:             236.56MiB/s
Error summary:    no errors found

Scrub device /dev/sda (id 2) done
Scrub started:    Fri Jan  9 07:29:23 2026
Status:           finished
Duration:         0:32:42
Total to scrub:   457.66GiB
Rate:             238.86MiB/s
Error summary:    no errors found

Scrub device /dev/sdd (id 3) done
Scrub started:    Fri Jan  9 07:29:23 2026
Status:           finished
Duration:         0:33:46
Total to scrub:   456.39GiB
Rate:             230.67MiB/s
Error summary:    no errors found
root@pr-srv-01:~#

Display More

That´s double time for exact the same Btrfs data filesystem!

Copying a large file from Windows 11 client to the Samba share is slower,too. But not that much.

At this time, no idea what changed in Btrfs kernel driver, but on my old dual core Intel Atom D510 server, this is bad stuff with 6.17.13.

If anybody noticed identical performance issues, please keep me informed.

Ideas welcome!

Best regards

prtigger

ryecoaaron · Jan 10th 2026

Quote from prtigger1

At this time, no idea what changed in Btrfs kernel driver, but on my old dual core Intel Atom D510 server, this is bad stuff with 6.17.13.

Newer kernels are usually likely to be better optimized on recent hardware. Your D510 is 17 years old.

prtigger1 · Jan 10th 2026

Hi Aaron

That's a possible explanation...

The load is higher and the cache usage is

lower during scrub. That's what i can see.

The scrub time difference is massive...

Normally my system is performing pretty

well with the older kernel...

If there is any way to optimize this bad behavior, i don't know at this time.

Switching to other file system may be the

last step...

That's the actual status...

Thank's and best regards

prtigger

ryecoaaron · Jan 10th 2026

On a system that old, there is little reason to use the newer kernel. I am curious if you see the same results with the 6.14 and 6.17 proxmox kernel.

prtigger1 · Jan 10th 2026

ryecoaaron

Exact this was my idea today!

I disabled backports, cleaned up the kernel stuff and repos. Installed the lastest 6.12.63 kernel meta package...

After that, i installed the 6.17.4-2-pve kernel... I've both kernel to start.

First test (Writing 1.8GB file to Samba share): PVE Kernel is slower than Debian bpo 6.17.13 kernel, yesterday.

Compared to actual 6.12.63, the write performace is more than 20% slower... Worse!!

Btrfs scrub is just running for 41 minutes...

By the way, if the settings in:

/etc/sysctl.d/99-openmediavault-nonrot.conf

are useful for my hardware, i had not fully checked at this time... (-nonrot stands for ???)

I`ve got an extra conf file, optimized for my network stack.

At this time i override laptop.mode = 0 (Changed yesterday, after i post the information here)

But both kernels run with this settings...

Best regards

prtigger

Best regards

prtigger

prtigger1 · Jan 10th 2026

The scrub is only a little bit slower than with 6.17.13 bpo:

Code

Linux pr-srv-01 6.17.4-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.17.4-2 (2025-12-19T07:49Z) x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Jan 10 20:08:13 2026 from 192.168.150.100
root@pr-srv-01:~#
root@pr-srv-01:~# btrfs scrub start -B -d /srv/dev-disk-by-uuid-a8a06053-0cc4-491d-adf2-01bb8a02fb44
Starting scrub on devid 1
Starting scrub on devid 2
Starting scrub on devid 3

Scrub device /dev/sdc (id 1) done
Scrub started:    Sat Jan 10 20:17:48 2026
Status:           finished
Duration:         1:08:31
Total to scrub:   457.41GiB
Rate:             113.94MiB/s
Error summary:    no errors found

Scrub device /dev/sdb (id 2) done
Scrub started:    Sat Jan 10 20:17:48 2026
Status:           finished
Duration:         1:08:29
Total to scrub:   457.66GiB
Rate:             114.05MiB/s
Error summary:    no errors found

Scrub device /dev/sdd (id 3) done
Scrub started:    Sat Jan 10 20:17:48 2026
Status:           finished
Duration:         1:08:27
Total to scrub:   456.39GiB
Rate:             113.79MiB/s
Error summary:    no errors found
root@pr-srv-01:~#

Display More

Best regards

prtigger

ryecoaaron · Jan 10th 2026

Quote from prtigger1

-nonrot stands for ???)

non-rotational. So, an ssd/usb stick/sd, etc

prtigger1 · Jan 10th 2026

ryecoaaron

Hi Aaron

Thank's for that info...

Is is possible to deactivate the

99-openmediavault*.conf files persistant?

Where are they generated?

I should not change this files, so

i have to add an extra file with overrides and

additions.

Best regards

prtigger

ryecoaaron · Jan 11th 2026

Quote from prtigger1

Is is possible to deactivate the
99-openmediavault*.conf files persistant?

Those files are written by omv's saltstack. But you can change the values in environment variables - https://github.com/openmediava…loy/sysctl/nonrot.sls#L26

Or you could create a file without openmediavault in the name and as long as it sorts alphanumerically after 99-openmediavault, it will override the value in the omv files.

prtigger1 · Jan 11th 2026

ryecoaaron

Hi Aaron

Thank you, i just realized, that these settings

exists for longer time and aren't new with

OMV 8.

Never noticed that before, because i was focused

on /etc/sysctl.conf...

But it's not to late to keep an eye on the

default changes...

I guess that will not fix the performance

problem with my Btrfs storage...

I decide to stay with the very good performing

6.12.xx stable kernel, until a newer backport

kernel is coming up. 6.17.13 is EOL right now.

Best regards

Prtigger

ryecoaaron · Jan 11th 2026

6.18.3 is in the unstable repo now. It shouldn't be long before it is in backports.

prtigger1 · Jan 11th 2026

This may be the next LTS kernel...

Lower Btrfs scrub and file system write performance with backport kernel 6.17.13, compared to stable trixie kernel 6.12.57

prtigger1 Jan 9th 2026

Participate now!