-
-
Notifications
You must be signed in to change notification settings - Fork 14.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zfs: 2.2.0 -> 2.2.1; zfsUnstable: 2.2.1-unstable-2023-10-21 -> 2.2.1 #269097
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This release adds support for 6.6 kernels. Please update the versions above in this same file.
@adamcstephens Done! FYI I am also running nixpkgs-review, but needs a bit longer to complete. |
nixpkgs-review output
|
Result of 2 packages marked as broken and skipped:
91 packages built:
|
We also should bump unstable to the same version: https://github.com/NixOS/nixpkgs/blob/3ac3a21f7918b09440debc526a4a3003d6f9edaa/pkgs/os-specific/linux/zfs/unstable.nix |
From 40e9f366584d143e1b748e95c0b668b4842e7499 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= <[email protected]>
Date: Wed, 22 Nov 2023 09:23:11 +0100
Subject: [PATCH] zfsUnstable: 2.2.1-unstable-2023-10-21 -> 2.2.1
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Signed-off-by: Jörg Thalheim <[email protected]>
---
pkgs/os-specific/linux/zfs/unstable.nix | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/pkgs/os-specific/linux/zfs/unstable.nix b/pkgs/os-specific/linux/zfs/unstable.nix
index 9c7e14c31bf3..18d1ae7f9d17 100644
--- a/pkgs/os-specific/linux/zfs/unstable.nix
+++ b/pkgs/os-specific/linux/zfs/unstable.nix
@@ -12,21 +12,20 @@ in
callPackage ./generic.nix args {
# check the release notes for compatible kernels
kernelCompatible = if stdenv'.isx86_64 || removeLinuxDRM
- then kernel.kernelOlder "6.6"
+ then kernel.kernelOlder "6.7"
else kernel.kernelOlder "6.2";
latestCompatibleLinuxPackages = if stdenv'.isx86_64 || removeLinuxDRM
- then linuxKernel.packages.linux_6_5
+ then linuxKernel.packages.linux_6_6
else linuxKernel.packages.linux_6_1;
# this package should point to a version / git revision compatible with the latest kernel release
# IMPORTANT: Always use a tagged release candidate or commits from the
# zfs-<version>-staging branch, because this is tested by the OpenZFS
# maintainers.
- version = "2.2.1-unstable-2023-10-21";
- rev = "95785196f26e92d82cf4445654ba84e4a9671c57";
+ version = "2.2.1";
- sha256 = "sha256-s1sdXSrLu6uSOmjprbUa4cFsE2Vj7JX5i75e4vRnlvg=";
+ sha256 = "sha256-2Q/Nhp3YKgMCLPNRNBq5r9U4GeuYlWMWAsjsQy3vFW4=";
isUnstable = true;
}
--
2.42.0 |
Added zfsUnstable change, ran |
Our tests are not passing, can someone look into them? |
|
Looks like it might be still broken and/or even more broken. The fix appears to maybe be unrelated to block cloning ( It may be better to inject that parameter in since it is incompatible with 2.1 at this point (it appears bug may also be present in 2.1 as well). |
Those tests also worked for me yesterday. |
Ah sorry, the tuneable is meant to resolve the data corruption from block cloning (if it is from block cloning) openzfs/zfs#15526 (comment). But yeah disabling block cloning as well is probably better at this point. v2.2.1 surfaces another problem (on a specific setup) which does not seem to be related. |
I opened #269452 related to this. If you want to continue maintaining the 2.2.x series, please step up in that PR so I can add you. I am not planning to address the 2.2.x series situation as a maintainer of ZFS as I am effectively removing myself from 2.2.x. |
I’ve opened #269465 as an alternative to this PR that only applies the patches to disable block cloning onto 2.2.0 for zfsStable. |
2.2.1 affects users with zfs on LUKS, see openzfs/zfs#15533 Reverting the commit mentioned in openzfs/zfs#15533 (comment) seems to fix it but only the user who bisected it confirmed it so far. Until that gets more testing or investigation I would be more inclined for a 2.2.0 with the patches discussed from openzfs/zfs#15526 |
This comment was marked as duplicate.
This comment was marked as duplicate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At a minimum, I think we need to bump this version to disable block cloning. Then if we want to patch, my thoughts are here: #269465 (comment)
Now supports Kernel 6.6.
Signed-off-by: Jörg Thalheim <[email protected]>
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 openzfs/zfs#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 NixOS#269097. Patch is nearly identical to the [Gentoo][1] patch, but better patch formatting. See openzfs/zfs#11900 See openzfs/zfs#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
I agree; hopefully the upstream PR to fix will be merged early this week and we can backport then. In the meantime I’ve opened #270275 to change the tunable default only, and it is conflict-free with this PR so either can go first. I’ve closed #269465 as well since that doesn’t seem the best course anymore. This PR has also been updated to resolve merge conflicts with master. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been running this 2.2.1 since originally opened. Waiting on last test run to complete.
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-23.11
git worktree add -d .worktree/backport-269097-to-release-23.11 origin/release-23.11
cd .worktree/backport-269097-to-release-23.11
git switch --create backport-269097-to-release-23.11
git cherry-pick -x 365cc96597f674e9c1c70eb08fc84f0d2f9b25b3 55b737831baa6080203ec490a8bfe5f9df420ae0 |
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 openzfs/zfs#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 NixOS#269097. Patch is nearly identical to the [Gentoo][1] patch, but better patch formatting. See openzfs/zfs#11900 See openzfs/zfs#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 (cherry picked from commit 9670ddc)
Description of changes
https://github.com/openzfs/zfs/releases/tag/zfs-2.2.1
Notably:
Things done
nix-build -A zfs.passthru.tests
, and am also running with this patch on x86_64-linux.nix.conf
? (See Nix manual)sandbox = relaxed
sandbox = true
nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD"
. Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/
)Priorities
Add a 👍 reaction to pull requests you find important.