Fix receive of split large blocks with a short trailing chunk
A dataset with a large recordsize can store a single-block file whose
block size is not a power of two. When such a block is sent without
large blocks (no -L), the sender splits it into SPA_OLD_MAXBLOCKSIZE
(128K) chunks, and the final chunk is smaller than the block size.
flush_write_batch_impl() already handles any WRITE record whose size
differs from the object's block size by doing a normal dmu_write(), but
it first asserted the record was always larger than the block size. The
shorter trailing chunk violates that assertion, so receiving such a
stream panicked the receive_writer thread on debug builds; production
builds took the correct dmu_write() path and were unaffected.
Drop the assertion and describe both size-mismatch cases in the comment;
the dmu_write() path already handles a record smaller than the block
size. Add an rsend test that sends such a block without -L (initial and
incremental, plain and compressed) and verifies the received file
matches.
[4 lines not shown]
Fix receive -x according to comment
The old condition skipped the -x for ANY property whose source wasn't
explicitly ZPROP_SOURCE_VAL_RECVD - which caught inherited/default
properties too, not just locally-set ones. The new condition correctly
skips only when the property is locally-set on the destination
(source == fsname), which is the documented intent.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Richard Kojedzinszky <richard at kojedz.in>
Closes #18737
Closes #18738
Add SECURITY.md policy file
Add a basic SECURITY.md file to establish the repository's security
reporting policy. Includes guidance for reporting security issues
and what to expect.
Reviewed-by: Allan Jude <allan at klarasystems.com>
Reviewed-by: George Melikov <mail at gmelikov.ru>
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18766
Do not return ESTALE for open-unlinked files
When the Linux fh_to_dentry() export operation is called for an
open-unlinked file on a ZFS filesystem, an ESTALE error is returned.
This behavior differs from other filesystem implementations on Linux
(like eg. ext4, XFS), which grant access to inodes that are unlinked
but still referenced. Update both the Linux and FreeBSD code to
conform with the established Linux behavior.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: tiehexue <tiehexue at hotmail.com>
Closes #18699
Closes #18718
Use a single creation time for a recursive snapshot
All snapshots created by one "zfs snapshot -r" are taken atomically in a
single txg, but dsl_dataset_snapshot_sync_impl() sampled the wall clock
once per snapshot inside the per-dataset loop. If that loop crossed a
one-second boundary, snapshots of the same txg were stamped with
different "creation" times, which confuses tools that order snapshots by
creation time (createtxg was already coherent).
Sample the wall clock once in dsl_dataset_snapshot_sync(), before the
loop, and pass it to each dsl_dataset_snapshot_sync_impl() call. The
other callers (origin, temporary snapshot, and receive) each create a
single snapshot per sync task and keep their current behavior by passing
gethrestime_sec() directly.
Add a test that takes a recursive snapshot of a 50-child hierarchy and
verifies every snapshot shares one createtxg and one creation time. The
test locks the fixed invariant rather than reproducing the timing race,
which the fast in-kernel sync loop hit only rarely.
[4 lines not shown]
libzfs/crypto: fetch key material directly onto the stack
Previously this was creating a temporary file in /tmp or TMPDIR, which
are often backed by a real filesystem on real disks, and so the key
material would be written to disk.
Instead, create a buffer on the stack, and create a stream over the top
of it, and let libcurl use that instead.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Chris Longros <chris.longros at gmail.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18762
libzfs/crypto: name the key material stream more clearly
Very difficult to see that (a) it's operating on a stdio stream and not
a file descriptor and (b) that there's a file involved and not just an
in-memory buffer.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Chris Longros <chris.longros at gmail.com>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18762
linux: batch DMU reads of non-resident pages in mappedread()
When a range being read has at least one page in the page cache,
zfs_read() routes the whole chunk through mappedread(), which falls
back to a separate dmu_read_uio_dbuf() call for every non-resident
PAGE_SIZE piece. Since cached pages outlive munmap(), a file which
was mapped at some point may sit mostly outside the page cache and
still pay this cost: one DMU call per 4K page instead of one per
chunk, measured in #16031 as a 4-10x sequential read slowdown.
Commit 39be46f43 ("Linux 5.18+ compat: Detect filemap_range_has_page")
fixed the detection side so fully uncached chunks bypass mappedread()
again, but a chunk holding even one resident page still degrades to
page-sized DMU reads for everything else.
Instead of issuing one DMU read per absent page, probe the page cache
with find_get_page() and extend the read over the whole run of
non-resident pages which follows, restoring chunk-sized DMU reads for
the uncached parts of a mapped file.
[30 lines not shown]
Linux: add idmap versions of verious znode operations
Calls from the core to znode operations (primarily in zfs_replay) are
always with zfs_init_idmap, so make the "generic" interface wrap the
idmap version, setting that as the namespace internally.
This lets us supply a uniform interface znode interface to the core for
all platforms.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
Linux: add idmap versions of zfs_zaccess and zfs_zaccess_rwx
The calls from the core to zfs_zaccess() and zfs_zaccess_rwx() are
always with zfs_init_idmap, so we can make that the "generic" interface
by having those call extended internal versions that take an idmap arg.
Existing uses in the Linux platform code that use zfs_init_idmap just
remove that arg, while others that pass down an idmap parameter use the
_idmap() variants.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
FreeBSD: remove zidmap_t and mnt_ns
These are not present and never used on FreeBSD, and never leave the
platform either, so are literal no-ops.
To keep the build working, zfs_zaccess() and zfs_zaccess_rwx() get
different prototypes on Linux. These will be dealt with in the next
commit.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
zfs_acl: split header into core and platform-specific variants
The common set of function names in the same "core" header makes it look
like these are all needed for all platforms, but really only a small
handful of functions are used by core code. Separating them makes that
much easier to see.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
zfs_acl: remove zfs_has_access
Last use on the Linux side was removed in 3558fd73b5 (2011). Briefly
returned when FreeBSD came home in 9f0a21e641 (2020), but that use was
removed again in 3f400b0f58 (2022).
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
zfs_acl: remove obsolete function prototypes
As far as I can tell these have existed without an impementation since
the earliest Sun ZFS releases.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18736
Linux: fix zfs_write() infinite loop on unfaultable buffer
On Linux, zfs_write() copies from the source buffer with page faults
disabled while the transaction is open, relying on
zfs_uio_prefaultpages() to make the pages resident beforehand. When
dmu_write_uio_dbuf() returns EFAULT, the retry path only subtracts
the bytes consumed so far from the prefault accounting. On zero
progress pfbytes does not change, the "pfbytes < nbytes" check never
triggers another prefault, and the loop retries the same failing
copy. If the buffer can never be faulted in again, e.g. the owning
process was torn down while a thread was in pwrite(2), that thread
spins unkillably at 100% CPU holding the file range lock, blocking
every other accessor of the file.
This is a regression from commit b0cbc1aa9a ("Use big transactions
for small recordsize writes."), which dropped the unconditional
re-prefault the EFAULT path had carried since commit 779a6c0bf6
("deadlock between mm_sem and tx assign in zfs_write() and page
fault"). Restore those semantics by resetting pfbytes on EFAULT, as
[15 lines not shown]
build: Fix for building dist target outside of project root
Do not change the working directory when doing copying because $distdir
is a path relative to the working directory, and thus not valid after
changing the working directory. This previously worked, when configure
was run from the project root, because @srcdir@ was the same as the
build working directory.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Glenn Washburn <development at efficientek.com>
Closes #18744
unit/fletcher: test fletcher-2 and fletcher-4 checksums
Cover known answers, incremental vs single-call agreement, varsize,
byteswap, and cross-implementation equality.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Christos Longros <chris.longros at gmail.com>
Closes #18747
ZTS: ctime_001_pos increase tolerance
The ctime_001_pos test checks that timestamp updates occur for a
file after performing certain operations (read, write, chown, etc).
The test case allowed for a +4 second tolerance in the timestamp
value which is generous but up to +7 second discrepencies have been
seen in the CI. Bump the tolerance to +10 seconds to prevent these
false positives. As long as the value increases and is reasonably
close to the expected value consider that to be sufficient.
Reviewed-by: Christos Longros <chris.longros at gmail.com>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18733
Disconnect metaslab tracing from default builds
This code can not even be enabled without patching and has no use
without some external tools. 32 additional bytes in zio_t plus
their initialization/destruction is too high cost for rarely used
development tool.
Making it conditional under METASLAB_TRACE define reduces zio_t
on FreeBSD by 64 bytes due to stucture alignment and removed the
initialization from CPU profiles.
Reviewed-by: Paul Dagnelie <paul.dagnelie at klarasystems.com>
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #18714
zstream: multithreading
This PR extends the `zstream_chain` mechanism introduced in #18509 to
include support for multithreading. It makes three main changes.
- It adds `zstream_queue.[ch]`, a generic FIFO queue with multiple
worker threads. This is a freestanding construct not directly tied to
ZFS or to the `zstream_chain` mechanism.
- It adapts `zstream_chain.[ch]` to allow both single-threaded and
multithreaded steps.
- It converts `zstream_fletcher4.[ch]` and `zstream_recompress.[ch]`
to use multithreading.
### Motivation
This patch significantly speeds recompression on modern CPUs. The
ultimate goal is to add a `zstream dedup` or `zstream pack` subcommand
[92 lines not shown]
ZTS: cover key unload when a child's mountpoint sorts before its root
zfs_unmount_unload_keys.ksh only exercised hierarchy-aligned
mountpoints. The changelist unmounts in reverse alphabetical order of
mountpoint, so a nested child always sorted after and unmounted before
its encryption root, and the case where the root unmounts first was
never covered. Add a case whose child mountpoint sorts before its
root's, so the root is unmounted while the child still holds the
inherited key, and assert "zfs unmount -u" still unloads the key and
unmounts the whole subtree.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Ameer Hamza <ahamza at ixsystems.com>
Closes #18713
libzfs: defer encryption key unload until the subtree is unmounted
"zfs unmount -u" unloads a dataset's encryption key right after
unmounting it. changelist_prefix() unmounts the subtree in mountpoint
order and passes MS_CRYPT to zfs_unmount() for every node, so each key
is unloaded inline during the walk. A wrapping key is shared by an
encryption root and the children that inherit it, and can only be
unloaded once all of them are unmounted. Because the walk is ordered by
mountpoint rather than by hierarchy, an encryption root can be unmounted
before a child that still holds its key; unloading the key there fails
with EBUSY, aborting the unmount. This breaks "zfs unmount -u <encroot>"
whenever a key-sharing child is still mounted.
Strip MS_CRYPT in the unmount pass so no key is unloaded inline and the
whole subtree is torn down first. With everything unmounted, unload the
encryption-root keys in a second pass, stopping at the first failure.
If an unload fails because a dataset using the key is genuinely in use
(for example a bind or second mount), re-mount the subtree to undo the
unmount before returning the error. With one encryption root, the
[5 lines not shown]
libzfs: fix MS_CRYPT/MS_OVERLAY collision with umount2(2) flags
MS_CRYPT and MS_OVERLAY are libzfs-internal mount flags, but their
values (0x8 and 0x4) aliased the umount2(2) flags UMOUNT_NOFOLLOW and
MNT_EXPIRE. A consumer that legitimately set UMOUNT_NOFOLLOW therefore
had that bit read as MS_CRYPT, so libzfs unloaded the dataset's
encryption key as a side effect.
Move both flags to high bits unused by umount2(2) and strip them before
the unmount syscall in do_unmount() (umount2(2) on Linux, unmount(2) on
FreeBSD) and in cmd/zfs. MS_CRYPT is a compile-time macro, so consumers
that set it (for example truenas_pylibzfs) must be rebuilt against the
new header.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Ameer Hamza <ahamza at ixsystems.com>
Closes #18713
FreeBSD: Wire sha512 offload to the build
FreeBSD main just got the CPUID_STDEXT4_SHA512 define.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Rob Norris <rob.norris at truenas.com>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #18732
ZTS: l2arc_multidev_throughput_pos relax throughput window
Occasionally in the CI this test will fail because the throughput for
one of the windows drops slightly below 50%. This is likely due to
running in the virtualized CI environment. Drop the performance cutoff
from 50% to 40% to try and reduce the number of false positives.
Reviewed-by: Ameer Hamza <ahamza at ixsystems.com>
Signed-off-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Closes #18727
zbookmark_compare: handle "marker" bookmarks with negative levels
"Marker" bookmarks (those with zb_level == ZB_ROOT_LEVEL, ZB_ZIL_LEVEL
or ZB_DNODE_LEVEL) represent valid blocks, but are associated with a
dataset directly rather than with a specific object within it. They end
up on bookmark lists during scan prefetch, and so need to be sorted
ahead of any "true" object blocks.
The problem is that for negative levels, BP_SPANB produces a negative
shift, which is not legal C. Fortunately the results are used only for
comparison, so the worst possible behaviour in a forgiving compilation
environment is a mis-sort, which for the scan/traverse cases, means that
we haven't prefetched certain metadata before we actually need it. But
there _is_ UB in there, and UBSAN does rightly complain.
Here we fix all this by handling these bookmarks directly - sorting them
ahead of "true" object blocks, which is usually what scan/traverse will
prefer. And we don't do any interesting math on these bookmarks, so we
sidestep the whole UB thing.
[6 lines not shown]
Calling thread IO
Adds a module parameter that will allow waiting for bio's
to complete, along with a flag that tracks whether a zio
has bypassed the queue.
The motivation behind this change was performance based. The
intention was to reduce overhead caused by swapping between
threads from when bio's are submitted, and the callback executes.
Currently, only zio's who have bypassed the queue are allowed
to wait for bio completion, this is mainly done because any performance
uplift from staying in the same thread is overshadowed by the vdev
queue lock.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Migel Imeri <mimeri at lanl.gov>
Closes #18562
Fix insufficient locking in dedup verify
Introduction of dde_io_lock removed global DDT lock acquisition
from write completion. As result, white ZIO ABD could be freed
while zio_ddt_collision() is comparing against it. Taking there
dde_io_lock should fix the issue.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Alexander Motin <alexander.motin at TrueNAS.com>
Closes #17960
Closes #18712
Closes #18720
zpl_ctldir: remove comments describing ancient kernel behaviour
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18722
zfs_ctldir: move the invalid dentry check up to zpl_snapdir_automount()
If the dentry is invalid, don't even bother calling
zfsctl_snapshot_mount(). There's no practical change here, but it just
helps keep the notion of "invalidated dentry" in the binding.
Sponsored-by: TrueNAS
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Signed-off-by: Rob Norris <rob.norris at truenas.com>
Closes #18722
