OpenZFS/src 02b5baftests/test-runner/bin zts-report.py.in

ZTS: Add import_relax_metadata_damaged exception

The newly added import_relax_metadata_damaged test case is flaky.
Add it to the exceptions script until the underlying issue is resolved.

Reviewed-by: George Melikov <mail at gmelikov.ru>
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Issue #19077
Closes #19104
DeltaFile
+1-0tests/test-runner/bin/zts-report.py.in
+1-01 files

OpenZFS/src 99831decmd/zdb zdb.c, include libzdb.h

zdb: Allow filtering on zvol objects

Allow "v" flag for object ID range filters for filtering on zvol
objects. Also, fixup tests so that "v" is now considered a valid
flag.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Glenn Washburn <development at efficientek.com>
Closes #19069
DeltaFile
+6-0cmd/zdb/zdb.c
+1-1tests/zfs-tests/tests/functional/cli_root/zdb/zdb_object_range_neg.ksh
+2-0man/man8/zdb.8
+2-0include/libzdb.h
+11-14 files

OpenZFS/src bf71aafman/man4 spl.4, module/os/linux/spl spl-kmem-cache.c

spl: Honour forced Linux slab cache selection

spl_kmem_cache_slab_limit controls automatic cache selection. An
explicit KMC_SLAB request should override that cutoff, but the Linux
slab branch applies it again. With a zero cutoff, this rejects the
forced znode cache. Pool creation later dereferences the NULL cache in
spl_kmem_cache_alloc().

Automatic selection has already applied the cutoff before this branch.
Remove the redundant check so KMC_SLAB retains its documented force
semantics, and clarify the automatic cutoff's scope in spl(4).

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Matthias Goergens <matthias.goergens at gmail.com>
Closes #19095
DeltaFile
+6-5man/man4/spl.4
+0-3module/os/linux/spl/spl-kmem-cache.c
+6-82 files

OpenZFS/src 56e8d23module/zfs vdev.c

Stop the TRIM and initialize threads when a vdev goes offline

vdev_fault() and vdev_offline() leave the vdev not writeable, but the
TRIM or initialize thread running on it only notices that at its next
vdev_trim_should_stop() check, and it is that thread which records the
final state of the operation: since bedbc13da vdev_trim_thread() sets
VDEV_TRIM_CANCELED for a faulted vdev on its way out, and
vdev_initialize_thread() does the same.  Neither ioctl waits for that,
even though spa_vdev_state_exit() already waits for the txg to sync
exactly so the command is synchronous -- "when the command completes,
you expect no further I/O from ZFS".

So the operation is still running when the command returns: a "zpool
status -t" issued right after "zpool offline -f" reports

    loop0  FAULTED  0  0  0  external device fault  (31% trimmed, ...)

on a vdev that is already FAULTED, and the TRIM thread keeps issuing IO
to the device the administrator has just faulted.

    [37 lines not shown]
DeltaFile
+82-1module/zfs/vdev.c
+82-11 files

OpenZFS/src 61fbdf1module/zfs spa.c

zfs: spa_sync_upgrades() should only take lock when needed

"zfs get -Hp ..." command got into waiting for memory allocation
while holding READER lock as dmu_objset_hold holds dp_config_rwlock READ
via dsl_pool_hold.

pageout was freeing memory by pushing some pages to swap zvol,
but got waiting for txg_wait_synced() and the memory was not freed.

txg_sync thread: spa_sync -> spa_sync_upgrades ->
rrw_enter(&dp->dp_config_rwlock, RW_WRITER) blocked.

This scenario did lead to investigation if spa_sync_upgrades() is
actually correct about requiring writer lock and it turns out that
we only do need write lock for three cases, where upgrade does change
DSL name space.

In other cases, and to check uberblock versions, we do not need
to set this lock.

    [3 lines not shown]
DeltaFile
+40-24module/zfs/spa.c
+40-241 files

