ZTS: make dio_read_verify_decline's first read fail its verify
dio_read_verify_decline expects at most 10 Direct I/O reads before the
file handle declines Direct I/O. The first read only fails its
checksum verify if manipulate_user_buffer's thread happens to change
the buffer between the read completing and the verify, so on a busy
runner 13 to 37 reads went by before the first failure and the test
failed, although the decline itself worked (one dio_verify_rd event,
no direct reads after it).
Delay every read of the pool's vdevs by 25 ms with zinject. The vdev
copies the data into the caller's buffer before the delay, so the
buffer is always modified before the verify and the first direct read
fails. The test now expects exactly one direct read, and reads 100
blocks instead of 500 to keep the run time down.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19724
ZTS: failmode_create_continue: use a new pool for each operation
After each operation, zpool clear resumes the pool and starts a
resilver of the writes that failed. Its txgs (scan setup, scan, scan
done, DTL updates) sync back to back, so they can still be running
after the next iteration's zpool sync, while the errors for the next
operation are injected. Their writes then fail and suspend the pool:
- If the pool suspends before the next operation assigns its
transaction, dmu_tx_assign() returns EIO (failmode=continue) and the
operation fails without creating the entry. The test then reports
"entry hidden by a stale dentry" and "entry missing" for mkdir or
symlink, as seen on almalinux8 and fedora44 in CI.
- If it suspends while the resilver's SPA_ASYNC_RESILVER_DONE task
waits for SCL_ALL, zpool clear blocks on the config lock behind it
and the pool never resumes: the test hangs until the job times out,
as seen once on almalinux8.
[8 lines not shown]
ZTS: failmode_create_continue: don't leave an exported pool behind
The test ends by exporting the pool, so its cleanup's destroy_pool
finds no pool and both disks keep labels of an exported testpool.
The next test on the same disks that imports testpool by name then
fails with "more than one matching pool", e.g.
large_dnode_009_pos after the failmode group.
Import the pool again by guid after the export, so the cleanup
destroys it.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19717
ZTS: failmode_create_continue: don't rely on mkdir(1)'s exit status
On Ubuntu 26.04, mkdir is uutils coreutils, and uutils mkdir 0.8.0
exits 0 when mkdir(2) fails but the directory exists afterwards, which
is exactly the case this test creates: zfs_mkdir() creates the entry,
then returns EIO from the failed zil_commit(). So the test fails on
ubuntu26 with "mkdir: blocked=0 rc=0" although the kernel returned
EIO. GNU mkdir exits 1, as does uutils ln for the symlink case.
Issue a single mkdir(2) from python3 instead, as the create case does
with a single open(O_CREAT).
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19717
Decrypt when holding an unmounted filesystem's objset
zfsvfs_hold() sets up an unmounted filesystem with zfsvfs_create_hold(),
which holds its objset without DS_HOLD_FLAG_DECRYPT, so no key mapping
is created. zfsvfs_init() then fails to read the encrypted master node
with EACCES, even though the key is loaded. As a result, zfs userspace,
groupspace and projectspace, and setting a user, group or project
quota, fail with "permission denied" on an encrypted filesystem that
isn't mounted, unless its blocks happen to be cached.
Hold the objset with decryption, as zfsvfs_create() does when it owns
it. This was introduced by eb0c674c2a.
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Reviewed by: George Wilson <gwilson at zfsmail.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Matthew Ahrens <matt at mahrens.org>
Co-authored-by: Claude Opus 5.5 <noreply at anthropic.com>
Closes #19713
Fix direct reads of blocks pending free
Direct reads only check the on-disk block pointer for holes, so they
can read stale data after a block has been freed but before the free
has synced. Share buffered read hole detection with direct reads to
honor pending frees as well.
Keep cached data ahead of hole detection and preserve the transaction
ordering of block clone and direct write overrides. Retain the block
pointer recheck after dnode_block_freed() for concurrent syncing.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Wale Zhang <wale.zhang.ftd at gmail.com>
Closes #19633
ZIL: Sync the txg that a suspended commit waits for
zil_suspend() raises zl_suspend and then calls zil_commit_impl(). With
zl_suspend set, zil_get_commit_list() leaves every itx on the per-txg
lists, including the commit itx that carries the caller's own waiter,
and returns that txg for the caller to wait for instead. But
zil_commit_impl() waits on the waiter first, and the waiter is on no
lwb. Only zil_itxg_clean() can mark it done, once the txg syncs, and
nothing asks for that sync. The wait lasts until the sync thread's
zfs_txg_timeout timer fires. A zil_commit() that loses the race with
zil_suspend() waits the same way.
spa_reset_logs() suspends the ZIL of each dataset in turn while it
holds spa_namespace_lock. zpool remove, zpool split, removing a log
device that holds log blocks and offlining a non-redundant log device
all call it. Each dataset with a ZIL chain adds up to zfs_txg_timeout
to the command, and every other pool command waits for the lock
meanwhile. At the default of 5 seconds, the zpool remove in
removal_nopwrite takes 10 to 11 seconds for its two file systems.
[17 lines not shown]
dmu_recv: keep rrd->abd current in do_corrective_recv()
do_corrective_recv() works on a local copy of rrd->abd, and may replace
it up to three times: with the decompressed stream data, with the
recompressed data, and with the re-encrypted data. Each time the old
buffer is freed, but rrd->abd is only updated just before the rewrite
zio is issued. receive_process_record() unconditionally frees
rrd->abd after do_corrective_recv() returns for a healing receive, so
any error return between the first swap and that assignment frees the
original stream buffer a second time and leaks the current one.
The affected returns are the three error returns in the re-encryption
block (taken for a non-raw receive into an encrypted dataset), when
reached after the data has been decompressed (compressed stream) or
recompressed (compressed on-disk block):
- dsl_dataset_hold_flags(..., DS_HOLD_FLAG_DECRYPT, ...) failing
(returns EACCES),
- spa_keystore_lookup_key() failing (returns EACCES),
[20 lines not shown]
ZTS: create the fdomain pool in zpool_create_draid_005_pos
The random loop of zpool_create_draid_005_pos builds the device list
of each layout a second time with fdomain keywords, but then creates
the pool from the fgroup list again, so the fdomain form of those
layouts is never tested. Use the fdomain list.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Signed-off-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Closes #19708
zpool: reject empty dRAID failure groups and stray devices
construct_spec() counts the devices after each fgroup or fdomain
keyword and requires each group to hold as many as the previous one.
It misses two cases: devices listed before the first keyword, which
are counted as children but belong to no group, and groups with no
devices, because a previous count of zero is also how it recognises
the first group. Both let through specifications in which the number
of devices is not the number of groups times the size of a group:
- "draid1 d1 d2 d3 d4 fgroup fgroup" is accepted as two groups of two
disks, although no disk was listed in a group;
- "draid1 d1 d2 d3 fdomain fdomain fdomain fdomain" makes
draid_config_by_type() compute zero failure groups and divide by
zero, and zpool is killed by SIGFPE;
- "draid2 fdomain fdomain <16 disks> fdomain <16 disks>" leaves the
last entries of the reordered child array uninitialized, and the
verify() around nvlist_add_nvlist_array() aborts zpool.
[13 lines not shown]
cstyle: clean up bugs in some of the style lints
There were a few little mistakes in the cstyle script (a missing
boundary on else-checking, a missing $ on the `special` variable,
and a flipped regex.
I also cleaned up the few instances of cstyle mistakes that resulted
from fixing these lints.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Allan Jude <allan at klarasystems.com>
Signed-off-by: Mark Musante <mmusante at wasabi.com>
Closes #19592
dmu_recv: fix corrective recv of zstd compressed blocks
A corrective ("healing") receive into a dataset using zstd compression
panics on debug builds, and overruns a heap buffer on production builds:
zpool create -o ashift=12 tp /var/tmp/zd
zfs create -o compression=zstd -o recordsize=128k tp/fs
<write ~4MB of compressible data to /tp/fs/f>
zfs snap tp/fs at s; zfs send tp/fs at s > s.zs
<corrupt one L0 block on disk, export/import>
zfs recv -c tp/fs at s < s.zs
VERIFY3U(aiter->iter_pos, <=, aiter->iter_abd->abd_size) failed
(131072 <= 24576)
PANIC at abd_os.c:841:abd_iter_at_end()
do_corrective_recv() recompresses the stream data with the block's
algorithm and rwa->os->os_complevel, into a buffer of the block's
physical size. There are three problems with this:
[50 lines not shown]
ZTS: test corrective receive of zstd compressed blocks
The existing corrective receive tests write data from /dev/urandom,
which is not compressible, so they never exercise the recompression
path. Add zfs_receive_zstd_corrective, which heals compressible data
on zstd, zstd-12, zstd-fast-10 and encrypted zstd-9 datasets from
uncompressed send streams.
This currently fails: recompressing the stream data for the corrupted
block overruns its buffer, which panics debug builds in
abd_iter_at_end() (VERIFY3U(aiter->iter_pos, <=,
aiter->iter_abd->abd_size)) and corrupts kernel memory otherwise.
The fix follows in the next commit.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Will Rouesnel <wrouesnel at wrouesnel.com>
Closes #19281
ZTS: exercise persistent legacy NFS exports on Linux
Use a uniquely owned exports.d file for the persistent-export phase and
remove that file during cleanup. Reset exports between the earlier test
iterations and remove the obsolete reporter skip.
Pass export paths as positional parameters to a fixed shell command
instead of interpolating them into eval.
Assisted-by: OpenAI Codex
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Giuseppe Piscitelli <ooonea at gmail.com>
Closes #19598
Linux 7.0 compat: kernel_neon_begin() takes a state buffer
Linux 6.2 made the arm64 kernel_neon_* functions EXPORT_SYMBOL_GPL,
and commit 7b89149c9 ("Linux 6.2 compat: add check for kernel_neon_*
availability") added a configure probe that uses them when they are
visible to the module and otherwise turns kfpu_begin()/kfpu_end() into
no-ops. Users could still get NEON by building against a kernel that
re-exports those symbols, or with a GPL-compatible module license.
Linux 7.0 broke that: it moved the arm64 kernel mode NEON save buffer
out of task_struct and changed the interface to
kernel_neon_begin/end(struct user_fpsimd_state *), so the caller now
provides the buffer (the kernel's own users put it on the stack) and
the region can be preempted. The probe no longer compiled, so NEON was
silently disabled even where the license was not a problem.
Support the new interface by making the context explicit in the kfpu
API. kfpu_begin() and kfpu_end() take a kfpu_ctx_t *, declared by the
caller for each region. On Linux arm64 with the new interface it is
[15 lines not shown]
Describe the added vdevs in the vdev_add event
spa_vdev_add() posts the vdev_add event with no vdev, so the event
tells a consumer that something was added but not what: unlike the
vdev_attach, vdev_remove and similar events, it has no vdev_guid,
vdev_path or other vdev details.
Post one event for each top-level vdev added, built from the vdev as
the other vdev events are. This keeps the payload layout that zedlets
and the other consumers already read from the vdev_* members, and it is
the same as before for the usual case of a single vdev added. The
events are created while the vdevs are being added and posted where the
single event used to be, after the pool configuration is updated.
Adding only spares or cache devices still posts a single event without
a vdev, as before.
Document it in zpool-events(8) and add a test checking the guid and
path of each vdev_add event from 'zpool events -v' and from the ZED.
[3 lines not shown]
Keep the logical birth of dedup blocks in zfs rewrite -P
zfs rewrite -P is meant to keep the logical birth time of the blocks it
rewrites, so that incremental sends and snapshot diffs leave them out.
zio_dva_allocate() does that for ordinary blocks, and sets the rewrite
flag so that BP_GET_BIRTH() takes the new physical birth as the
allocation time. zio_ddt_write() keeps it only when the rewrite turns
out to be a NOP: a deduplicated block that gets new copies, as when
copies changes or dedup was turned on after the write, is filled from
its DDT entry with the current txg as logical birth, and the next
incremental send carries it again. In a libzpool test, a block written
at copies=2 without fast dedup went from 9L/9P to 14L/14P when
rewritten with -P at copies=1.
A dedup block pointer must carry the physical birth of its DDT entry,
which ddt_phys_select() matches on free, while BP_GET_BIRTH() must
still return the txg that space accounting compares with the previous
snapshot. So the logical birth can be kept, with the rewrite flag
set, only when the entry was written in this txg. That is the case
[17 lines not shown]
CI: FreeBSD 15.2 PRERELEASE
The FreeBSD 15.1-STABLE CI images are no longer available: the
snapshots/CI-IMAGES directory of download.freebsd.org now lists
14.5-STABLE, 15.2-PRERELEASE and 16.0-CURRENT, and every freebsd15-1s
job fails in "Start build machine".
Rename the builder to freebsd15-2s and point it at the
15.2-PRERELEASE images, as #18490 did for 15.1.
Signed-off-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
zio: initialize all props of gang children
zio_write_gang_block() builds the zio_prop_t of the gang children on
the stack and sets its fields one by one, but zp_brtwrite, zp_rewrite
and zp_zpl_smallblk were added to the structure later without this
site being updated. zio_write() copies the whole structure into each
child, so those fields carry whatever was left on the stack.
zp_rewrite is read for a gang child that could not be preallocated:
it goes through zio_dva_allocate(), and once its allocation succeeds
a set zp_rewrite gives its block pointer the rewrite bit and the
logical birth of io_bp_orig, which is zero for such a child. The
gang header then holds a member with a logical birth of 0 and a
rewrite bit that is otherwise only written to datasets with the
physical_rewrite feature active.
zp_brtwrite is only read along with io_bp_override and
zp_zpl_smallblk only by spa_preferred_class(), which returns early
for gang children, so neither is read for a gang child today.
[7 lines not shown]
ztest: do not ask the kernel whether its pool is active
When a pass starts and the pool is missing from zpool.cache, ztest
imports it from a scan of its directory. This happens after a kill that
lands while the cache file is being rewritten, which leaves it empty.
The import used libzpool_config_ops, whose pool_active() opens /dev/zfs
to ask the kernel about the pool and fails when the device does not
exist. get_configs() then drops every pool it found, so on a host
without the zfs module ztest aborts with "no pools found" although the
labels are intact and zdb -e opens the pool.
The pool lives in ztest's own directory and only this process imports
it, and the cache file path never asks the kernel either. Use config
ops that report the pool as inactive and still refresh the config with
spa_tryimport(), so the import takes the same steps as before. With
--use-existing-pool the pool may be one the kernel has imported, so
libzpool_config_ops is kept there.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
Closes #19684
nvt_nvpair_match: when duplicates allowed, only match the exact pair
Previously, this would match any pair with the same name, which when
duplicates are allowed could allow nvt_remove_nvpair() to remove the
wrong pair, leaving the wanted one on a hashtable bucket list.
In the case of nvlist_remove_nvpair(), it would then free the pair,
leaving a dangling pointer on the hashtable.
Fix this by always matching the specific pair (by pointer) when
duplicates are allowed.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19700
unit/nvpair: ensure nvlist_exists is correct after removal by pair
nvt_remove_nvpair() has a bug in that it doesn't remove the incoming
pair directly, but rather, removes the first pair in the hashtable that
matches the incoming pair. If the nvlist is configured to allow
duplicate keys, then the "wrong" pair may be removed and the hashtable
is left with a dangling pair pointer.
If an attempt is made to remove another instance of that name, looking
into that dangling pair may be an attempt to access invalid memory. ASan
and valgrind both rightly complain about this.
These tests attempt to exercise this by adding two pairs, removing one
at a time, checking existence in between. While the invalid memory
access is in the remove path, it was discovered when switching
nvlist_exists() to use the hashtable instead of a pair walk internally.
That change is not here, but still, the test will remain useful to
confirm that the pair list and the hashtable remain consistent via a
couple of different paths.
[5 lines not shown]
unit/nvpair: test next/prev on empty list
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19700
unit/nvpair: add iteration order tests
Pair iteration is guaranteed to return pairs in sorted order. Test this
for all three uniqueness modes, by inserting and replacing keys, then
checking they're returned in the expected order.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19700
unit/nvpair: move lookup_nvpair ENOTSUP tests into unsupported
Partially reverts c18d722c97. The lookup_nvpair test was correct, it
just should not have been passed parameters. The unsupported variants
for non-unique and unique+name should be in the "unsupported" catchall
tests.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #19700
Add support for anyraid vdevs
Anyraid allows devices of mismatched sizes to be combined together
into a single top-level vdev. In the current version, Anyraid only
supports mirror-type parity, but raidz-type parity is planned for the
near future.
Anyraid works by dividing each of the disks that makes up the vdev
into tiles. These tiles are the same size across all disks within a
given anyraid vdev. The size of a tile is 1/64th of the size of the
smallest disk present at creation time, or 16GiB, whichever is larger.
These tiles are then combined together to form the logical vdev that
anyraid presents, with sets of tiles from different disks acting as
mini-mirrors, allowing the reliability guarantees to be preserved.
Tiles are allocated on demand; when a write comes into a part of the
logical vdev that doesn't have backing tiles yet, the Anyraid logic
picks the nparity + 1 disks with the most unallocated tiles, and
allocates one tile from each of them. These physical tiles are
combined together into one logic tile, which is used to store data
[43 lines not shown]
ZIL: avoid repeated dirty registration in an active TXG
Register the ZIL when initializing its itxg for the active TXG. The
itxg lock serializes initialization with other writers and zil_clean(),
which resets itxg_txg before the ZIL leaves the dirty list.
Keep real-TXG registration for frozen pools.
Signed-off-by: George Melikov <mail at gmelikov.ru>
Reviewed-by: Matthew Ahrens <matt at mahrens.org>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #19689
ZTS: enable the busy checkpoint discard test
Remove the skip and obsolete reporter allowances after the checkpoint
accounting fix. Track whether the saved discard limit still needs to be
restored, keeping one exit callback without relying on saved-file paths.
Preserve restoration failure checks.
Assisted-by: OpenAI Codex
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Tony Hutter <hutter2 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Giuseppe Piscitelli <ooonea at gmail.com>
Closes #19645
zpool: reject a dRAID children count of zero
Since dRAID failure domains were added, the children count given with
the "c" suffix of a dRAID type only has to divide the number of disks,
and draid_config_by_type() checks that by taking the number of disks
modulo the count. A count of zero, as in "zpool create tank draid2:0c
<disks>", divides by zero and zpool is killed by SIGFPE instead of
reporting an invalid vdev specification. Before that change the count
had to equal the number of disks, so zero was rejected.
zpool_create_draid_003_pos runs that command and passes anyway,
because log_mustnot takes a command killed by SIGFPE for one that
failed; the kernel log of those runs shows "trap divide error" in
zpool.
Reject a zero count with the message given for a count which does not
divide the number of disks.
Signed-off-by: Tigerblue77 <37409593+tigerblue77 at users.noreply.github.com>
[3 lines not shown]
