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: 0.87
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 .. 38 39 40 41 42 43 44 45 46 47 48 .. 79 Next › Last »

kerberizer commented on 2014-04-16 01:56 (UTC)

As I emphasized when publishing them, those PKGBUILDs are not intended for general use, but rather as a potential point for reference. Sticking to demizer's well-proven, stable and supported packages and PKGBUILDs is the sensible thing to do, unless you want to experiment and then also understand well the risks involved. Now, for those that really want to tinker with my PKGBUILDs, here's a critical thing which I only hinted earlier: because these PKGBUILDs install the systemd unit files provided by ZoL, you need to `systemctl disable zfs.service` and then, after the packages are installed, to `systemctl enable zfs.target`. The latter is crucial for your datasets to be mounted as expected. There are likely more elegant ways to achieve this, but I haven't yet had the time to give it more thought (any ideas are welcome, of course: probably something connected with the systemd presets). P.S. The reason why it's not (apparently) necessary to change the version for the {spl,zfs}-utils-git PKGBUILDs is because they don't have a dependency on the Linux kernel. The real problem here, however, is that each of the PKGBUILDs in their own chain of dependencies (spl-utils -> spl-modules -> zfs-utils -> zfs-modules) doesn't check the version of the package it depends upon. That's exactly one of the other problems with my PKGBUILDs that I talked about (and the reason are the Git type versions, for which there's likely an easy and elegant solution, but at least I need some time to think about it; again, ideas are very welcome).

timemaster commented on 2014-04-16 00:09 (UTC)

Well... it seems I had an old version in /usr/local and it conflicted with the newer version. Seems to work with kerberizer packages and seems like my disk is 96% used :) fragmentation? who cares for a system mainly used for save once/don't read often.

timemaster commented on 2014-04-15 23:54 (UTC)

I tried to remove the zfs packages from demizer repo and build the git packages using kerberizer. Had to modify the version for the zfs-modules-git and spl-modules-git but not on the two others ? After the installation, zfs import was crashing with an error. I will be coming back to demizer version but they require a different version of the kernel...? I am lazy and this will be working back in a few days so I will wait I guess.

puithove commented on 2014-04-14 11:54 (UTC)

@demizer - switching to the -git packages sounds like a totally sane approach. Take it easy and hope you have a speedy recovery. Thanks for all you do here. My laziness likes the convenience of the repo so that I don't pull any kernel updates until I know the zfs stuff is building for it - especially useful if running with a zfs root.

demizer commented on 2014-04-14 01:09 (UTC)

@WhiteKnight, I will continue to update demz-repo-core, only the packages will be based on the zfs-git packages that we will begin to support. @kerberizer, The upstream git master branch is stable. Before patches are merged into the master branch they are tested. In the years I have been using ZOL, I have never had a problem using patches from the master branch. As far as the zfs, zfs-utils, spl, and spl-utils packages, I think they should be deleted too. We would have to record somewhere our reasoning for no longer updating these packages or following the ZFSonLinux.org release model. So for the record, on the next kernel bump, I will create the following packages (using kerberizer's existing work posted below) that use the "replaces" PKGBUILD variable: zfs-git zfs-utils-git spl-git spl-utils-git I will update these packages on every kernel bump so the changes propagate. The demz-repo-core packages will be based on these packages.

kerberizer commented on 2014-04-13 22:53 (UTC)

Sorry for spamming the comments, but it just came to me that if we migrate towards -git packages, the yaourt users will need to use the --devel option. Not sure if that's relevant for the other AUR helpers, and I wonder if it should be considered a problem or not.

kerberizer commented on 2014-04-13 22:36 (UTC)

I thought it might be still helpful to share the PKGBUILDs I've been working on, as a line or two of them may come in handy (I've also tried to optimize slightly a few things)... https://github.com/kerberizer/archzfs-git Mind you, they are NOT to be used blindly! At the very least, they need manually switching to the new systemd zfs.target provided by ZoL, but that's not the only thing that needs additional tinkering. @WhiteKnight: You are welcome! ;) As for the LTS packages, they are necessary anyway, and if I find some time next week, I might give them a try, as it's certainly better for @demizer to concentrate on his recovery right now.

WhiteKnight commented on 2014-04-13 14:40 (UTC)

Thanks for the detailed explanation, @kerberizer. With your words in mind, just forget my asking for LTS packages. :)

kerberizer commented on 2014-04-13 14:24 (UTC)

@WhiteKnight: As @demizer said, the master branch of the ZoL code is considered stable -- or at least as "stable" as Arch Linux itself is, being a rolling release distribution. This means that moving to -git packages shouldn't lower the stability of a non-LTS Arch Linux system below its inherent level. To put it another way, the packages based on release tags (e.g. 0.6.2) cannot make a non-LTS system any more stable that it inherently is, and indeed, due to the need for specific patching with small user base for testing, they might even _lower_ that stability. This means that all people who have so far been happy with the regular packages shouldn't be any less happy with the -git ones. And those who need more stability than that should consider the LTS kernels anyway -- or, even better, a non rolling-release distribution (for example, I personally tend to use older, well-proven versions of FreeBSD for the most critical systems I manage, albeit it's somewhat arguable if that's not simply laziness on my side ;))). BTW, there's one more reason in my view why -git packages are convenient for non-critical systems. They allow for a gradual upgrade process, where new or changed functionality is introduced in small -- and more manageable -- steps, as opposed to the "huge leaps" between two releases, where one has to cope with a multitude of new things at once -- both as pure number and as variation. That's another reason why I prefer either regularly upgraded systems (like the rolling-release distros) or systems that are never upgraded, save for the most critical patches -- and even then only the ones which are relevant to the specific use. As for the "automatic" transition, if I understand the process correctly, it's just a matter of adding one more variable ("replaces") to the PKGBUILD -- nothing fancy here really and no waste of resources either. And it shouldn't involve any manual work. It's also probably worth mentioning that the transition to -git packages is really more an "organizational" or "administrative" issue at the moment -- the packages are in fact _already_ based on the master ZoL branch (and there's no reasonably simple way to avoid this for the 3.14 kernel as @demizer explained earlier).

WhiteKnight commented on 2014-04-13 12:38 (UTC)

What @kerberizer says makes sense from my point of view. Providing LTS packages for the arch LTS kernel sounds like a good compromise, even thou I'd prefer to have the default (non LTS) kernel on my server. But I'm well aware that I cannot demand anything. :) By the way: Please don't get me wrong; I don't have any problems if the transition would require manual work. And I guess, most users here see it like that, too. So I'd suggest to not waste time and energy for some kind of atuomatic transition.

« First ‹ Previous 1 .. 38 39 40 41 42 43 44 45 46 47 48 .. 79 Next › Last »