Arch Linux User Repository

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!

@demizer: I fully support what you've written. It's not only a potentially tedious work patching the ZoL releases for each new kernel, but it's also probably more risky in terms of stability, since this is not something that is necessarily widely tested outside of the Arch Linux community. Thus, somewhat paradoxically, the "stable" packages might actually be less stable than the -git ones. So, I'd also vote for moving towards -git (and supporting the -lts as well for those who really need stability). Concerning the zfs, zfs-utils, spl and spl-utils packages, it might indeed be better to delete them in favour of the -git ones. My reasoning is based mainly on version problems. If we are to follow Git master, it becomes quite important on which exactly snapshot of the source tree the package is based, especially during times of high commit activity, when the timestamp of the package can't be used as a more or less reliable indicator. Simply put, the -git type versioning (e.g. 0.6.2.r253.g888f714_3.14-1) is very desirable anyway. I don't have much experience with this, but I suppose we could also use the "replaces" array in the PKGBUILD to have the transition done smoothly for the people who use the repos (that's partially in reply to the question by @WhiteKnight).

What effect would that have on your repo? ([demz-repo-core])

I would vote for using -git packages since that would match the Arch way better. since I'm abroad (in Brazil, home server is in Los Angeles) and / is mounted read only, I will play safe for a while and not try anything that requires a reboot..... but back to topic, I would be willing to help prepare a testing environment (vagrant and virtualbox come to mind) to aid testing releases, if that would be helpful and easy to work with. Thanks for the great work!

@kerberizer, yes I have been thinking about this as well. These packages are now essentially similar to zfs-linux-git. I'm not sure if that is right. Since ZFSonLinux.org takes a long time between releases, the release based model would not work for Arch Linux since Arch uses the newest kernel ASAP. These packages would only be viable on every new ZOL release, after that kernel updates would require the use of patches to fix kernel API changes, which is the method we have deployed until now. The API changes for 3.14 were fixed in the ZOL master branch, but was built upon all of the previous changes over an 8 month period, so there was no easy simple patch to pull in as was done before. So technically, the best solution would be to just build ZFS from git everytime. This is what the gentoo guys do. I'm not sure if we should delete the zfs, zfs-utils, spl, spl-utils packages in AUR and just use zfs-git, zfs-utils-git, spl-git, and spl-utils-git? Since the release based zfs packages won't work on Arch. Let me know what you all think guys! Thanks, Jesus A.

@demizer: Are you going to keep following master (i.e. not stick to the "release" tags, like 0.6.3) in the future? I remember you doing that in the past, but then at some point you switched to the 0.6.2 tag. I'm asking because I'm almost ready with a set of {spl,zfs}-{utils,modules}-git packages for those who want to follow the Git master, but this now seems redundant.

So this latest update does use a patch to make the code current to git master. As Arch is bleeding edge, so must be these packages, it is the only way. The master branch of the ZOL git repo is stable. Users that don't feel comfortable using bleeding edge, should use the linux-lts packages. I'm sorry about the rw kernel parameter change, I should have vetted it more before adding it to the repo, and definitely should not have changed it right before going out on surgery. Once I feel physically comfortable I will work on linux-lts packages as well as closing some of the issues in the archzfs repo.

@puithove: Hm, do you have the "rw" kernel parameter set in your bootloader? This hasn't been required until very recently (it is also due to a change in the ZFS initcpio hook, not in the ZoL code itself; see https://github.com/demizer/archzfs/commit/2ba64814e1)

To get by for now, it looks like it'll work if I go with mountpoint=legacy on my root filesystem dataset, and put it in fstab. Not the way it should have to be but... Everything else seems to be working as far as I can see.

I decided to try this update. Unfortunately I'm running into an issue. I have my root filesystem on zfs. Now after the update, everything still mounts and I'm able to get logged in, but my root fs is mounted read-only. If I check properties, I see "readonly=on" and the source is "temporary". If I do zfs inherit readonly or zfs set readonly=off it'll remount as rw, but by that point of course my boot is screwed and most stuff isn't running. Looks like temporary properties are something new to zfsonlinux according to this that I found: https://github.com/zfsonlinux/zfs/issues/985 - I wonder if something new needs to be added to the boot sequence to get the root remounted as rw.

does this incorporate everything from 0.6.2 to git HEAD? think I'll wait for 0.6.3 in that case, unless we get a minimal backport in another package or something.