OpenZFS/src e8e3076include/os/linux/zfs/sys zfs_vfsops_os.h zfs_ctldir.h, module/os/linux/zfs zfs_vfsops.c zpl_ctldir.c

Linux: rewrite snapshot automount facility

This commit has a near-total rewrite of the snapshot mount/expire
facility, to try and modernise it, fix a lot of structural and
implementation issues and improve performance.

Because its a change in architecture, not just implementation, it's not
really been possible to incrementally move the implementation from the
old to the new. So, the source commentary is intended as a standalone
description of how it all works, while this commit message describes
what's changed for readers who know the previous version.

The main conceptual difference is that the previous version assumed that
there would only ever be one mount per snapshot dataset at most, and
that that mount would be on the matching `.zfs/snapshot/<snapname>`
mountpoint, and that this subsystem would be the one responsible for
unmounting. Those limitations just don't exist, as Linux mounts can be
duplicated, moved around, attached to other namespaces, even deleted,
without actually removing access to the filesystem and all without the

    [100 lines not shown]
DeltaFile
+878-725module/os/linux/zfs/zfs_ctldir.c
+403-40module/os/linux/zfs/zpl_ctldir.c
+62-0include/os/linux/zfs/sys/zpl.h
+9-8include/os/linux/zfs/sys/zfs_ctldir.h
+4-12module/os/linux/zfs/zfs_vfsops.c
+1-1include/os/linux/zfs/sys/zfs_vfsops_os.h
+1,357-7866 files

OpenZFS/src b55f7f3config kernel.m4 kernel-workqueue.m4, include/os/linux Makefile.am

Linux 5.19/6.17: handle differences in how to flush delay workqueue

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+77-0config/kernel-workqueue.m4
+41-0include/os/linux/kernel/linux/workqueue_compat.h
+2-0config/kernel.m4
+1-0include/os/linux/Makefile.am
+121-04 files

OpenZFS/src a2a6458config kernel.m4 kernel-follow-down-one.m4, include/os/linux/kernel/linux vfs_compat.h

Linux 6.3: follow_down() gains flags arg

We need the flags arg to trigger the snapshot mount. For earlier
kernels, we can emulate it with vfs_path_lookup()

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+70-0config/kernel-follow-down.m4
+36-0include/os/linux/kernel/linux/vfs_compat.h
+0-23config/kernel-follow-down-one.m4
+2-2config/kernel.m4
+108-254 files

OpenZFS/src 50b7b50config kernel.m4 kernel-fs-context.m4, include/os/linux/kernel/linux vfs_compat.h

Linux 6.18 compat: vfs_parse_fs_string() takes 3 args

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+25-0config/kernel-fs-context.m4
+10-0include/os/linux/kernel/linux/vfs_compat.h
+2-0config/kernel.m4
+37-03 files

OpenZFS/src f11ec72tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: test that a foreign mount on the snapdir can be detached

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+50-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_foreign.ksh
+1-1tests/runfiles/linux.run
+1-0tests/zfs-tests/tests/Makefile.am
+52-13 files

OpenZFS/src 1a9f0b5tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: test that ongoing access doesn't prevent snapdir detach

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+80-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_fd_hold.ksh
+1-1tests/runfiles/linux.run
+1-0tests/zfs-tests/tests/Makefile.am
+82-13 files

OpenZFS/src 11d5900tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: test multiple snapshot automounts via multiple base dataset mounts

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+68-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_multiple.ksh
+2-1tests/runfiles/linux.run
+1-0tests/zfs-tests/tests/Makefile.am
+71-13 files

OpenZFS/src 3101e16tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: test snapdir shutdown behaviour when automount is moved elsewhere

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+70-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_expire_move.ksh
+64-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_move.ksh
+2-1tests/runfiles/linux.run
+2-0tests/zfs-tests/tests/Makefile.am
+138-14 files

OpenZFS/src 626dca3tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: test snapdir shutdown behaviour when automount is bound elsewhere

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+65-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_expire_bind.ksh
+59-0tests/zfs-tests/tests/functional/snapdir/snapdir_mount_bind.ksh
+1-1tests/runfiles/linux.run
+2-0tests/zfs-tests/tests/Makefile.am
+127-14 files

OpenZFS/src 32f4b3atests/zfs-tests/tests/functional/snapdir snapdir_admin_create_destroy.ksh

ZTS: snapdir_admin_create_destroy: use makedir helper

