Age | Commit message (Collapse) | Author | Files | Lines |
|
zfs_unstable: 2.2.4 → 2.2.4-unstable-2024-05-13
|
|
|
|
|
|
Now compatible with Linux 6.8.
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.4
Need to patch py-libzfs to support incompatible API change.
|
|
No pre-release version at this moment, so use now-released 2.2.4.
|
|
|
|
|
|
|
|
Has patch to fix 6.8 issue
|
|
zfs: rename zfsStable -> zfs_2_2; zfsUnstable -> zfs_unstable; remove enableUnstable option in favor of package
|
|
This just adds complexity and confusion. Once-upon-a-time, there was no
`package` and only `enableUnstable`, but now it is just confusing to
have both, as it would be possible to do e.g. `package = pkgs.zfs` and
`enableUnstable = true`, but then `enableUnstable` does nothing.
|
|
This matches the naming of other zfs_* pkgs.
|
|
The `zfs` alias already has equivalent semantics. Instead, make this
like zfs_2_1 so folks who want to pin a specific release series can do
so easily and clearly to have more control over when more substantial
updates occur.
Rename all tests to match the pkg attr they are testing.
|
|
This adds compatibility with newer kernels, which fixes
nixosTests.zfs.series_2_1, which broke when the default kernel version
was bumped.
This means we no longer need the removeLinuxDRM option at all, but
I've kept it around as a no-op so people can leave it set in case the
same thing happens again in future.
|
|
ZFS no longer tries to use GPL-only symbols on aarch64.
Tested by building nixosTests.zfs.stable (modified to use Linux 6.6)
and nixosTests.zfs.unstable.
|
|
|
|
Patch now includes compatibility for 6.8 kernels (even if ðey aren’t on
offer in nixpkgs at ðis time).
|
|
Should have patches for 6.7 compatibility
|
|
|
|
|
|
zfs: default disable zfs_dmu_offset_next_sync to avoid data corruption
|
|
This helps mitigate a data corruption bug. This was previously defaulted
to zero prior to upstream commit
05b3eb6d232009db247882a39d518e7282630753, and it is already a tunable,
so doing this seems safe. Initially data corruption was thought to be
introduced with v2.2, but further upstream investigation currently
believes that changes in v2.2 only exacerbated the issue that already
existed.
A longer-term fix is likely to be
https://github.com/openzfs/zfs/pull/15571, though that is not yet
merged. The zfs_2_1 package has already backported that, so do not apply
the tunable default change there.
Positioning of `extraPatches` is to avoid merge conflicts with
https://github.com/NixOS/nixpkgs/pull/269097.
Patch is nearly identical to the [Gentoo][1] patch, but better patch
formatting.
See https://github.com/openzfs/zfs/issues/11900
See https://github.com/openzfs/zfs/issues/15526
[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-fs/zfs-kmod/files/zfs-kmod-2.2.1-Disable-zfs_dmu_offset_next_sync-tunable-by-default.patch
|
|
Signed-off-by: Jörg Thalheim <joerg@thalheim.io>
|
|
Now supports Kernel 6.6.
|
|
When we are building for user or kernel, we are not building a kernel module all the time.
|
|
This re-introduces the old stable ZFS version we had in the past following
the many predicted issues of ZFS 2.2.x series, that is much more stable
than any further ZFS version at the moment.
I am also removing myself from maintenance of any further ZFS versions as I am
planning to quit ZFS maintenance at some point.
In the meantime, for users like me who depend on ZFS for critical operations, here is a ZFS version
that is known to work for LTS kernels.
|
|
|
|
|
|
|
|
Otherwise configuring runs some test builds with `nproc` amount of cores.
|
|
|
|
It's still in kernels-org.json, because even if I remove it the update
script will keep putting it back, but nothing references it, and it'll
be removed from that file when kernels are next updated after it's
been delisted from kernel.org.
linux_testing_bcachefs still needs to be updated for >6.4, so for now
I've just inlined the Linux 6.4 definition in linux_testing_bcachefs's
definition.
|
|
|
|
|
|
https://github.com/openzfs/zfs/commits/zfs-2.1.13-staging
With anecdote from a NixOS user that it’s working
https://github.com/openzfs/zfs/pull/15125
…working for me as well as I built+booted from this commit.
|
|
|
|
Introduced in https://github.com/torvalds/linux/commit/aaeca98456431a8d9382ecf48ac4843e252c07b3
with the usual disdain for ZFS.
We have been there in the past with
<https://www.phoronix.com/news/NixOS-Linux-5.0-ZFS-FPU-Drop> /
https://github.com/NixOS/nixpkgs/pull/61076.
This fixes ZFS on aarch64 until the next breakage.
See https://github.com/openzfs/zfs/issues/14555 for original upstream
issue.
|
|
|
|
EOL
|
|
|
|
zfs.meta.platforms: restrict to upstream-supported $TARGET_CPUs
|
|
|
|
|
|
We do not have callPackages (notice the s) for kernel packages. Hence
it's not override zfs dependencies as we do not have an override
function. This is fixed by splitting of the file into a generic builder
function and 2 files for zfsStable and zfsUnstable.
|
|
zfs: 2.1.9 → 2.1.11
|
|
Skipping over 2.1.10 now that it was found to have possible data
corruptions
Release notes @ OpenZFS’s Git forge: https://github.com/openzfs/zfs/releases/tag/zfs-2.1.11
|
|
When ZFS is built with cURL, it allows retrieving encryption keys from
URLs automatically.
|
|
|
|
Patched from https://github.com/openzfs/zfs/pull/14668
|
|
|