Arch Linux User Repository

When requesting changes, please include detailed reasoning for the change.

If you receive this error when trying to build, it is because you have not imported the GPG keys used for verification.

==> ERROR: One or more PGP signatures could not be verified!

You have two options:

1) Import the two keys into your keyring. ArchWiki article. You can find the key IDs in the PKGBUILD file, in the validpgpkeys array. (recommended)

2) Alternatively, you can skip this verification by passing the --skippgpcheck argument to makepkg when building. (not recommended)

Hi ZFSers,

Looks like we are stuck in limbo again with the 6.7-x kernels until upstream releases zfs-2.2.3 with 6.7-x support. Until then, you'll see:

==> dkms install --no-depmod zfs/2.2.2 -k 6.7.0-arch1-1
configure: error: 
        *** None of the expected "sb->s_shrink()" interfaces were detected.
        *** This may be because your kernel version is newer than what is
        *** supported, or you are using a patched custom kernel with
        *** incompatible modifications.
        ***
        *** ZFS Version: zfs-2.2.2-1
        *** Compatible Kernels: 3.10 - 6.6

Error! Bad return status for module build on kernel: 6.7.0-arch1-1 (x86_64)
Consult /var/lib/dkms/zfs/2.2.2/build/make.log for more information.

Of course, linux-zen throws the same error.

You can of course, run linux-hardened (for now) and/or the LTS kernel until we get upstream 6.7-x support.

Cheers

@baslking This is a bug introduced by linux kernel developers to force hand of closed source shops like Nvidia, who are standing on GPL land earning money, by slowly boiling the frog. ZFS is collateral damage. Meanwhile, ZFS developers urge affected users to not pester said linux kernel developers, but instead to wait for patches. Despite this, what is missing imho, is somebody testing new stable kernels and report on linux-stable regularly. Like the other guys with non-x86 archs. "ZFS 2.2.2 working" "Nope, you broke it." "It works again" etc. As a service reminder to policy makers, from a trusted but well-hidden linux power user group.

The kernel 6.6 on amd64 works. For others, try emptying the "GPL" to empty string in https://github.com/torvalds/linux/blob/master/include/linux/export.h#L87 and L89 and compile your own kernel. I haven't tested this, but by briefly looking, I think this might be the spot.

For me, on aarch64, using the 6.6 Kernel dkms fails with GPL constraints. I have read that this would become an issue. Is anyone else seeing this? Maybe the x86_64 arch works?

I backed off the kernel to 6.1.70-1 and I managed to re-install zfs-dkms successfully. ZFS 2.2.2 claims to support 6.6 kernel, but the dkms command is failing for me,

The failed dkms make.log ends with:

MODPOST /var/lib/dkms/zfs/2.2.2/build/module/Module.symvers
ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'kernel_neon_end'
ERROR: modpost: GPL-incompatible module zfs.ko uses GPL-only symbol 'kernel_neon_begin'
make[3]: *** [scripts/Makefile.modpost:145: /var/lib/dkms/zfs/2.2.2/build/module/Module.symvers] Error 1
make[2]: *** [/usr/lib/modules/6.6.9-1-rpi-ARCH/build/Makefile:1865: modpost] Error 2
make[1]: *** [Makefile:234: __sub-make] Error 2
make[1]: Leaving directory '/usr/lib/modules/6.6.9-1-rpi-ARCH/build'
make: *** [Makefile:56: modules-Linux] Error 2
make: Leaving directory '/var/lib/dkms/zfs/2.2.2/build/module'

@bsdice: An emulated block device is not a valid benchmark. Have you seen a performance impact on real physical HDD/SSD/nvme?

@mabod: Try Optane PMEM emulated block device with ZFS and ProxMox, 1/3rd iops on 4k random read/write

@bsdice: Have you experienced a performance hit of init_on_alloc? I am aware about the discussion e.g https://github.com/openzfs/zfs/issues/9910 But I do not see any performance difference with several fio benchmarks with multiple parallel threads.

Personally I am on LTS kernel 6.1 for most machines and will keep in file /etc/modprobe.d/zfs.conf the lines options zfs zfs_bclone_enabled=0 and also options zfs zfs_dmu_offset_next_sync=0 until some grass has grown over the issue. Say a year or two, at least until the next revision of ZFS test suite includes tests for this sort of corruption.

There might be a performance hit with zfs_dmu_offset_next_sync=1 so I keep it off.

I don't need block cloning and also am willing to let LZ4 shrink any hole of zeros instead of ZFS handling sparseness. I realize on VM thin provisioned workloads with many holes things might look different i.e. ProxMox setups.

I also will keep init_on_alloc=0 init_on_free=0 as kernel parameters because of the performance hit for ZFS.

Thanks @kstolp! Appreciate you being so on the ball with all of this!

@urbenlegend No. As of 2.2.1-2, you do not need to set zfs_dmu_offset_next_sync. The underlying issue was identified and fixed in PR#15571.

As of 2.2.1-2, do we still need zfs_dmu_offset_next_sync=0?