The rust-coreutils (uutils) mkdir calls llistxattr() immediately after
calling mkdir(), which triggers the automount, and so prevents rmdir
from seeing and deleting the mountpoint dir.

Switching over to our helper that we know only calls mkdir() fixes that
up.

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847
DeltaFile
+1-1tests/zfs-tests/tests/functional/snapdir/snapdir_admin_create_destroy.ksh
+1-11 files

OpenZFS/src 1c696d0tests/zfs-tests/cmd Makefile.am .gitignore, tests/zfs-tests/include commands.cfg

ZTS: makedir helper command

The system mkdir command may do other things besides the mkdir()
syscall, which is a problem when we're trying to test the syscall
specifically. This helper only does the mkdir() syscall.

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18847:w
DeltaFile
+33-0tests/zfs-tests/cmd/makedir.c
+2-1tests/zfs-tests/cmd/.gitignore
+1-0tests/zfs-tests/include/commands.cfg
+1-0tests/zfs-tests/cmd/Makefile.am
+37-14 files

OpenZFS/src a515918etc/systemd/system zfs-volume-wait.service.in zfs-mount@.service.in

Make systemd-udev-settle optional for the import units

systemd-udev-settle.service has been deprecated for years, recent
systemd releases warn about it at boot, and distributions have begun
shipping without it, which turns the hard Requires= in
zfs-import-cache and zfs-import-scan into a broken import: a
Requires= on a masked or removed unit keeps the service from ever
starting.  Issue #10891.

Demote the dependency to Wants= and keep the After= ordering.  Where
the settle unit exists and completes, the boot is what it always
was: Wants= pulls settle in, the import waits for it, and the
device-symlink guarantee it provided is intact.  Where it is masked
or gone the wish is quietly dropped and the import runs anyway,
which beats not importing at all.  One deliberate behavior change:
if settle itself fails, on a system so large that enumeration
overruns its timeout, the old Requires= cancelled the import while
the new units go ahead at the timeout mark with whatever has been
enumerated by then.

    [29 lines not shown]
DeltaFile
+3-1etc/systemd/system/zfs-import-scan.service.in
+3-1etc/systemd/system/zfs-import-cache.service.in
+0-1etc/systemd/system/zfs-volume-wait.service.in
+0-1etc/systemd/system/zfs-mount@.service.in
+0-1etc/systemd/system/zfs-mount.service.in
+6-55 files

OpenZFS/src fd1ae59module/zfs ddt.c

DDT: Skip DDT log lookups in ddt_prune_walk()

DDT log is not explicitly locked, and serialized only by the TXG
sync process.  Since that stage of ddt_prune_walk() is not in sync
with the TXG sync process, we can't access the DDT log there.  We
could possibly lock it, but it seems we can just skip it, since it
is only a performance optimization, while the final LOG lookup is
be done by prune_candidates_sync() any way.

Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #18889
DeltaFile
+0-7module/zfs/ddt.c
+0-71 files

OpenZFS/src 5d687a9cmd ztest.c, module/zfs dbuf.c

dbuf: use dirty record size for overridden writes

A level-0 dirty record retains its ARC buffer after dmu_sync() writes it
for an indirect ZIL record. If a newer transaction group changes the
block size before the older one syncs, that retained buffer and the live
dbuf legitimately have different sizes.

The normal fallback is reachable when encryption and dedup are enabled.
dmu_sync() keeps the dedup checksum for the override BP. Syncing-context
policy then enables dedup, but zio_write_bp_init() cannot reuse an
encrypted dedup override and restores the regular write pipeline.

dbuf_write() built its ABD from the retained buffer but passed the live
dbuf size to ZIO. After growth, compression can therefore read beyond
the retained allocation. After shrink, the older transaction group's
block is instead written with the newer, smaller LSIZE and truncated
data.

This was observed as a 527 KiB compression request against a retained

    [20 lines not shown]
DeltaFile
+321-40cmd/ztest.c
+21-6module/zfs/dbuf.c
+342-462 files

OpenZFS/src 7312322module/nvpair nvpair.c

nvpair: Fix operator precedence

59dc88602e23a436440e4164c6d9401da8f0dff2 made a mistake when doing a
check, which can cause us to continue processing when we should return
EFAULT.

Reported-by: Grok 4.5 Build Beta
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Richard Yao <richard at ryao.dev>
Closes #18874
DeltaFile
+1-1module/nvpair/nvpair.c
+1-11 files

OpenZFS/src bd336d3tests/test-runner/include logapi.shlib

ZTS: don't read a command's exit status as a missing binary

