Arch Linux User Repository

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

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

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

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

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

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!

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

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 ?

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.