[zfs-2.1.15] Misc backports #15858

tonyhutter · 2024-02-06T20:57:42Z

Motivation and Context

Backports to zfs-2.1.15-staging.

Description

Backport some low-risk features and ZTS updates to zfs-2.1.15-staging.

How Has This Been Tested?

Types of changes

Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Performance enhancement (non-breaking change which improves efficiency)
Code cleanup (non-breaking change which makes code smaller or more readable)
Breaking change (fix or feature that would cause existing functionality to change)
Library ABI change (libzfs, libzfs_core, libnvpair, libuutil and libzfsbootenv)
Documentation (a change to man pages or other documentation)

Checklist:

My code follows the OpenZFS code style requirements.
I have updated the documentation accordingly.
I have read the contributing document.
I have added tests to cover my changes.
I have run the ZFS Test Suite with this change applied.
All commit messages are properly formatted and contain Signed-off-by.

robn · 2024-02-06T21:41:29Z

@tonyhutter do you want 6.6/6.7/6.8 compat patches for 2.1.15? I don't mind either way, I don't need them, but I'd be happy to backport them if you want them.

tonyhutter · 2024-02-06T21:45:19Z

@robn thanks, but I don't think we'll need them. We really only build 2.1.x for EL7-9 now.

rincebrain · 2024-02-06T22:24:18Z

I would personally suggest including the compat patches, not because I particularly plan on using them myself directly, but because it'd be very helpful to be able to keep saying "can you try 2.1.x" a while longer if any more bugs in 2.2.x come up.

I'll also happily do the backports, if need be, I don't think any of them looked exciting, but that's my $0.02.

tonyhutter · 2024-02-06T22:59:42Z

@rincebrain it's ok with me if developers want to backport compat commits into zfs-2.1.15-staging. They can just open a backport PR and we can get them approved pretty quick. Note that we don't build Fedora RPMs for 2.1.x anymore, so those users will need to build from source.

This particular PR is just a backport for some ZED and ZTS commits that I would like to see in zfs-2.1.15-staging.

m-ueberall · 2024-02-07T09:42:06Z

@tonyhutter do you want 6.6/6.7/6.8 compat patches for 2.1.15? I don't mind either way, I don't need them, but I'd be happy to backport them if you want them.

Given that kernel 6.6 is a long-term support version, that'd be great! I'd imagine that this would allow a number of people to delay the switch from 2.1.x to 2.2.x if need be.

AllKind · 2024-02-07T21:22:22Z

I'd like to propose 9ce567c and 95b68eb again.
Since their inclusion into 2.2+ there have been no new error reports in that regard (except one, which is a follow up problem from the previous code).
Also someone else opened a PR for those already (can't find the now though) and @behlendorf proposed it for this upcoming 2.1 release.

behlendorf · 2024-02-07T21:56:59Z

@AllKind thanks for the reminder, these have already been included in the staging branch and will be part of 2.1.15.

Have libzfs call a special `zfs_prepare_disk` script before a disk is included into the pool. The user can edit this script to add things like a disk firmware update or a disk health check. Use of the script is totally optional. See the zfs_prepare_disk manpage for full details. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#15243

There have been rare cases where the VDEV_ENC_SYSFS_PATH value that zed gets passed is stale. To mitigate this, dynamically check the sysfs path at the time of zed event processing, and use the dynamic value if possible. Note that there will be other times when we can not dynamically detect the sysfs path (like if a disk disappears) and have to rely on the old value for things like turning on the fault LED. That is to say, we can't just blindly use the dynamic path in every case. Also: - Add enclosure sysfs entry when running 'zpool add' - Fix 'slot' and 'enc' zpool.d scripts for nvme Reviewed-by: Don Brady <dev.fs.zfs@gmail.com> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#15462

Many tests are failing on AlmaLinux 9 because ZTS could not destroy the pool in cleanup. This was due to $PWD being set to '.' instead of the expected full path. This patch sets $PWD to the full path. Signed-off-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Don Brady <don.brady@delphix.com>

Add a test for the dirty dnode SEEK_HOLE/SEEK_DATA bug described in openzfs#15526 The bug was fixed in openzfs#15571 and was backported to 2.2.2 and 2.1.14. This test case is just to make sure it does not come back. seekflood.c originally written by Rob Norris. Reviewed-by: Graham Perrin <grahamperrin@freebsd.org> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Rob Norris <robn@despairlabs.com> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#15608

Replace ENCLO_US_RE with ENCLO_SU_RE in the name of the variable. Note this changes the user-visible string in zed.rc, thus might break current users with the wrong string, but it's ~2 months since zfs-2.2.0 tag is out, thus should not be widespread yet. Mechanical change: $ grep -rl ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT cmd/zed/zed.d/zed.rc cmd/zed/zed.d/statechange-slot_off.sh $ sed -i 's/ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT/<linebreak> ZED_POWER_OFF_ENCLOSURE_SLOT_ON_FAULT/g' \ cmd/zed/zed.d/zed.rc \ cmd/zed/zed.d/statechange-slot_off.sh $ grep -rl ZED_POWER_OFF_ENCLOUSRE_SLOT_ON_FAULT $ Fixes 11fbcac ("zed: Add zedlet to power off slot when drive is faulted") Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Mauricio Faria de Oliveira <mfo@canonical.com> Closes openzfs#15651

Add `zpool` flags to control the slot power to drives. This assumes your SAS or NVMe enclosure supports slot power control via sysfs. The new `--power` flag is added to `zpool offline|online|clear`: zpool offline --power <pool> <device> Turn off device slot power zpool online --power <pool> <device> Turn on device slot power zpool clear --power <pool> [device] Turn on device slot power If the ZPOOL_AUTO_POWER_ON_SLOT env var is set, then the '--power' option is automatically implied for `zpool online` and `zpool clear` and does not need to be passed. zpool status also gets a --power option to print the slot power status. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Reviewed-by: Mart Frauenlob <AllKind@fastest.cc> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#15662

When very large pools are present, it can be laborious to find reasons for why a pool is degraded and/or where an unhealthy vdev is. This option filters out vdevs that are ONLINE and with no errors to make it easier to see where the issues are. Root and parents of unhealthy vdevs will always be printed. Testing: ZFS errors and drive failures for multiple vdevs were simulated with zinject. Sample vdev listings with '-e' option - All vdevs healthy NAME STATE READ WRITE CKSUM iron5 ONLINE 0 0 0 - ZFS errors NAME STATE READ WRITE CKSUM iron5 ONLINE 0 0 0 raidz2-5 ONLINE 1 0 0 L23 ONLINE 1 0 0 L24 ONLINE 1 0 0 L37 ONLINE 1 0 0 - Vdev faulted NAME STATE READ WRITE CKSUM iron5 DEGRADED 0 0 0 raidz2-6 DEGRADED 0 0 0 L67 FAULTED 0 0 0 too many errors - Vdev faults and data errors NAME STATE READ WRITE CKSUM iron5 DEGRADED 0 0 0 raidz2-1 DEGRADED 0 0 0 L2 FAULTED 0 0 0 too many errors raidz2-5 ONLINE 1 0 0 L23 ONLINE 1 0 0 L24 ONLINE 1 0 0 L37 ONLINE 1 0 0 raidz2-6 DEGRADED 0 0 0 L67 FAULTED 0 0 0 too many errors - Vdev missing NAME STATE READ WRITE CKSUM iron5 DEGRADED 0 0 0 raidz2-6 DEGRADED 0 0 0 L67 UNAVAIL 3 1 0 - Slow devices when -s provided with -e NAME STATE READ WRITE CKSUM SLOW iron5 DEGRADED 0 0 0 - raidz2-5 DEGRADED 0 0 0 - L10 FAULTED 0 0 0 0 external device fault L51 ONLINE 0 0 0 14 Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Cameron Harr <harr1@llnl.gov> Closes openzfs#15769

CVE-2020-24370 is a security vulnerability in lua. Although the CVE description in CVE-2020-24370 said that this CVE only affected lua 5.4.0, according to lua this CVE actually existed since lua 5.2. The root cause of this CVE is the negation overflow that occurs when you try to take the negative of 0x80000000. Thus, this CVE also exists in openzfs. Try to backport the fix to the lua in openzfs since the original fix is for 5.4 and several functions have been changed. GHSA-gfr4-c37g-mm3v https://nvd.nist.gov/vuln/detail/CVE-2020-24370 https://www.lua.org/bugs.html#5.4.0-11 lua/lua@a585eae Reviewed-by: Tony Hutter <hutter2@llnl.gov> Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: ChenHao Lu <18302010006@fudan.edu.cn> Closes openzfs#15847

The zfs_load-key tests were failing on F39 due to their use of the deprecated ssl.wrap_socket function. This commit updates the test to instead use ssl.SSLContext() as described in https://stackoverflow.com/a/65194957. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Tony Hutter <hutter2@llnl.gov> Closes openzfs#15534 Closes openzfs#15550

Update ABI files from latest CI run results (for zfs-2.1.15) Signed-off-by: Tony Hutter <hutter2@llnl.gov>

mmatuska · 2024-02-10T09:30:03Z

Please backport 07e95b4 (#15716), it fixes FreeBSD userspace build after #15662
This is the same for 2.1.x as it was for 2.2.x

- Mark some parameters to zpool_power*() as unused. - Add a stub zpool_disk_wait(). Fixes: a9520e6 ("zpool: Add slot power control, print power status") Signed-off-by: Mark Johnston <markj@FreeBSD.org> Reviewed-by: Alexander Motin <mav@FreeBSD.org> Reviewed-by: Tony Hutter <hutter2@llnl.gov>

tonyhutter · 2024-02-12T17:25:41Z

@mmatuska sorry I missed that one! I included it in my latest push.

tonyhutter added 4 commits February 8, 2024 13:42

tonyhutter force-pushed the backport215 branch from 0eacb56 to 44a2b9f Compare February 8, 2024 21:45

tonyhutter force-pushed the backport215 branch from 44a2b9f to e23bb01 Compare February 8, 2024 21:56

tonyhutter and others added 4 commits February 8, 2024 14:39

tonyhutter force-pushed the backport215 branch from e23bb01 to eac6f61 Compare February 8, 2024 22:45

[zfs-2.1.15] Update ABI files

7643c7c

Update ABI files from latest CI run results (for zfs-2.1.15) Signed-off-by: Tony Hutter <hutter2@llnl.gov>

tonyhutter force-pushed the backport215 branch from eac6f61 to 7643c7c Compare February 9, 2024 00:47

behlendorf approved these changes Feb 13, 2024

View reviewed changes

behlendorf merged commit 4a0d86a into openzfs:zfs-2.1.15-staging Feb 13, 2024
8 of 11 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[zfs-2.1.15] Misc backports #15858

[zfs-2.1.15] Misc backports #15858

tonyhutter commented Feb 6, 2024

robn commented Feb 6, 2024

tonyhutter commented Feb 6, 2024

rincebrain commented Feb 6, 2024

tonyhutter commented Feb 6, 2024 •

edited

Loading

m-ueberall commented Feb 7, 2024 •

edited

Loading

AllKind commented Feb 7, 2024

behlendorf commented Feb 7, 2024

mmatuska commented Feb 10, 2024 •

edited

Loading

tonyhutter commented Feb 12, 2024

[zfs-2.1.15] Misc backports #15858

[zfs-2.1.15] Misc backports #15858

Conversation

tonyhutter commented Feb 6, 2024

Motivation and Context

Description

How Has This Been Tested?

Types of changes

Checklist:

robn commented Feb 6, 2024

tonyhutter commented Feb 6, 2024

rincebrain commented Feb 6, 2024

tonyhutter commented Feb 6, 2024 • edited Loading

m-ueberall commented Feb 7, 2024 • edited Loading

AllKind commented Feb 7, 2024

behlendorf commented Feb 7, 2024

mmatuska commented Feb 10, 2024 • edited Loading

tonyhutter commented Feb 12, 2024

tonyhutter commented Feb 6, 2024 •

edited

Loading

m-ueberall commented Feb 7, 2024 •

edited

Loading

mmatuska commented Feb 10, 2024 •

edited

Loading