log_neg_expect() treats an exit status of 127 as a missing binary and
fails before it looks at what the command printed.  That is only a
convention of the shell, and a command is free to return 127 for its
own reasons.  fio returns the number of jobs which failed, so a run of
127 failing jobs is reported as though fio were not installed.

no_space/enospc_rm fills a pool with 200 fio jobs and requires them to
fail with ENOSPC.  How many of them get that far varies with timing,
and on the occasions it comes to exactly 127 the test fails with

  fio ... unexpectedly exited 127 (File not found)

even though the output holds the expected message.  A dozen runs here
landed between 183 and 199, and the failure seen in CI reported 127.

Only read 127 as a missing binary when the expected output is absent.
A command which printed what was asked of it plainly ran, so nothing

    [5 lines not shown]
DeltaFile
+13-1tests/test-runner/include/logapi.shlib
+13-11 files

OpenZFS/src d135209tests/unit .gitignore Makefile.am

unit/cityhash: test the cityhash hash functions

Cover known answers, the 1/2/3-argument specialized forms against
cityhash4, and distinct inputs.

Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18880
DeltaFile
+100-0tests/unit/test_cityhash.c
+15-1tests/unit/Makefile.am
+1-0tests/unit/.gitignore
+116-13 files

OpenZFS/src 0a932e9tests/unit test_sha2.c

unit/sha2: add Monte Carlo test

SHAVS chain MD[i] = SHA(MD[i-3] || MD[i-2] || MD[i-1]) run for 1000
rounds, for SHA-256, SHA-512 and SHA-512/256.  The seeds and expected
digests are the COUNT = 0 vectors from the NIST CAVP byte-oriented test
vectors (shabytetestvectors).

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18879
DeltaFile
+90-0tests/unit/test_sha2.c
+90-01 files

OpenZFS/src 0d837d3config zfs-meta.m4

build: Fix release detection when build dir is not source dir

When building outside of the root source directory, configure fails to
detect that the source for the build is a git repository because the
build directory is checked if it is a git repository. Instead check
source directory and use the source directory for generating the
release. Check for the .nogitrelease file in the source directory too.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Glenn Washburn <development at efficientek.com>
Closes #18891
DeltaFile
+3-3config/zfs-meta.m4
+3-31 files

OpenZFS/src bc87c1f.github/workflows/scripts qemu-6-tests.sh

CI: don't fail a passing job when a log reader has already exited

Once a VM's tests finish the runner kills that VM's log reader.  If the
reader is already gone, kill reports ESRCH, and since the script runs
under set -eu that ends it and the job is reported failed after the
tests have already passed.

That is what turned the fedora44 run in
https://github.com/openzfs/zfs/actions/runs/30772421272 red:

  vm1: Results Summary
  vm1: PASS  1151
  vm1: FAIL     2
  vm1: SKIP     6
  ...
  qemu-6-tests.sh: line 143: kill: (20700) - No such process
  ##[error]Process completed with exit code 1.

All 13 failures in that run were on the expected list and neither VM

    [13 lines not shown]
DeltaFile
+4-1.github/workflows/scripts/qemu-6-tests.sh
+4-11 files

OpenZFS/src eddc536.github/workflows/scripts qemu-6-tests.sh

CI: publish the per-VM test counter atomically

Each VM's log reader keeps a running test count in /tmp/ctr-vm$ID and
reads every other VM's counter to print the combined progress figure.
The counter is published with a plain redirect, which truncates the file
before it writes, so a reader can see it empty.  `read` then returns 1,
and because the reader inherits set -eu that ends the reader subshell.

The VM keeps running and its results are recovered later from the
artifact, but its output stops being prefixed into the live log from
that point on, with nothing said about why.

Seen on fedora44 in
https://github.com/openzfs/zfs/actions/runs/30772421272.  vm2's last
prefixed line is refreserv/cleanup at 01:57, carrying counter 745, while
vm1 keeps reporting vm2 frozen at 746 for the remaining 38 minutes: the
reader incremented the counter and died before printing that line.  vm2
itself ran on until 02:14 and its 899/11/6 summary never reached the
live log.

    [9 lines not shown]
DeltaFile
+7-1.github/workflows/scripts/qemu-6-tests.sh
+7-11 files

OpenZFS/src 90cdd9aman/man4 zfs.4, module/zfs dmu_recv.c

Batch object reallocation syncs in zfs receive