OpenZFS/src 4e015d8tests/zfs-tests/tests/functional/cli_root/zpool_initialize zpool_initialize_online_offline.ksh

ZTS: inject latency into initialize online/offline test

Fast vdevs can finish initialization before the online/offline test
checks progress and suspends it.  Moving the suspend command earlier
only narrows this race window.

Inject a 20 ms write delay with one lane on the disk being initialized
so the test can observe progress and suspend initialization.  Keep the
original online/offline assertions and clear the injection during
cleanup before destroying the pool.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Matthias Goergens <matthias.goergens at gmail.com>
Closes #19024
DeltaFile
+9-0tests/zfs-tests/tests/functional/cli_root/zpool_initialize/zpool_initialize_online_offline.ksh
+9-01 files

OpenZFS/src 0833cfdinclude/os/freebsd/spl/sys uio.h, include/os/linux/spl/sys uio.h

Decline Direct I/O reads on a file handle after a benign verify failure

A Direct I/O read verifies the block checksum over the caller's buffer
after the read completes, to catch the buffer being modified while the
read is in flight.  When an application recycles its O_DIRECT read
buffers across concurrent requests -- QEMU's block layer does this -- a
queued read can overwrite the buffer before the previous read's verify
runs.  The verify then fails even though the data on disk is correct:
ZFS discards the direct read, re-reads the block through the ARC, and
emits an ereport.fs.zfs.dio_verify_rd.  The returned data is correct and
the pool stays healthy, but under concurrent load the stream of failed
verifies and buffered re-reads is a real cost and can stall the
workload (#18610).

Once a file handle hits one of these benign failures -- a DIO read
verify that failed but whose buffered re-read then succeeded, proving
the on-disk data good and the buffer caller-modified -- decline Direct
I/O for reads on that handle for the rest of its life and route them
through the existing uncached buffered path.  An application that uses a

    [29 lines not shown]
DeltaFile
+117-0tests/zfs-tests/tests/functional/direct/dio_read_verify_decline.ksh
+47-0module/os/linux/zfs/zpl_file.c
+23-1module/zfs/zfs_vnops.c
+9-0include/os/linux/spl/sys/uio.h
+7-0include/os/freebsd/spl/sys/uio.h
+1-1tests/runfiles/linux.run
+204-21 files not shown
+205-27 files

OpenZFS/src cd3699dinclude/os/linux Makefile.am, include/os/linux/kernel/linux kthread_compat.h

Linux 7.3: make host filesystem available to kernel threads

Every kernel task has a `struct fs_struct *fs` that points to the root
of the filesystem tree for this task, and is used as the starting point
for path resolution. This is what is modified by chroot(2),
pivot_root(2), etc.

Kernel threads (as spawned by kthreadd) used to get a pointer to the
root filesystem by default. In 7.3 this changed, and kernel threads now
get a pointer to an internal nullfs; effectively a "no-op" filesystem
with no path into the true filesystem. An opt-in mechanism is provided
in the form of `scoped_with_init_fs()`, which swaps in a a pointer to
the root filesystem for the scoped code, and reverts it at end of scope.

Currently we don't have any good notion of whether or not a given thread
(including taskq tasks) will require filesystem access, and no good way
to signal it anyway. For now, to maintain the status quo, we add
`scoped_with_init_fs()` in the two places where arbitrary code may run
on a kernel thread: in `thread_generic_wrapper()`, the startup

    [13 lines not shown]
DeltaFile
+35-0include/os/linux/kernel/linux/kthread_compat.h
+5-2module/os/linux/spl/spl-thread.c
+3-1module/os/linux/spl/spl-taskq.c
+1-0include/os/linux/Makefile.am
+44-34 files

OpenZFS/src 6e2fa4bconfig kernel.m4 kernel-inode-create.m4, module/os/linux/zfs zpl_inode.c

Linux 7.3: inode_operations.create dropped flag arg

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Co-developed-by: TheAlmightyOgreLord <beardedtechwizard at protonmail.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19082
DeltaFile
+34-0config/kernel-inode-create.m4
+5-0module/os/linux/zfs/zpl_inode.c
+2-0config/kernel.m4
+41-03 files

OpenZFS/src 315bc75include/os/linux/kernel/linux simd_x86.h, module/zcommon simd_stat.c

Linux: use cpu_feature_enabled() instead of static_cpu_has()

static_cpu_has() was renamed in 7.3 because since 3.18
cpu_feature_enabled() has always been the "right" way to do the same
thing. So we just switch everything over.

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Co-developed-by: TheAlmightyOgreLord <beardedtechwizard at protonmail.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19082
DeltaFile
+7-7include/os/linux/kernel/linux/simd_x86.h
+4-4module/zcommon/simd_stat.c
+11-112 files

OpenZFS/src d966f3dconfig kernel-bio.m4, include/os/linux/kernel/linux blkdev_compat.h

Linux 7.3: bvec_iter.bi_bvec_done is now bi_offset

Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Co-developed-by: TheAlmightyOgreLord <beardedtechwizard at protonmail.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19082
DeltaFile
+26-0config/kernel-bio.m4
+4-0include/os/linux/kernel/linux/blkdev_compat.h
+30-02 files

OpenZFS/src ab994accmd ztest.c, include/sys dmu.h

dmu: remove dmu_prealloc()

ztest is the only caller, and its ZTI_INIT entry has sat behind #if 0
since the 2010 import from OpenSolaris build 141, so nothing exercises
it. No kernel or libzpool code calls it either.

Remove the function and its export, plus the ztest code that existed
only for it: ztest_dmu_prealloc(), the ztest_prealloc() helper it
called, and the disabled ZTI_INIT entry.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Patrick Domack <patrickdk at patrickdk.com>
Closes #19090
DeltaFile
+0-77cmd/ztest.c
+0-22module/zfs/dmu.c
+0-2include/sys/dmu.h
+0-1013 files

OpenZFS/src db07a5emodule/zfs dbuf.c

dbuf: account dirty data for embedded writes

dmu_buf_will_not_fill() leaves the dbuf DB_NOFILL and dbuf_dirty()
skips the dirty accounting for those, so the dirty record from an
embedded write never raises dp_dirty_total.  A receive of a stream
of embedded records runs unthrottled ahead of the syncing TXG,
pinning dbufs the ARC cannot evict.  Same gap as dmu_brt_clone().

An embedded write fills a whole block, so charge one.

No reproducer yet.  A receive of 300,002 embedded records against
a 64 MiB ARC peaks at 116%, and the same receive carrying 2
embedded records peaks at 118%, so that overshoot is dnode and
bonus buffers from creating 300,000 files rather than the embedded
writes.  The accounting gap is real either way.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Patrick Domack <patrickdk at patrickdk.com>
Closes #19071
DeltaFile
+10-0module/zfs/dbuf.c
+10-01 files

OpenZFS/src 8fe28f4man/man8 zdb.8

zdb.8: document the -Z flag

Add Z to the SYNOPSIS and an entry for -Z, --zstd-headers to 
the option list.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #19094
DeltaFile
+5-2man/man8/zdb.8
+5-21 files

OpenZFS/src 1c8a75ftests/zfs-tests/tests/functional/device_access device_access_import.ksh

ZTS: Fix device_access_import cleanup

The device_access_import test will complete without destroying
the pool it created.  Instead it will end with "testpool" being
exported on loop0 and loop1.  This causes a failure later on
with fadvise_willneed_limit, where it will fail to import due to
two pools named "testpool".  This can be reproduced by running:

./scripts/zfs-tests.sh -T device_access,fadvise

To fix this, simply wipe the labels during cleanup() in
device_access_import.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: George Melikov <mail at gmelikov.ru>
Signed-off-by: Tony Hutter <hutter2 at llnl.gov>
Closes #19089
DeltaFile
+6-0tests/zfs-tests/tests/functional/device_access/device_access_import.ksh
+6-01 files

OpenZFS/src 1a8e514module/zfs zfs_vnops.c

Fix self-deadlock when cloning a range within the same file

zfs_clone_range() takes an RL_READER range lock on the source range
and an RL_WRITER range lock on the destination range.  When the
source and destination are the same file (inzp == outzp) both locks
are on the same znode's rangelock.  If the destination write has to
grow the file's block size, zfs_rangelock_enter() grows the writer
lock to cover the whole file (see zfs_rlock.c), which then conflicts
with the source reader held by the same thread.  The result is an
unrecoverable self-deadlock (the thread waits forever in
zfs_rangelock_enter_impl(), D state, freed only by a reboot).

Reproduced by fstests generic/564, whose copy_range probe does a
sub-recordsize copy_file_range() within one file that extends it (so
the destination block size grows).

For a same-file clone, take a single writer lock spanning both ranges
instead of a separate reader and writer.  The source block pointers
are read before zfs_clone_range_locked() reduces the lock, so the

    [11 lines not shown]
DeltaFile
+19-2module/zfs/zfs_vnops.c
+19-21 files

OpenZFS/src 75bd31cmodule/zfs arc.c

L2ARC: do not feed a device while its rebuild is pending

l2arc_add_vdev() leaves the device at l2ad_start with l2ad_first set,
marks it l2ad_rebuild, and starts its feed thread.  The rebuild runs
later from the spa async thread and only then restores the geometry the
on-disk header describes.

A feed in that window writes at l2ad_start believing the device is
empty, and its headers go on the head of l2ad_buflist while the rebuild
appends the restored ones at the tail.  l2arc_evict() walks that list
from the tail and stops at the first header outside the range it is
clearing, so once list position stops tracking device offset the walk
exits early, headers the hand is about to overwrite are never destroyed,
and the writes that replace them charge the space twice.  vs_alloc
passes vs_space and zpool(8) reports 16.0E free.

l2arc_dev_invalid() rejected a device with l2ad_rebuild or l2ad_trim_all
set until b525525b4 made the feed threads per-device; neither flag has
had a reader since.  Restore the test, after SCL_L2ARC is taken so it

    [7 lines not shown]
DeltaFile
+5-0module/zfs/arc.c
+5-01 files

OpenZFS/src 7853c27include/sys zio.h, module/zfs vdev_raidz.c vdev_draid.c

ZIO: Batch lightweight ZIOs

This further develops concept of ZIO batching from #18921, extending
it from the leaf vdev layer up the stack.  Now it covers the case of
I/O scheduler enabled, not covered before.  I/O aggregation of the
scheduler can complete several ZIOs at once, creating opportunity
for batching.

This change allows ZIO pipeline stages to return more than one ZIO,
chaining them via the field added in previous commit, renaming it
to more generic io_exec_next.  To identify ZIOs to batch, this change
introduces a new ZIO flag ZIO_FLAG_LIGHTWEIGHT, set for members of
a batch.  So once zio_done() or possibly other stage handlers return
a list of ZIOs, zio_execute() has now ability to decide which of them
to execute itself, and which to dispatch to taskqueues as before.

With this change my tests of 32KB block writes to 3x 5-wide NVMe RAIDZ1
on 64-core system with scheduler=on show throughput increase from
15.0GiB/s to 16.1GiB/s, while the taskqueue lock contention is

    [12 lines not shown]
DeltaFile
+259-113module/zfs/zio.c
+4-3include/sys/zio.h
+2-4module/zfs/vdev_mirror.c
+3-1module/zfs/vdev_queue.c
+1-2module/zfs/vdev_raidz.c
+1-2module/zfs/vdev_draid.c
+270-1256 files

OpenZFS/src 6a320c9config kernel-vfs-fop-flags.m4, module/os/linux/zfs zpl_file.c

Linux: Wire RWF_DONTCACHE and POSIX_FADV_NOREUSE

Wire both to Uncached I/O, since that is what they mean -- the data
will not be accessed again after the operation. It allows us to both
reduce ARC/dbuf cache trashing and avoid extra memory copies to/from
scattered and unmapped ARC buffers.

Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: George Melikov <mail at gmelikov.ru>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #19054
DeltaFile
+184-0tests/zfs-tests/cmd/file/file_uncached.c
+103-0tests/zfs-tests/tests/functional/uncached/uncached_noreuse.ksh
+100-0tests/zfs-tests/tests/functional/uncached/uncached_dontcache.ksh
+37-0module/os/linux/zfs/zpl_file.c
+28-0config/kernel-vfs-fop-flags.m4
+20-0tests/zfs-tests/tests/functional/uncached/setup.ksh
+472-013 files not shown
+528-419 files

OpenZFS/src cb333betests/zfs-tests/tests/functional/compression compress_004_pos.ksh, tests/zfs-tests/tests/functional/zstream zstream_raw_001_pos.ksh

ZTS: resolve two possible divide by zero errors in tests

Resolve two divide by zero errors observed by the CI. Change 
how random picking to ensure no divide by zero, and also keep 
same semantics.

Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: George Melikov <mail at gmelikov.ru>
Signed-off-by: tiehexue <tiehexue at hotmail.com>
Closes #19078
DeltaFile
+7-2tests/zfs-tests/tests/functional/zstream/zstream_raw_001_pos.ksh
+6-1tests/zfs-tests/tests/functional/compression/compress_004_pos.ksh
+13-32 files

OpenZFS/src ba464dftests/zfs-tests/tests/functional/mmp mmp_write_distribution.ksh mmp_on_zdb.ksh

ZTS: do not leave a suspended pool behind in the mmp tests

The mmp tests destroy their pool from cleanup through

    datasetexists $TESTPOOL && destroy_pool $TESTPOOL

and datasetexists() asks zfs, which cannot open a pool whose I/O is
suspended:

    # zfs get name msus
    cannot open 'msus': pool I/O is currently suspended

MMP suspends the pool by itself once its writes have not succeeded for
long enough, which is exactly the state a failing mmp test tends to
leave behind, so the guard says the pool is gone, cleanup destroys
nothing, and the pool stays imported.  Every mmp test that runs after
it then fails on its own zpool create:

    /dev/loop0 is part of active pool 'testpool'

    [31 lines not shown]
DeltaFile
+21-3tests/zfs-tests/tests/functional/mmp/mmp_on_uberblocks.ksh
+2-1tests/zfs-tests/tests/functional/mmp/mmp_write_distribution.ksh
+2-1tests/zfs-tests/tests/functional/mmp/mmp_on_zdb.ksh
+2-1tests/zfs-tests/tests/functional/mmp/mmp_on_thread.ksh
+2-1tests/zfs-tests/tests/functional/mmp/mmp_on_off.ksh
+2-1tests/zfs-tests/tests/functional/mmp/mmp_hostid.ksh
+31-82 files not shown
+34-108 files

OpenZFS/src 0e2c0f9tests/zfs-tests/cmd mmap_sync.c

ZTS: judge mmap_sync by a concurrent fsync, not by a fixed bound

mmap_sync fails whenever one msync() takes longer than two seconds,
and in CI it does, on machines that are merely loaded:

    slow msync: 2318.177000 ms
    slow msync: 4043.686000 ms

The bound was raised once already, in c4d1a19b3 ("ZTS: increase
timeout of mmap_sync_001_pos"), and the ctime_001_pos failure fixed in
8486ea36f shows the same CI stalling a creat() for twelve seconds, so
no fixed bound is going to hold there.

An msync() goes through zpl_fsync(): since a18c9edda ("Linux: sync:
remove async/sync accounting") it writes the dirty pages out with
zfs_putpage() and ends in zil_commit(), and it never waits for page
writeback.  So what the bound really measures is the ZIL commit, which
is the disk.  Sampling the kernel stacks of mmap_sync under an IO load
in a VM confirms it: the time goes into zil_commit_impl() waiting for

    [28 lines not shown]
DeltaFile
+200-36tests/zfs-tests/cmd/mmap_sync.c
+200-361 files

OpenZFS/src e08bc29module/zfs dmu_recv.c, tests/runfiles common.run

Skip interior dnode slots when receiving DRR_FREEOBJECTS

receive_freeobjects() looks up every object of the record with
dmu_object_info() and fails the receive on any error but ENOENT.  An
interior slot of a multi-slot dnode answers EEXIST, and that is the
errno zfs receive then reports as "destination already exists".  This
is how ZTS send_realloc_files fails in CI:

    cannot restore to testpool/newfs at snap3: destination already exists

The sender emits such a record whenever a multi-slot dnode was freed
and a smaller one was later allocated on one of its interior slots: it
frees the leading slots, claims the new object and frees the trailing
slots as three separate records, e.g. for an 8-slot dnode at 10:

    FREEOBJECTS firstobj = 10 numobjs = 3
    OBJECT object = 13 ... dn_slots = 1
    FREEOBJECTS firstobj = 14 numobjs = 4


    [24 lines not shown]
DeltaFile
+116-0tests/zfs-tests/tests/functional/rsend/send_realloc_dnode_interior.ksh
+10-1module/zfs/dmu_recv.c
+2-1tests/runfiles/common.run
+1-0tests/zfs-tests/tests/Makefile.am
+129-24 files

OpenZFS/src 09e7e73tests/zfs-tests/tests/functional/l2arc l2arc_multidev_scaling_pos.ksh

ZTS: fill the ARC before l2arc_multidev_scaling_pos measures it

The test sets l2arc_write_max to 4MB/s, starts a background dd and then
requires that L2ARC wrote at least 80% of 4MB/s per device over a fixed
window.  What that window measures, though, is not the rate limit but
how fast the dd manages to feed the ARC: a feed thread writes what it
finds on the eviction lists and goes back to sleep, so with a writer
that cannot keep ahead of it the phase falls short of the bound through
no fault of the code under test.

In CI on Linux it fails both ways, on unrelated branches:

    NOTE: Single-device writes: 19MB (expected ~48MB)
    Single-device writes 19MB below minimum 38MB

    NOTE: Dual-device writes: 26MB (expected ~96MB)
    Dual-device writes 26MB below minimum 76MB

while passing runs on the same days report 72MB and 158MB for those very

    [45 lines not shown]
DeltaFile
+86-73tests/zfs-tests/tests/functional/l2arc/l2arc_multidev_scaling_pos.ksh
+86-731 files

OpenZFS/src 92a3904include/sys dsl_scan.h, module/zfs dsl_scan.c spa.c

Wait for the txg that finished a scan to sync

dsl_scan_done() marks the scan DSS_FINISHED in syncing context, and
right before that it asks vdev_dtl_reassess() to update the DTLs and
dirty the config, which the same txg writes out later in its
spa_sync().  spa_activity_in_progress() looks at the state alone:

    scanning = (scn->scn_phys.scn_state == DSS_SCANNING);
    ...
    *in_progress = (scanning && !paused && ...);

so "zpool wait -t resilver" and "zpool wait -t scrub" return while the
labels of that txg are still being written; spa_vdev_resilver_done()
notifies the waiters from the async thread, which can run before the
sync ends, so a waiter is not even guaranteed to sleep.

A command issued right after the wait then reads a pool whose labels
are mid-rewrite.  ZTS vdev_zaps_004_pos fails on this: it runs "zdb
-PC" straight after "zpool wait -t resilver" and the pool fails to

    [28 lines not shown]
DeltaFile
+21-2module/zfs/spa.c
+7-0module/zfs/dsl_scan.c
+6-0include/sys/dsl_scan.h
+34-23 files

OpenZFS/src 1ebc6f5cmd/zdb zdb.c

zdb: do not adopt an unreferenced spa when the pool fails to open

When spa_open_rewind() fails, zdb looks the pool up in the namespace
to see whether it only failed for a missing log device, and it does
so into the global spa:

    if ((spa = spa_lookup(target)) != NULL &&
        spa->spa_log_state == SPA_LOG_MISSING) {

spa_lookup() takes no reference, and the open that just failed had
already set spa to NULL.  So whenever the pool is in the namespace
but fails to open for any other reason, zdb goes on to fatal(), and
zdb_exit() then spa_close()s a pool it holds no reference on:

    zdb: can't open 'testpool': Device not configured
    ASSERT at module/zfs/spa_misc.c:1004:spa_close()
    zfs_refcount_count(&spa->spa_refcount) > spa->spa_minref || ...

The pool is in the namespace whenever the cachefile names it, so a

    [13 lines not shown]
DeltaFile
+10-4cmd/zdb/zdb.c
+10-41 files

OpenZFS/src 0ee8ea0include/os/freebsd/spl/sys types32.h, lib/libspl/include/sys types32.h

FreeBSD: use sys/abi_compat.h for time32_t

FreeBSD 14.5 defines time32_t in sys/abi_types.h. The SPL typedef now
duplicates it, which breaks the -std=gnu99 module build on stable/14.
Apply the same change as freebsd-src 87632ddf67b.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #19059
DeltaFile
+5-0lib/libspl/include/sys/types32.h
+2-1include/os/freebsd/spl/sys/types32.h
+7-12 files

OpenZFS/src 9e06573.github/workflows README.md zfs-qemu.yml, .github/workflows/scripts qemu-2-start.sh

CI: update the FreeBSD STABLE CI runner to 14.5-STABLE

Update the FreeBSD STABLE CI from 14.4-STABLE to 14.5-STABLE. Update the
README as well.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #19058
DeltaFile
+2-2.github/workflows/zfs-qemu.yml
+2-2.github/workflows/scripts/qemu-2-start.sh
+1-1.github/workflows/README.md
+5-53 files

OpenZFS/src e4538b5tests/zfs-tests/tests/functional/device_access device_access_import.ksh setup.ksh

ZTS: tighten the device_access tests

- Wrap the cachefile copy in log_must and require it to be
  non-empty, so the negative import tests cannot pass vacuously
  on a system without /etc/zfs/zpool.cache.
- Make check_vdevs() list only the pool it is passed instead of
  every /dev-backed pool on the host.
- Skip the group with log_unsupported when $DISKS are not real
  block devices, instead of failing.
- Wrap the restore_perms() chmod in log_must.

Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: xfcyhuang <xfcyhuang at aliyun.com>
Closes #19057
DeltaFile
+2-2tests/zfs-tests/tests/functional/device_access/device_access.kshlib
+2-1tests/zfs-tests/tests/functional/device_access/device_access_import.ksh
+3-0tests/zfs-tests/tests/functional/device_access/setup.ksh
+7-33 files

OpenZFS/src 0a25e5ccmd ztest.c

ztest: print the fishing seed with %016llx

printf("%016lx", uint64_t) is undefined on ILP32 where uint64_t
promotes to unsigned long long.  Cast to u_longlong_t and use
%016llx, as is done elsewhere in this file.

Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Igor Ostapenko <igor.ostapenko at klarasystems.com>
Signed-off-by: xfcyhuang <xfcyhuang at aliyun.com>
Closes #19055
DeltaFile
+10-7cmd/ztest.c
+10-71 files