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 !
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: