Package Details: zfs-linux 2.3.1_6.13.8.arch1.1-1

Git Clone URL: https://aur.archlinux.org/zfs-linux.git (read-only, click to copy)
Package Base: zfs-linux
Description: Kernel modules for the Zettabyte File System.
Upstream URL: https://openzfs.org/
Keywords: kernel linux openzfs zfs
Licenses: CDDL
Groups: archzfs-linux
Conflicts: spl-dkms, spl-dkms-git, spl-linux, zfs-dkms, zfs-dkms-git, zfs-dkms-rc, zfs-linux-git, zfs-linux-rc
Provides: spl, zfs
Replaces: spl-linux
Submitter: demizer
Maintainer: lightdot
Last Packager: lightdot
Votes: 275
Popularity: 1.16
First Submitted: 2016-04-21 08:45 (UTC)
Last Updated: 2025-03-25 23:55 (UTC)

Required by (19)

Sources (1)

Pinned Comments

lightdot commented on 2025-02-04 21:19 (UTC) (edited on 2025-03-29 20:47 (UTC) by lightdot)

This package will be kept in sync with the openzfs latest stable release and the kernels officially supported by it.

For the supported kernel versions, refer to the respective openzfs release notes (LINK).

E.g. openzfs 2.3.1 supports kernel versions 4.18 - 6.13. When kernel 6.14 is released for Arch, zfs-linux will not be updated until the openzfs project announces that it's compatible. This will most likely happen with the next openzfs release.

The kernel compatibility of the upcoming openzfs release can be seen in their META file (LINK).

For those wishing to use openzfs with unsupported kernels, do note that this could lead to serious issues, including data loss, even though such a zfs-linux package might build and install cleanly. Have reliable backups and use such a package at your peril.

Please do not mark this package as out of date without checking the kernel compatibility first. Thank you!

Latest Comments

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 79 Next › Last »

demizer commented on 2014-06-28 20:25 (UTC)

Hello everyone! My workstation is currently down due to a bad memory module. I am currently running memtest on new memory and hopefully it will be good after a run of 12-24 hours. Unfortunately, I won't be able to update the packages until tomorrow. I also had a drive in the zfs storage pool become corrupt due to the bad memory. So remember, ZFS is only as good as the hardware! I can't really afford and ECC memory setup ATM, so I make sure my backups are up-to-date always.

Zielony commented on 2014-06-28 17:02 (UTC)

Hi, demizer, you are probably aware there has been released 3.15.2-1 already. ;-) Thank you for previous great package work and in advance for this next one. Best regards

justinkb commented on 2014-06-24 01:37 (UTC)

Hm, I didn't notice any bumps to the actual commit after the bump from 0.6.2 base to the specific commit on master (4fd762f) necessitated by the 3.14 kernel release a while back. Unless critical issues arise, I don't think demizer intends to be constantly bumping the commit (now 07dabd2, which is the 0.6.3 tag) in the PKGBUILD...

khenderick commented on 2014-06-21 06:17 (UTC)

@justinkb, as per my understanding (from discussions here in the past), zfs-git follows the master branch, so the zfs-git package is evolving as time passes, following the commits on the repo. All commits on the master branch are considered stable enough and to be as stable as Arch Linux itself, being a rolling release. It was explained that taking the last release and always having to patch the code to work with the evolving kernel is a lot of work and might introduce bugs during the patching, making such packages in fact even less stable than the master branch. If stability is your main concern (running and enterprise storage system or so), you would most likely be running the -lts variants from both kernel and zfs anyway :).

justinkb commented on 2014-06-21 00:01 (UTC)

@kerberizer, As long as you use known "stable" commits (current commit is the 0.6.3 tag effectively, right?) I'm totally on board with keeping these as git packages. Just thought it would lessen the maintenance burden until kernel 3.16 might start messing up compilation again. :-) But your rationale for keeping it on git is fine.

demizer commented on 2014-06-19 05:44 (UTC)

For reference, if anyone needs old packages they are archived here http://demizerone.com/archive_archzfs/

demizer commented on 2014-06-19 03:25 (UTC)

timemaster and kerberizer are correct on all points. I am going to update the packages for kernel 3.15.1, and begin work on re-factoring the initcpio hooks. The hooks have two issues logged on the archzfs github project page and I am going to work over the next few days to iron them out. There is also another issue with hostid reported by email that I am going to fix. I don't want to bork systems that use zfs as the root fs, so if you have what you consider a unique setup, please post the spec here. I will be setting up testing environments in qemu and recording my steps for the record. Again, if you are using a unique root zfs setup, please take a bit of time and post your setup so I can make tests for it. Once I have the hooks done, I will post a notice here two hours before posting the updated packages to give people a heads up. It will be up to the user to make sure their system does not get stuck in busy box. Hopefully with multiple testing environments setup, this won't be an issue. Thanks!

kerberizer commented on 2014-06-19 02:40 (UTC)

@timemaster, exactly. @justinkb, you may find more details in the comments from 2014-04-13. If your concern is that the SPL/ZFS master branch is not stable enough -- which could, indeed, be a valid concern depending on your specific use case, e.g. in a critically important production system environment -- then you'd probably want to use the linux-lts kernel packages anyway; and @demizer also supports {spl,zfs}{,-utils}-lts packages for those kernels. Not much sense otherwise to use very stable SPL/ZFS code on not-so-stable kernel codebase (i.e. on the non-lts kernels). As a side note, on not particularly critical systems, I have found the frequent updating to be actually more manageable than jumping from one stable version to another. The reason is that the changes are introduced at much smaller steps, so 1) cases, where you face a large number of significant changes and in very different areas, are avoided, and 2) if a bug is encountered, it's source can be easily located across the code, often outright down to the specific commit. For this reason now I tend to rebuild my own ZoL packages on almost every new commit. But again, this may not quite be the best approach for critical production systems. :)

timemaster commented on 2014-06-19 01:31 (UTC)

I don't think resurecting the stable packages will provide any long term good. If I understand correctly, the original issue was that the stable packages were lacking so much behind that they could not build on newer kernel. Maintainer had to patch them to make them wok on newer version and it was finally decided that instead of patching them in a untested way we would be much better and stable to use the git version that work on newer kernel. If I am not mistaken, the packages for zfs-git was always specifying the same git commit even across kernel upgrade. This provided a consistent version that would work for newer kernel version and won't introduce new development bugs. Now that a new stable version exists, let's just point this zfs-git to that specific tag and be done with it. When a future kernel is released and 0.7.3 can still build on it, then let's keep it. When a future kernel is released and the current 0.7.3 version can't build on it, then we'll just bump the package version to use a newer development commit ? kernel incompatibility seems to have a high chance of happening so resurecting the stable packages then to delete them again seems pointless. Your thoughts ?

justinkb commented on 2014-06-19 00:47 (UTC)

Well, this is interesting: * zfsonlinux 0.6.3 has been released * kernel 3.15 has landed in [core] I checked and 0.6.3 supports 3.15 without any patches. Maybe it's time to bring back the non-git spl/spl-utils/zfs/zfs-utils packages.

« First ‹ Previous 1 .. 32 33 34 35 36 37 38 39 40 41 42 .. 79 Next › Last »