When an incremental stream reallocates an object at a different dnode
slot count, receive_object() must wait for the old dnode's free to
sync out before the object number can be claimed again, because
dnode_check_slots_free() only accepts slots whose final dirty txg has
synced.  The receive writer did this with one txg_wait_synced() per
reallocated object, so a dataset that ever changed dnodesize (for
example dnodesize=auto, as the root-on-ZFS guides suggest) receives
such incrementals at a few KB/s while the pool syncs mostly empty
txgs (#11353).

Batch those waits.  The frees are still issued immediately, since
many frees can share one txg, but the record whose claim would need
the sync is parked on a per-receive list and the affected dnode slot
ranges are tracked in a small AVL tree.  Later records that touch a
parked range park behind it in stream order while unrelated records
keep flowing.  Once the batch reaches zfs_recv_defer_batch_size
(default 32 MB, 0 restores the old behavior) or the stream ends, a

    [38 lines not shown]
DeltaFile
+576-21module/zfs/dmu_recv.c
+113-0tests/zfs-tests/tests/functional/rsend/send_realloc_dnode_mixed.ksh
+95-0tests/zfs-tests/tests/functional/rsend/send_realloc_dnode_resume.ksh
+19-0man/man4/zfs.4
+2-1tests/runfiles/linux.run
+2-1tests/runfiles/common.run
+807-232 files not shown
+810-238 files

OpenZFS/src 3ebf3ffinclude/sys dsl_pool.h, module/zfs brt.c ddt.c

Predict and throttle buffers dirtied by the sync context

Block cloning may cause lots of dirty buffers in the sync context
for BRT/DDT updates, while in open context dirtying only indirect
blocks, and so remaining almost invisible for write throttling.
With active cloning I was able to make dirty reach 16GB and more
while having the limit of only 4GB.

In case of cloned/deduped blocks delete the problem is not so bad,
thanks to zfs_max_async_dedup_frees limit.  But on smaller systems
or with higher tunable setting it might still be a problem.

To handle the cloning make dmu_tx_count_clone() predict amount
of the dirty buffers that might be produced by the sync context
for this transaction, summarise those for each transaction group,
and account them in write throttling as real dirty buffers.
When sync context as part of DDT/BRT writing start dirtying MOS
buffers, subtract that dirty from the predicted reserve.  This way
completions of the DDT/BRT write ZIOs will gradually open the

    [14 lines not shown]
DeltaFile
+84-2module/zfs/dsl_pool.c
+27-10module/zfs/dmu_tx.c
+28-0module/zfs/dsl_scan.c
+14-0module/zfs/ddt.c
+13-0module/zfs/brt.c
+5-0include/sys/dsl_pool.h
+171-126 files not shown
+183-1512 files

OpenZFS/src 6271e80man/man4 zfs.4

man: zvol_request_sync is not ignored under blk-mq

The zfs.4 entry for zvol_request_sync claims it "is ignored when
running on a kernel that supports block multiqueue (blk-mq)". This
has never been true. The sentence and the blk-mq support it describes
landed in the same commit (6f73d0216 "zvol: Support blk-mq for better
performance"), which added

        if (zvol_request_sync)
                force_sync = 1;

to zvol_request_impl() -- the function shared by both submission
paths, reached from zvol_submit_bio() and from zvol_mq_queue_rq()
alike. No blk-mq guard was added there then, and none exists now.

Taken literally the sentence is worse than inaccurate: HAVE_BLK_MQ
was removed in 9601eeea1 because every supported kernel has blk-mq,
so the documented condition is always satisfied and the parameter
would never do anything.

    [18 lines not shown]
DeltaFile
+3-3man/man4/zfs.4
+3-31 files

OpenZFS/src f454858cmd/zstream zstream.h Makefile.am, man/man8 zstream.8

zstream: Add zstream raw command

Introduce a "zstream raw" command.

This command allows zvol send streams to be applied to a raw disk image
or block device, with support for incremental sends and compression.

Encrypted (raw) streams are not supported, but compression, large
blocks, and embedded write records are handled.

Contiguous writes can optionally be buffered and issued together with
pwritev(2).

Block devices supporting TRIM/UNMAP use the platform-appropriate
BLKDISCARD or SIOCGDELETE ioctl to handle FREE records.

Raw file volume images use the platform-appropriate hole punching
operation to handle FREE records if supported by the underlying
filesystem.

    [7 lines not shown]
DeltaFile
+532-0cmd/zstream/zstream_raw.c
+187-0tests/zfs-tests/tests/functional/zstream/zstream_raw_001_pos.ksh
+45-1man/man8/zstream.8
+5-0cmd/zstream/zstream.c
+1-0cmd/zstream/zstream.h
+1-0cmd/zstream/Makefile.am
+771-12 files not shown
+773-18 files

OpenZFS/src 56a82c8cmd/zstream zstream_redup.c zstream_recompress.c

zstream: Annotate zstream_usage as noreturn

And remove dead code following its use.

Sponsored-by: Klara, Inc.
Sponsored-by: Railway Corporation
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Garth Snyder <garth at garthsnyder.com>
Signed-off-by: Ryan Moeller <ryan.moeller at klarasystems.com>
Closes #18565
DeltaFile
+1-4cmd/zstream/zstream_drop_record.c
+1-4cmd/zstream/zstream_decompress.c
+0-2cmd/zstream/zstream_dump.c
+1-1cmd/zstream/zstream.h
+0-1cmd/zstream/zstream_redup.c
+0-1cmd/zstream/zstream_recompress.c
+3-136 files

OpenZFS/src bc18982tests/runfiles common.run linux.run, tests/zfs-tests/cmd Makefile.am

ZTS: Enable compress_004_pos on FreeBSD

Use fspacectl(2) on FreeBSD to do hole punching for randfree_file and
build it on both platforms.  With this, compress_004_pos can be moved to
the common runfile.

Sponsored-by: Klara, Inc.
Sponsored-by: Railway Corporation
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Garth Snyder <garth at garthsnyder.com>
Signed-off-by: Ryan Moeller <ryan.moeller at klarasystems.com>
Closes #18565
DeltaFile
+4-13tests/zfs-tests/tests/functional/compression/compress_004_pos.ksh
+10-1tests/zfs-tests/cmd/file/randfree_file.c
+2-4tests/zfs-tests/cmd/Makefile.am
+0-4tests/runfiles/linux.run
+1-0tests/runfiles/common.run
+17-225 files

OpenZFS/src 3bd8ceflib/libzfs libzfs_sendrecv.c

libzfs: don't read a dataset handle after closing it in resume send

zfs_send_resume_impl_cb_impl() closes the dataset handle before its
error switch and then reads zhp->zfs_name again in the ESRCH case.
zfs_name is an array declared inside struct zfs_handle, so the free()
at the end of zfs_close() releases it along with the handle, and
lzc_exists() copies out of the freed block.

The close dates from the original resume send.  The ESRCH case was added
three years later with redacted send, below a handle that was no longer
live.  The path is reachable: dsl_bookmark_lookup() returns ESRCH when
the incremental source is a bookmark that has gone away, which a resume
can lose a race with.

Keep a copy of the name alongside the error message that is already
formatted before the close, and test that instead.

Reported-by: RigelYoung <43904538+RigelYoung at users.noreply.github.com>
Reviewed-by: Rob Norris <rob.norris at truenas.com>

    [4 lines not shown]
DeltaFile
+3-1lib/libzfs/libzfs_sendrecv.c
+3-11 files

OpenZFS/src 674b1aeinclude/sys zap.h, module/zfs ddt_zap.c zap.c

DDT: Make ddt_zap_walk() use cursor _by_dnode functions

ddt_zap_walk() already receives dnode as an argument.  We can save
one dnode_hold() per entry by using _by_dnode cursor functions.
zap_cursor_init_noprefetch_by_dnode() is added in the process.

Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18888
DeltaFile
+6-0module/zfs/zap.c
+2-3module/zfs/ddt_zap.c
+1-0include/sys/zap.h
+9-33 files

OpenZFS/src 845cd96tests/runfiles linux.run, tests/zfs-tests/tests Makefile.am

ZTS: add coverage for the MMP claim on a degraded mirror

Add mmp_degraded_import, which verifies the uberblock claim requires a
write only to those mirror legs the pool configuration still expects to
be present.  A healthy mirror is claimed, a mirror with an offlined leg
is claimed and imports degraded, and a mirror with a leg this host
cannot open, and which the configuration does not mark absent, is
refused.  The degraded and unreachable cases repeat on a three-way
mirror, where the number of legs the configuration expects and the
number this host can reach come apart.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Michael Heller <michael.heller at gmail.com>
Closes #18855
DeltaFile
+163-0tests/zfs-tests/tests/functional/mmp/mmp_degraded_import.ksh
+1-0tests/zfs-tests/tests/Makefile.am
+1-0tests/runfiles/linux.run
+165-03 files