zfs-2.4.2 patchset - #18462
Merged
tonyhutter merged 76 commits intoMay 12, 2026
Merged
Conversation
Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes openzfs#18077
Sponsored-by: https://despairlabs.com/sponsor/ Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Rob Norris <robn@despairlabs.com> Closes openzfs#18077
The upcoming 7.0 kernel will no longer fall back to generic_setlease(), instead returning EINVAL if .setlease is NULL. So, we set it explicitly. To ensure that we catch any future kernel change, adds a sanity test for F_SETLEASE and F_GETLEASE too. Since this is a Linux-specific test, also a small adjustment to the test runner to allow OS-specific helper programs. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18215
On systems where `$kernelsrc` is different than `$kernelbuild`, the objtool binary will be located in `$kernelbuild` as it's the result of running `make prepare` during kernel build. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Attila Fülöp <attila@fueloep.org> Signed-off-by: Louis Leseur <louis.leseur@gmail.com> Closes openzfs#18248 Closes openzfs#18249
It does exactly the same thing, just inverts the return. Detect its presence or absence and call the right one. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18216
Kernel devs noted that almost all callers to posix_acl_to_xattr() would check the ACL value size and allocate a buffer before make the call. To reduce the repetition, they've changed it to allocate this buffer internally and return it. Unfortunately that's not true for us; most of our calls are from xattr_handler->get() to convert a stored ACL to an xattr, and that call provides a buffer. For now we have no other option, so this commit detects the new version and wraps to copy the value back into the provided buffer and then free it. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18216
The traditional mount API has been removed, so detect when its not available and instead use a small adapter to allow our existing mount functions to keep working. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18216
Fedora 41 was deprecated on Dec 15 2025. Remove it from CI tests. Reviewed-by: Rob Norris <robn@despairlabs.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#18261
This API has been available since kernel 5.2, and having it available (almost) everywhere should give us a lot more flexibility for mount management in the future. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18260
Checking for LD_VERSION in unreliable as not all distros define it on the compiler's preprocessor. Explicitly check it via autoconf. This fixes support for Ubuntu 18.04 on arm64. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Juhyung Park <qkrwngud825@gmail.com> Closes openzfs#18262
Provide intuitive log search keywords and increased system consistency. Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Signed-off-by: Alexander Ziaee <ziaee@FreeBSD.org> Closes openzfs#18290
When a namespace property is changed via zfs set, libzfs remounts the filesystem to propagate the new VFS mount flags. The current approach uses mount(2) with MS_REMOUNT, which reads all namespace properties from ZFS and applies them together. This has two problems: 1. Linux VFS resets unspecified per-mount flags on remount. If an administrator sets a temporary flag (e.g. mount -o remount,noatime), a subsequent zfs set on any namespace property clobbers it. 2. Two concurrent zfs set operations on different namespace properties can overwrite each other's mount flags. Additionally, legacy datasets (mountpoint=legacy) were never remounted on namespace property changes since zfs_is_mountable() returns false for them. Add zfs_mount_setattr() which uses mount_setattr(2) to selectively update only the mount flags that correspond to the changed property. For legacy datasets, /proc/mounts is iterated to update all mountpoints. On kernels without mount_setattr (ENOSYS), non-legacy datasets fall back to a full remount; legacy mounts are skipped to avoid clobbering temporary flags. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> Closes openzfs#18257
The autoconf checks are more than enough to decide whether or not we can work with this kernel or not. Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18295
Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18295
vdev_rebuild() is always called with spa_config_lock held in
RW_WRITER mode. However, when it tries to call dmu_tx_assign()
the latter may hang on dmu_tx_wait() waiting for available txg.
But that available txg may not happen because txg_sync takes
spa_config_lock in order to process the current txg. So we have
a deadlock case here:
- dmu_tx_assign() waits for txg holding spa_config_lock;
- txg_sync waits for spa_config_lock not progressing with txg.
Here are the stacks:
__schedule+0x24e/0x590
schedule+0x69/0x110
cv_wait_common+0xf8/0x130 [spl]
__cv_wait+0x15/0x20 [spl]
dmu_tx_wait+0x8e/0x1e0 [zfs]
dmu_tx_assign+0x49/0x80 [zfs]
vdev_rebuild_initiate+0x39/0xc0 [zfs]
vdev_rebuild+0x84/0x90 [zfs]
spa_vdev_attach+0x305/0x680 [zfs]
zfs_ioc_vdev_attach+0xc7/0xe0 [zfs]
cv_wait_common+0xf8/0x130 [spl]
__cv_wait+0x15/0x20 [spl]
spa_config_enter+0xf9/0x120 [zfs]
spa_sync+0x6d/0x5b0 [zfs]
txg_sync_thread+0x266/0x2f0 [zfs]
The solution is to pass txg returned by spa_vdev_enter(spa)
at the top of spa_vdev_attach() to vdev_rebuild() and call
dmu_tx_create_assigned(txg) which doesn't wait for txg.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Reviewed-by: Akash B <akash-b@hpe.com>
Reviewed-by: Alek Pinchuk <apinchuk@axcient.com>
Signed-off-by: Andriy Tkachuk <andriy.tkachuk@seagate.com>
Closes openzfs#18210
Closes openzfs#18258
Currently, when there there are several faulted disks with attached dRAID spares, and one of those disks is cleared from errors (zpool clear), followed by its spare being detached, the data in all the remaining spares that were attached while the cleared disk was in FAULTED state might get corrupted (which can be seen by running scrub). In some cases, when too many disks get cleared at a time, this can result in data corruption/loss. dRAID spare is a virtual device whose blocks are distributed among other disks. Those disks can be also in FAULTED state with attached spares on their own. When a disk gets sequentially resilvered (rebuilt), the changes made by that resilvering won't get captured in the DTL (Dirty Time Log) of other FAULTED disks with the attached spares to which the data is written during the resilvering (as it would normally be done for the changes made by the user if a new file is written or some existing one is deleted). It is because sequential resilvering works on the block level, without touching or looking into metadata, so it doesn't know anything about the old BPs or transactions groups that it is resilvering. So later on, when that disk gets cleared from errors and healing resilvering is trying to sync all the data from its spare onto it, all the changes made on its spare during the resilvering of other disks will be missed because they won't be captured in its DTL. That's why other dRAID spares may get corrupted. Here's another way to explain it that might be helpful. Imagine a scenario: 1. d1 fails and gets resilvered to some spare s1 - OK. 2. d2 fails and gets sequentially resilvered on draid spare s2. Now, in some slices, s2 would map to d1, which is failed. But d1 has s1 spare attached, so the data from that resilvering goes to s1, but not recorded in d1's DTL. 3. Now, d1 gets cleared and its s1 gets detached. All the changes done by the user (writes or deletions) have their txgs captured in d1's DTL, so they will be resilvered by the healing resilver from its spare (s1) - that part works fine. But the data which was written during resilvering of d2 and went to s1 - that one will be missed from d1's DTL and won't get resilvered to it. So here we are: 4. s2 under d2 is corrupted in the slices which map to d1, because d1 doesn't have that data resilvered from s1. Now, if there are more failed disks with draid spares attached which were sequentially resilvered while d1 was failed, d3+s3, d4+s4 and so on - all their spares will be corrupted. Because, in some slices, each of them will map to d1 which will miss their data. Solution: add all known txgs starting from TXG_INITIAL to DTLs of non-writable devices during sequential resilvering so when healing resilver starts on disk clear, it would be able to check and heal blocks from all txgs. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Akash B <akash-b@hpe.com> Signed-off-by: Andriy Tkachuk <andriy.tkachuk@seagate.com> Closes openzfs#18286 Closes openzfs#18294
statx(2) requires _GNU_SOURCE to be defined in order for sys/stat.h to produce a definition for struct statx and the STATX_* defines. We get that at compile time because we pass -D_GNU_SOURCE through to everything, but in the configure check we aren't setting _GNU_SOURCE, so we don't find STATX_MNT_ID, and so don't set HAVE_STATX_MNT_ID. (This was fine before ccf5a8a, because linux/stat.h does not require _GNU_SOURCE). Simple fix: in the check, define _GNU_SOURCE before including sys/stat.h. Sponsored-by: TrueNAS Reviewed-by: Ameer Hamza <ahamza@ixsystems.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18312
Update the redundancy_draid_spare1 exception to reference an issue which describes the failure. Remove the exception for the redundancy_draid_spare3 test. I have not observed it in local testing. If it reproduces in the CI we can create a new issue for it and put back the exception. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#18308
Observed again in the CI. Put the maybe exception back in place and reference a newly created issue for this sporadic failure. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#18320
It turns out the kernel can also take directory leases, most notably in the NFS server. Without a setlease handler on the directory file ops, attempts to open a directory over NFS can fail with EINVAL. Adding a directory setlease handler was missed in 168023b. This fixes that, allowing directories to be properly accessed over NFS. Sponsored-by: TrueNAS Reported-by: Satadru Pramanik <satadru@gmail.com> Signed-off-by: Rob Norris <rob.norris@truenas.com> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18339
Removing the HAVE_FS_CONTEXT gates and anything that would be used if it wasn't set. Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18339
With the old API gone, there's no need to massage new-style calls into its shape and call another function; we can just make those handlers work directly. Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18339
Target of opportunity; with no other callers, there's no need for it to be a static function. Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18339
Target of opportunity; with no other callers, there's no need for it to be a static function. Sponsored-by: TrueNAS Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18339
Allow restricting ZTS OS targets by setting the vars.ZTS_OS_OVERRIDE repository variable (e.g. '["debian13"]') to reduce shared runner contention when running the full OS matrix is unnecessary. When unset, the existing ci_type-based OS selection is used unchanged. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Ameer Hamza <ahamza@ixsystems.com> Closes openzfs#18342
Do a ZFS build inside of an ARM runner. This only does a simple build, it does not run the test suite. The build runs on the runner itself rather than in a VM, since nesting is not supported on Github ARM runners. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: George Melikov <mail@gmelikov.ru> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#18343
…fs#18348) (openzfs#18354) This function was removed in c6442bd: "Removing old code outside of 4.18 kernsls", but fails at present on PowerPC builds due to the recent inclusion of 6bc9c0a90522: "powerpc: fix KUAP warning in VMX usercopy path" in the upstream kernel, which introduces a use of cpu_feature_keys[], which is a GPL-only symbol. Removing the API check as it doesn't appear necessary. Signed-off-by: John Cabaj <john.cabaj@canonical.com> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
Update FreeBSD CI targets from 14.3 to 14.4 in both the QEMU start script and the workflow configuration. Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Christos Longros <chris.longros@gmail.com> Closes openzfs#18362
Normally, kernel gives any LSM registering a `sb_eat_lsm_opts` hook a first look at mount options coming in from a userspace mount request. The LSM may process and/or remove any options. Whatever is left is passed to the filesystem. This is how the dataset properties `context`, `fscontext`, `defcontext` and `rootcontext` are used to configure ZFS mounts for SELinux. libzfs will fetch those properties from the dataset, then add them to the mount options. In 0f608aa (openzfs#18216) we added our own mount shims to cover the loss of the kernel-provided ones. It turns out that if a filesystem provides a `.parse_monolithic callback`, it is expected to do _all_ mount option parameter processing - the kernel will not get involved at all. Because of that, LSMs are never given a chance to process mount options. The `context` properties are never seen by SELinux, nor are any other options targetting other LSMs. Fix this by calling `security_sb_eat_lsm_opts()` in `zpl_parse_monolithic()`, before we stash the remaining options for `zfs_domount()`. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18376
Currently, after rebuild (aka sequential resilver), checksum errors can be seen sometimes on the spare vdev or draid spare. On my laptop, it happens from 2 to 4 times of running redundancy_draid_spare1 test in a loop for 100 times. It looks like there's a race in vdev_rebuild_thread() when the rebuild of space map ranges is finished and we re-enable allocations from the metaslab too soon: a new allocations may happen from that metaslab before txg with the rebuilt ranges is sync-ed, causing undesirable interference. Solution: wait for the txg to be sync-ed before enabling metaslab. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Akash B <akash-b@hpe.com> Signed-off-by: Andriy Tkachuk <atkachuk@wasabi.com> Closes openzfs#18307 Closes openzfs#18319 Closes openzfs#18473
Only call txg_wait_synced() when rebuild IOs were issued for this metaslab. This is a small optimization since in practice the first metaslab is very likely to have allocations and cause vr_last_txg to be initialized. After this point when processing empty metaslabs txg_wait_synced() is called but with an already committed txg so it will not wait. Still it's better not to call txg_wait_synced() at all when it's not needed. Reviewed-by: Andriy Tkachuk <atkachuk@wasabi.com> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#18482
The d_u union introduced in 3.18 is now anonymous, so we need to detect it and decide the right way to name d_alias. Note that we used to have support for both names to support kernels before 3.18, so this commit is effectively reverting the commit that removed that support, efc293e. Sponsored-by: TrueNAS Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Rob Norris <rob.norris@truenas.com> Closes openzfs#18471
- Add Fedora 44 to CI tests - Fix build issues from the newer compiler. These are mostly 'char *' to 'const char *' conversions. - Fix threadsappend.c test waiting for the same thread TID twice. This caused the test to hang on F44 (but strangely not other OSs?) Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#18478
Update freebsd15-0s builder to freebsd15-1s and point it at the 15.1-PRERELEASE tag. The previous freebsd-15.0-STABLE images are no longer available. Additionally, add a freebsd15-0r stanza for the RELEASE. Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 4, 2026 17:39
602ed78 to
570e7f5
Compare
Remove redundant dsl_pool variable and duplicate spa_get_dsl() call in vdev_rebuild_thread. Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Akash B <akash-b@hpe.com> Closes openzfs#18263
The spa_sync thread waits on ->spa_txg_zio and will set ZIO_WAIT_DONE before running the sync tasks. The dmu_tx_commit() call must be done after we add the child zio to the ->spa_txg_zio parent otherwise its possible the child is added after txg_sync has waited. Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com> Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov> Closes openzfs#18276
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 4, 2026 20:16
570e7f5 to
b537863
Compare
…#18469) When the path argument to "zfs list -Ho name <path>" (or any caller of zfs_path_to_zhandle()) is a symlink that crosses a mount boundary, the wrong dataset is returned. Instead of returning the dataset that owns the symlink's target, getextmntent() matches the dataset containing the symlink itself. For example, given two ZFS datasets "tank/ds1" and "tank/ds2", and a symlink "/tank/ds1/link" pointing into "/tank/ds2": $ sudo zfs list -Ho name /tank/ds1/link tank/ds1 The expected (and previous) behavior is to return "tank/ds2", since the symlink's target resides in that dataset. The problem is in getextmntent(), in lib/libspl/os/linux/mnttab.c. That function calls statx() on the caller-supplied path to obtain its mnt_id (used to match against the mnt_id of each entry in /proc/self/mounts), and it passes AT_SYMLINK_NOFOLLOW to that statx() call. As a result, the mnt_id returned reflects the symlink's location rather than the symlink target's mount, and the wrong /proc/self/mounts entry is matched. The same function also calls stat64() on the caller-supplied path (used as a fallback when STATX_MNT_ID is not available, and to populate the statbuf out-parameter). stat64() always follows symlinks, so the statx() and stat64() calls were inconsistent: one resolved the symlink, the other didn't. The AT_SYMLINK_NOFOLLOW behavior may be appropriate when statx() is called on a mount entry from /proc/self/mounts (which is always a real directory), but it is wrong for caller-supplied paths, which may be symlinks. This bug was introduced by 523d9d6 ("Validate mountpoint on path-based unmount using statx"), which added the STATX_MNT_ID code path. However, the bug was latent: config/user-statx.m4 omitted "#define _GNU_SOURCE" when checking for STATX_MNT_ID in <sys/stat.h>, so HAVE_STATX_MNT_ID was never defined, and the buggy statx() path was never compiled in. getextmntent() always fell back to the dev_t comparison via stat64(), which correctly follows symlinks. The fix to that autoconf check, in 2b930f6 ("config: fix STATX_MNT_ID detection"), caused HAVE_STATX_MNT_ID to be properly defined on kernels that support it, activating the broken AT_SYMLINK_NOFOLLOW path for the first time and exposing the regression. The fix is to drop AT_SYMLINK_NOFOLLOW from the statx() call so that symlinks are followed, matching the behavior of stat64() on the same path. Verified with a minimal reproducer: created two ZFS datasets, placed a symlink inside the first pointing into the second, and confirmed that "zfs list -Ho name <symlink>" returns the dataset containing the symlink's target rather than the dataset containing the symlink. Signed-off-by: Prakash Surya <prakash.surya@perforce.com> Reviewed-by: Ameer Hamza <ahamza@ixsystems.com> Reviewed-by: Mark Maybee <mark.maybee@delphix.com> Reviewed-by: Alexander Motin <alexander.motin@TrueNAS.com>
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 4, 2026 20:36
b537863 to
c9e6445
Compare
Convert 'char *' to 'const char *' to make GCC happy on Fedora 44. Signed-off-by: Tony Hutter <hutter2@llnl.gov>
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 5, 2026 22:44
c9e6445 to
c6f5d98
Compare
|
If there is time for this release it would be helpful to test against Almalinux 10.2 Beta. Attempting to install the zfs-2.4.1 AL10.1 kmod fails with the following, but installing dkms works for trivial tests. [root@ldas-pcdev16 ~]# cat /etc/almalinux-release AlmaLinux release 10.2 Beta (Lavender Lion) [root@ldas-pcdev16 ~]# uname -a Linux ldas-pcdev16 6.12.0-211.7.1.el10_2.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 30 21:19:35 EDT 2026 x86_64 GNU/Linux [root@ldas-pcdev16 ~]# dnf --enablerepo=zfs-testing-kmod install zfs Last metadata expiration check: 0:03:41 ago on Tue 05 May 2026 04:25:28 PM PDT. Error: Problem: package zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod requires zfs-kmod = 2.4.1, but none of the providers can be installed - cannot install the best candidate for the job - nothing provides kernel(__alloc_pages_noprof) = 0x8aab2d5b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__blk_alloc_disk) = 0x3795fbfd needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__blk_mq_alloc_disk) = 0x122e872f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__blkdev_issue_discard) = 0xa142b076 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__cpuhp_remove_state) = 0xef30e318 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__cpuhp_setup_state) = 0x958207b0 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__cpuhp_state_add_instance) = 0xac53f682 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__cpuhp_state_remove_instance) = 0xc176def4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__folio_lock) = 0x2a4357b4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__folio_put) = 0x67b1b01a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__free_pages) = 0x2efdd8b5 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__kmalloc_cache_noprof) = 0xb34f2269 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__kmalloc_node_noprof) = 0xfff7305d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__kmem_cache_create_args) = 0xd112ec6f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__mark_inode_dirty) = 0x2948634c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__put_cred) = 0x103070f7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__put_devmap_managed_folio_refs) = 0xab11fe70 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__put_user_ns) = 0xe673db04 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__remove_inode_hash) = 0x2df89534 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__seq_puts) = 0x16db141c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(__tracepoint_sched_set_state_tp) = 0xa2a5a3a6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(_copy_from_iter) = 0x1b58186b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(_copy_to_iter) = 0xa3e36528 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bdev_end_io_acct) = 0xe0fc718c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bdev_file_open_by_path) = 0xbef643e0 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bdev_start_io_acct) = 0xbba43139 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bio_add_page) = 0xc1ab9484 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bio_alloc_bioset) = 0xff0d4c3c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bio_chain) = 0x4c9b7e64 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bio_endio) = 0x4911a863 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(bio_put) = 0x40169c04 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_finish_plug) = 0x81120f5a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_mq_alloc_tag_set) = 0x0b5b9a02 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_mq_end_request) = 0x63763a57 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_mq_free_tag_set) = 0x9fe26d49 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_mq_start_request) = 0x99417dbb needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_queue_flag_set) = 0x814eb74d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blk_start_plug) = 0xc5c5219f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(blkdev_issue_secure_erase) = 0xcc3c1a2f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(clear_inode) = 0x03dd193b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(clear_nlink) = 0xacf51be4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(clear_page_dirty_for_io) = 0x9b7050e1 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(const_pcpu_hot) = 0x3ab99294 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(copy_splice_read) = 0xc565fedb needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(current_time) = 0x5afec0ac needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_add_ci) = 0x30452527 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_drop) = 0x7aa78da8 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_instantiate) = 0x1f372ad1 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_invalidate) = 0x8e213a62 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_make_root) = 0xf4a7a1a2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_obtain_alias) = 0x67256476 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_parent_ino) = 0xc1f7a599 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_path) = 0xe375c9b7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_prune_aliases) = 0xda1ec055 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_splice_alias) = 0x47a4ca52 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_tmpfile) = 0x0edb72c7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(deactivate_locked_super) = 0x4ee098d4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(deactivate_super) = 0xe7e7361b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(del_gendisk) = 0x11643b90 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(device_add_disk) = 0x83963197 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(disk_check_media_change) = 0xd44b1ced needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(dput) = 0xafce2fb2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(drop_nlink) = 0x7a8d8649 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(end_page_writeback) = 0x2d0ddf8b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(fault_in_iov_iter_readable) = 0x97236f26 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(fget) = 0x46a4e061 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(file_bdev) = 0x11b3d1b4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(filemap_alloc_folio_noprof) = 0xf3fb296d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(filemap_dirty_folio) = 0xf8392b4f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(filemap_range_has_page) = 0x9f49de82 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(filp_close) = 0xb965268a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(filp_open) = 0x73d09bb1 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(finish_open) = 0x6f70ab3b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(flush_signals) = 0x2484e86b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(folio_mapping) = 0x3ff37ed1 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(folio_wait_bit) = 0x3c532c3b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(follow_down_one) = 0x86a557b4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(forget_cached_acl) = 0x157a2cd1 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(fput) = 0xfdaf1152 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(from_kgid) = 0x85b29a70 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(from_kuid) = 0xf40c0d90 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(fs_bio_set) = 0x385e114d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_fadvise) = 0x2cdf19ac needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_file_llseek) = 0xd6835d85 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_file_mmap) = 0x292b5aa3 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_file_open) = 0x8388574d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_fillattr) = 0xa76c0f5c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_permission) = 0x744f172b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_read_dir) = 0x35514a23 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_write_checks) = 0x03e1ec46 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(igrab) = 0x280ef134 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(ilookup) = 0x4e36dbd3 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(inc_nlink) = 0x11f63de6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(init_special_inode) = 0x58a4621d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(init_task) = 0xdce535c2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(init_timer_key) = 0xc6f46339 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(init_user_ns) = 0x5377ef14 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(inode_init_once) = 0xb3952d40 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(inode_owner_or_capable) = 0x71eafc70 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(inode_set_flags) = 0x49891899 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(insert_inode_locked) = 0x4fb25c15 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(invalidate_bdev) = 0x5e484873 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iov_iter_advance) = 0x5c27abaa needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iov_iter_alignment) = 0x26ce695b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iov_iter_get_pages2) = 0x41adf5db needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iov_iter_revert) = 0x9bf1909c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iput) = 0x6cacb6b8 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(iter_file_splice_write) = 0xac57db0d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kern_path) = 0x84653de6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kernel_read) = 0x8bb784f5 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kernel_write) = 0x2b3ed916 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kill_anon_super) = 0x98b3a9b4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kmalloc_caches) = 0x297d2a2f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kmem_cache_alloc_noprof) = 0xe5d8dbd7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kmem_cache_destroy) = 0x2ba27aa7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kmem_cache_free) = 0x904eb853 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kobject_add) = 0x85725c15 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kobject_del) = 0x560bf1de needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kobject_init) = 0xdc4ce3f6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kobject_put) = 0x5110f96a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kobject_uevent) = 0x91b34f49 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kthread_bind) = 0xd5bc1878 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kthread_create_on_node) = 0xe37d5f14 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(kthread_stop) = 0x6170ee92 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(make_kgid) = 0xa20a7995 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(make_kuid) = 0x5e880c11 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(mark_page_accessed) = 0x3fea72a2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(migrate_folio) = 0x5d72c353 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(misc_deregister) = 0x76696f7b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(misc_register) = 0x5fe014f7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(module_layout) = 0x6404a6de needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(new_inode) = 0x83f2f797 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(ns_capable) = 0x01df6d06 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(override_creds) = 0xbeadd441 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(pagecache_get_page) = 0x7986658f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_get_charp) = 0x4754a359 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_get_uint) = 0x72617daf needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_get_ullong) = 0x88f12025 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_ops_charp) = 0x89302c8a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_ops_int) = 0xd862838d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_ops_uint) = 0x8d1cae97 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_ops_ullong) = 0x887462fe needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_ops_ulong) = 0x595fc27d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_set_charp) = 0x4755a588 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_set_int) = 0xe6f97c11 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_set_uint) = 0x3340dade needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(param_set_ullong) = 0x2e67365d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(path_get) = 0x2ca75cb9 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(path_put) = 0x21145a62 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(pcpu_hot) = 0x5a3b68ce needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(pin_user_pages_unlocked) = 0xf0096913 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(posix_acl_from_xattr) = 0xf6e70cef needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(posix_acl_to_xattr) = 0x320cc9eb needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(posix_acl_valid) = 0x9f9595ad needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(proc_create_data) = 0xd0489c51 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(proc_mkdir) = 0xfaa638a4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(put_disk) = 0x49d2121a needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(redirty_page_for_writepage) = 0xb8e67c3b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(register_filesystem) = 0x8e541423 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(remove_proc_entry) = 0xe1c8aba6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(revert_creds) = 0x8bf90170 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(security_inode_init_security) = 0xf3ae20bd needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_lseek) = 0x4e5e86a0 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_open) = 0x81456531 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_open_private) = 0xa445d7e7 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_printf) = 0x1fbbb120 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_putc) = 0xe34258ac needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_read) = 0x6e0806b0 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_release) = 0x5b27b448 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_release_private) = 0x5c0de3aa needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(seq_write) = 0x6864009e needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_anon_super) = 0x07d9aeff needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_cached_acl) = 0x89404541 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_capacity) = 0x743c0c09 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_disk_ro) = 0xb3e19c7c needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_nlink) = 0x1cd53141 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_page_writeback) = 0xf01a79ea needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(set_user_nice) = 0xf7379ae5 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(setattr_prepare) = 0xb6f813a0 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(sg_alloc_table_from_pages_segment) = 0xe9ec201f needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(sg_next) = 0xfbe215e4 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(sget) = 0x360dacdf needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(shrink_dcache_sb) = 0xaeea66b5 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(simple_dir_inode_operations) = 0x9a43e865 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(simple_dir_operations) = 0x05d92751 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(splice_file_range) = 0x6e213fb9 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(submit_bio) = 0xabcd9527 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(super_setup_bdi_name) = 0x73ea8c8b needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(sync_blockdev) = 0x6718eb83 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(timestamp_truncate) = 0x9ad90fac needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(touch_atime) = 0x6e25c2b2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(truncate_inode_pages_range) = 0xd2a8fa20 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(truncate_setsize) = 0x5b620403 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(unlock_new_inode) = 0x0a23fc37 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(unlock_page) = 0x2b8de1fc needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(unpin_user_pages) = 0xad8ce049 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(unregister_filesystem) = 0x92b9cedd needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vfs_fsync) = 0xd17c19d6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vfs_getattr) = 0x73ff58ab needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vfs_llseek) = 0x5e15e37d needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vfs_statfs) = 0x52946fd2 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vm_node_stat) = 0xe0cff481 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vm_zone_stat) = 0x02ba1187 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(vmalloc_to_page) = 0x49ab5ed3 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(wake_up_process) = 0x08e83fd6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(write_cache_pages) = 0x7a515970 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(write_inode_now) = 0x5a19de07 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(d_set_d_op) = 0xe26c2422 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod - nothing provides kernel(generic_delete_inode) = 0x85ab7fe6 needed by kmod-zfs-2.4.1-1.el10.x86_64 from zfs-testing-kmod (try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages) |
Contributor
- For multilevel gang blocks it seemed possible to fallback from normal to special class, since they don't have proper object type, and DMU_OT_NONE is a "metadata". They should never fallback. - Fix possible inversion with zfs_user_indirect_is_special = 0, when indirects written to normal vdev, while small data to special. Make small indirect blocks also follow special_small_blocks there. - With special_small_blocks now applying to both files and ZVOLs, make it apply to all non-metadata without extra checks, since there are no other non-metadata types. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com> Closes openzfs#18208
For now make it only evict the specified data from the dbuf cache. Even though dbuf cache is small, this may still reduce eviction of more useful data from there, and slightly accelerate ARC evictions by making the blocks there evictable a bit sooner. On FreeBSD this also adds support for POSIX_FADV_NOREUSE, since the kernel translates it into POSIX_FADV_DONTNEED after every read/write. This is not as efficient as it could be for ZFS, but that is the only way FreeBSD kernel allows to handle POSIX_FADV_NOREUSE now. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com> Closes openzfs#18399
dbuf_whichblock() is not made to handle offsets beyond the block end for single-block objects. Handle it in dmu_evict_range(), similar to dmu_prefetch_by_dnode(). Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Reviewed-by: Tony Hutter <hutter2@llnl.gov> Signed-off-by: Alexander Motin <alexander.motin@TrueNAS.com> Closes openzfs#18399 Closes openzfs#18489
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 7, 2026 17:10
c6f5d98 to
ea3171f
Compare
14 tasks
Contributor
|
results.txt |
Fixes regression introduced by 61ab032. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com> Signed-off-by: Joel Low <joel@joelsplace.sg> Closes openzfs#18442
META file and changelog updated. Signed-off-by: Tony Hutter <hutter2@llnl.gov>
tonyhutter
force-pushed
the
zfs-2.4.2-staging
branch
from
May 11, 2026 16:43
ea3171f to
6330a45
Compare
behlendorf
approved these changes
May 12, 2026
Closed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation and Context
Proposed patchset for zfs-2.4.2
Description
How Has This Been Tested?
Types of changes
Checklist:
Signed-off-by.