kernel 7.0 performance issue with zfs pools

Dec 2, 2025
3
1
3
Hello

I wish to report a drastic loss of performance with the 7.0 kernel as soon as it implies operating with zfs pools.

I run 2 of these, one is a single raidz2 array of 12 4TB sas hard disks, the other has 2 raidz2 arrays of 8 600GB sas hard drives and each is available to the backup server as a separate datastore. The server itself if grately overpowered with 16 cores, 130GB ram, 10GB ethernets and SSD mirrors for the system as well as the contents of the datastore namespaces (through symlinks rather direct than zfs cross mounts)

the upgrade to the 7.0 kernel made pbs verifications and garbage collecting take 3 to as much as 4 time as long as they used to, partly because the two mentionned operations were now running concurrently rather than during separated timeframes.

next the release of the first bugfix to the 7.0 kernel didn't address the problem so once I figured its origin (I must admit I was quite careless while proceding to the previous one without carefully checking the release notes, my bad) I switched back to the 6.17 kernel and now my backup server is back to its previous operationnal health.

ah about this maybe you also need to know that the zfs pools themselves haven't been upgraded to the current version shipped with the 4.0 pbs release and is still as the PBS 3 created them the reason for this beeing that the most valuable datastore is replicated using zfs snapshots and send/recv process on a remote installation still running a debian 12.5 runnng zfs 2.1.11 that we wish to fully upgrade before we do the same on the backup server. actually the full plan is even to install the proxmox backup server on that one as well and switch to PBS syncs rather than zfs transfers but that ain't the question of the thread.

I fiirst started searching the forums in order to see if someone else experienced and reported a similar issue but found nothing, but if I once again missed something I'd be glad to contribute there rather than in this new one and/or provide additionnal information if asked to.

best reagards !
 
Last edited:
I confirm the above.

Server:
40 x Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz (2 Sockets)
32G RAM
raid10 3 mirror

Stored data 40Tb

On the kernel 6.17.13 GC time was 3-4 hours
On the kernel 7.0.2 GC more than a day, up to two days

The RAM usage graph also shows that the system is not using as much memory as before.
1780134850046.png
1780134883675.png

kernel 7.0.6-2-pve

2026-05-30T11:19:51+05:00: starting garbage collection on store basket
2026-05-30T11:19:52+05:00: Access time update check successful, proceeding with GC.
2026-05-30T11:19:52+05:00: Using access time cutoff 1d 5m, minimum access time is 2026-05-29T06:14:51Z
2026-05-30T11:19:52+05:00: Start GC phase1 (mark used chunks)
2026-05-30T11:36:02+05:00: marked 1% (12 of 1165 index files)
2026-05-30T11:43:23+05:00: marked 2% (24 of 1165 index files)
2026-05-30T11:47:14+05:00: marked 3% (35 of 1165 index files)
2026-05-30T11:48:28+05:00: marked 4% (47 of 1165 index files)
2026-05-30T11:53:14+05:00: marked 5% (59 of 1165 index files)
2026-05-30T11:56:25+05:00: marked 6% (70 of 1165 index files)
2026-05-30T12:05:25+05:00: marked 7% (82 of 1165 index files)
2026-05-30T12:08:20+05:00: marked 8% (94 of 1165 index files)
2026-05-30T12:13:05+05:00: marked 9% (105 of 1165 index files)
2026-05-30T12:16:23+05:00: marked 10% (117 of 1165 index files)
2026-05-30T12:18:48+05:00: marked 11% (129 of 1165 index files)
2026-05-30T12:27:05+05:00: marked 12% (140 of 1165 index files)
2026-05-30T12:28:07+05:00: marked 13% (152 of 1165 index files)
2026-05-30T12:30:23+05:00: marked 14% (164 of 1165 index files)
2026-05-30T12:33:41+05:00: marked 15% (175 of 1165 index files)
2026-05-30T12:34:10+05:00: marked 16% (187 of 1165 index files)
2026-05-30T14:17:51+05:00: marked 17% (199 of 1165 index files)

kernel 6.17.13-13-pve

2026-05-30T15:02:08+05:00: starting garbage collection on store basket
2026-05-30T15:02:09+05:00: Access time update check successful, proceeding with GC.
2026-05-30T15:02:09+05:00: Using access time cutoff 1d 5m, minimum access time is 2026-05-29T09:57:08Z
2026-05-30T15:02:09+05:00: Start GC phase1 (mark used chunks)
2026-05-30T15:20:37+05:00: marked 1% (12 of 1165 index files)
2026-05-30T15:28:57+05:00: marked 2% (24 of 1165 index files)
2026-05-30T15:33:15+05:00: marked 3% (35 of 1165 index files)
2026-05-30T15:34:39+05:00: marked 4% (47 of 1165 index files)
2026-05-30T15:39:58+05:00: marked 5% (59 of 1165 index files)
2026-05-30T15:43:33+05:00: marked 6% (70 of 1165 index files)
2026-05-30T15:53:24+05:00: marked 7% (82 of 1165 index files)
2026-05-30T15:56:36+05:00: marked 8% (94 of 1165 index files)
2026-05-30T16:01:24+05:00: marked 9% (105 of 1165 index files)
2026-05-30T16:04:57+05:00: marked 10% (117 of 1165 index files)
2026-05-30T16:07:23+05:00: marked 11% (129 of 1165 index files)
2026-05-30T16:15:49+05:00: marked 12% (140 of 1165 index files)
2026-05-30T16:16:46+05:00: marked 13% (152 of 1165 index files)
2026-05-30T16:18:58+05:00: marked 14% (164 of 1165 index files)
2026-05-30T16:22:05+05:00: marked 15% (175 of 1165 index files)
2026-05-30T16:22:30+05:00: marked 16% (187 of 1165 index files)
2026-05-30T16:40:35+05:00: marked 17% (199 of 1165 index files)
 
Last edited:
Same here, garbage_collection tasks are (much) slower with 7.0.2-6 than with 6.17.13-11.
Fastest verification on 7.0 kernel (6h35) is slower than slowest verification on 6.17 kernel (4h15).


Christophe.