Package Details: zfs-dkms 2.2.3-2

Git Clone URL: https://aur.archlinux.org/zfs-dkms.git (read-only, click to copy)
Package Base: zfs-dkms
Description: Kernel modules for the Zettabyte File System.
Upstream URL: https://zfsonlinux.org/
Licenses: CDDL
Provides: SPL-MODULE, zfs, ZFS-MODULE
Submitter: isiachi
Maintainer: kstolp
Last Packager: kstolp
Votes: 159
Popularity: 1.19
First Submitted: 2015-08-31 12:01 (UTC)
Last Updated: 2024-03-13 08:43 (UTC)

Pinned Comments

kstolp commented on 2023-09-29 00:34 (UTC)

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

kstolp commented on 2023-01-07 09:31 (UTC)

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)

Latest Comments

« First ‹ Previous 1 2 3 4 5 6 7 8 9 .. 58 Next › Last »

bsdice commented on 2024-01-10 08:50 (UTC) (edited on 2024-01-10 08:51 (UTC) by bsdice)

The problem with linux-lts (edit: ment 6.1.x branch) is the continuous breakage due to incomplete or wrong backports. I no longer trust it. It sounds funny and wrong but if you want stable, use Torvald's point releases. Second best imho is to use the n-1 kernel with moderate backporting. Right now that is 6.6.10. Of course you'd have to develop a strategy so kernels no longer roll during updates. Which you should do anyways when using ZFS.

jstrom commented on 2024-01-10 08:46 (UTC)

Note that linux-lts was bumped to 6.6 a day or so ago.

whiteman808 commented on 2024-01-10 08:30 (UTC)

I recommend to use linux-lts kernel instead of stock linux or linux-zen. I'm using linux-lts and no more problems with incompatible kernel :-)

air-g4p commented on 2024-01-10 07:57 (UTC)

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

bsdice commented on 2024-01-04 22:06 (UTC)

@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.

baslking commented on 2024-01-04 21:36 (UTC) (edited on 2024-01-04 21:37 (UTC) by baslking)

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'

mabod commented on 2023-11-30 08:13 (UTC)

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

bsdice commented on 2023-11-30 07:07 (UTC)

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

mabod commented on 2023-11-30 07:03 (UTC)

@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.

bsdice commented on 2023-11-29 17:46 (UTC) (edited on 2023-11-29 17:47 (UTC) by bsdice)

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.