cmd/zed/zed.d/Makefile.am | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 track default symlinks, instead of symlinking

config/dkms.m4 | 14 14 + 0 - 0 !
config/user.m4 | 1 1 + 0 - 0 !
2 files changed, 15 insertions(+)

 block manual building in the dkms source tree.
  To avoid messing up future DKMS builds and the zfs installation,
  block manual building of the DKMS source tree.

config/zfs-meta.m4 | 33 28 + 5 - 0 !
1 file changed, 28 insertions(+), 5 deletions(-)

 check for meta and dch consistency in autoconf

etc/systemd/system/zfs-volume-wait.service.in | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 relocate the executable path

cmd/zed/zed.d/zed.rc | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 enable zed emails
 The OpenZFS event daemon monitors pools.  This patch enables the email
 sending function by default (if zed is installed).  This is consistent with
 the default behavior of mdadm.

etc/systemd/system/zfs-zed.service.in | 2 1 + 1 - 0 !
etc/zfs/zfs-functions.in | 2 1 + 1 - 0 !
2 files changed, 2 insertions(+), 2 deletions(-)

 fix the path to the zed binary on the systemd unit.
 We install zed into /usr/sbin manually meanwhile the upstream default
 is installing it into /sbin.
 Ubuntu packages also install zed to /usr/sbin, but they ship their own
 zfs-zed unit.

scripts/dkms.mkconf | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

---

contrib/dracut/90zfs/module-setup.sh.in | 3 2 + 1 - 0 !
etc/systemd/system/50-zfs.preset.in | 1 1 + 0 - 0 !
etc/systemd/system/Makefile.am | 1 1 + 0 - 0 !
etc/systemd/system/zfs-import-cache.service.in | 2 2 + 0 - 0 !
etc/systemd/system/zfs-import-scan.service.in | 2 2 + 0 - 0 !
etc/systemd/system/zfs-load-module.service.in | 17 17 + 0 - 0 !
6 files changed, 25 insertions(+), 1 deletion(-)

 explicitly load the zfs module via systemd service

lib/libzfs/os/linux/libzfs_util_os.c | 9 9 + 0 - 0 !
1 file changed, 9 insertions(+)

---

config/Rules.am | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 force libtool to produce verbose output

cmd/zvol_wait/zvol_wait | 10 9 + 1 - 0 !
1 file changed, 9 insertions(+), 1 deletion(-)

 don't wait for links when volume has property keystatus=unavailable
  zfs-volume-wait.service systemd unit does not start if the encrypted
  zvol is locked. The /sbin/zvol_wait should not wait for links when the
  volume has property keystatus=unavailable. This patch fixes this issue
Bug: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1888405

man/Makefile.am | 2 1 + 1 - 0 !
man/Makefile.in | 2 1 + 1 - 0 !
man/man1/arcstat.1 | 184 0 + 184 - 0 !
man/man8/arcstat.8 | 184 184 + 0 - 0 !
4 files changed, 186 insertions(+), 186 deletions(-)

---

scripts/dkms.mkconf | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 do not attempt to build the modules on preempt_rt kernels

module/zstd/zfs_zstd.c | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 bump zzstd.ko module version number.
  All modules are going to be merged into one upstream soon. At the
  moment all other modules increase with every build, but zzstd
  one. Append zfs package version to zzstd module version number, to
  make dkms module versions higher than kernel prebuilt ones.

scripts/dkms.mkconf | 6 6 + 0 - 0 !
1 file changed, 6 insertions(+)

 fix cross-compile of the dkms module.

man/man4/zfs.4 | 2 1 + 1 - 0 !
module/zfs/dsl_scan.c | 28 16 + 12 - 0 !
2 files changed, 17 insertions(+), 13 deletions(-)

 [patch] increase default zfs_scan_vdev_limit to 16mb

For HDD based pools the default zfs_scan_vdev_limit of 4M
per-vdev can significantly limit the maximum scrub performance.
Increasing the default to 16M can double the scrub speed from
80 MB/s per disk to 160 MB/s per disk.

This does increase the memory footprint during scrub/resilver
but given the performance win this is a reasonable trade off.
Memory usage is capped at 1/4 of arc_c_max.  Note that number
of outstanding I/Os has not changed and is still limited by
zfs_vdev_scrub_max_active.

man/man4/zfs.4 | 2 1 + 1 - 0 !
module/zfs/vdev_rebuild.c | 27 18 + 9 - 0 !
2 files changed, 19 insertions(+), 10 deletions(-)

 [patch] increase default zfs_rebuild_vdev_limit to 64mb

When testing distributed rebuild performance with more capable
hardware it was observed than increasing the zfs_rebuild_vdev_limit
to 64M reduced the rebuild time by 17%.  Beyond 64MB there was
some improvement (~2%) but it was not significant when weighed
against the increased memory usage. Memory usage is capped at 1/4
of arc_c_max.

Additionally, vr_bytes_inflight_max has been moved so it's updated
per-metaslab to allow the size to be adjust while a rebuild is
running.

contrib/initramfs/scripts/zfs | 54 35 + 19 - 0 !
1 file changed, 35 insertions(+), 19 deletions(-)

 [patch] rootdelay on zfs should be adaptive

The 'rootdelay' boot option currently pauses the boot for a specified
amount of time. The original intent was to ensure that slower
configurations would have ample time to enumerate the devices to make
importing the root pool successful. This, however, causes unnecessary
boot delay for environments like Azure which set this parameter by
default.

This commit changes the initramfs logic to pause until it can
successfully load the 'zfs' module. The timeout specified by
'rootdelay' now becomes the maximum amount of time that initramfs will
wait before failing the boot.

cmd/zdb/zdb.c | 7 5 + 2 - 0 !
1 file changed, 5 insertions(+), 2 deletions(-)

 [patch] zdb: zero-pad checksum output

The leading zeroes are part of the checksum so we should show them.

include/sys/spa.h | 2 1 + 1 - 0 !
1 file changed, 1 insertion(+), 1 deletion(-)

 [patch 01/13] zdb: zero-pad checksum output follow up

Apply zero padding for checksums consistently.  The SNPRINTF_BLKPTR
macro was not updated in commit ac7648179c8 which results in the
`cli_root/zdb/zdb_checksum.ksh` test case reliably failing.

include/sys/spa.h | 1 1 + 0 - 0 !
module/zfs/spa.c | 5 3 + 2 - 0 !
module/zfs/vdev.c | 12 11 + 1 - 0 !
3 files changed, 15 insertions(+), 3 deletions(-)

 [patch] fix "detach spare vdev in case if resilvering does not
 happen"
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Spare vdev should detach from the pool when a disk is reinserted.
However, spare detachment depends on the completion of resilvering,
and if resilver does not schedule, the spare vdevkeeps attached to
the pool until the next resilvering. When a zfs pool contains
several disks (25+ mirror), resilvering does not always happen when
a disk isreinserted. In this patch, spare vdev is manually detached
from the pool when resilvering does not occur and it has been tested
on both Linux and FreeBSD.

module/zfs/dmu_send.c | 8 6 + 2 - 0 !
1 file changed, 6 insertions(+), 2 deletions(-)

 [patch] fix null pointer dereference when doing concurrent 'send'
 operations
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

A NULL pointer will occur when doing a 'zfs send -S' on a dataset that
is still being received.  The problem is that the new 'send' will
rightfully fail to own the datasets (i.e. dsl_dataset_own_force() will
fail), but then dmu_send() will still do the dsl_dataset_disown().

contrib/initramfs/scripts/zfs | 6 3 + 3 - 0 !
1 file changed, 3 insertions(+), 3 deletions(-)

 [patch] revert "initramfs: use `mount.zfs` instead of `mount`"

This broke mounting of snapshots on / for users.

See https://github.com/openzfs/zfs/issues/9461#issuecomment-1376162949 for more context.

module/zfs/zil.c | 1 1 + 0 - 0 !
1 file changed, 1 insertion(+)

 [patch] zil: don't expect zio_shrink() to succeed.

At least for RAIDZ zio_shrink() does not reduce zio size, but reduced
wsz in that case likely results in writing uninitialized memory.

module/os/linux/spl/spl-kmem-cache.c | 12 11 + 1 - 0 !
1 file changed, 11 insertions(+), 1 deletion(-)

 [patch] linux: never sleep in kmem_cache_alloc(..., km_nosleep)
 (#14926)

When a kmem cache is exhausted and needs to be expanded a new
slab is allocated.  KM_SLEEP callers can block and wait for the
allocation, but KM_NOSLEEP callers were incorrectly allowed to
block as well.

Resolve this by attempting an emergency allocation as a best
effort.  This may fail but that's fine since any KM_NOSLEEP
consumer is required to handle an allocation failure.

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>

module/zfs/dnode.c | 12 10 + 2 - 0 !
1 file changed, 10 insertions(+), 2 deletions(-)

 [patch] dnode_is_dirty: check dnode and its data for dirtiness

Over its history this the dirty dnode test has been changed between
checking for a dnodes being on `os_dirty_dnodes` (`dn_dirty_link`) and
`dn_dirty_record`.

  de198f2d9 Fix lseek(SEEK_DATA/SEEK_HOLE) mmap consistency
  2531ce372 Revert "Report holes when there are only metadata changes"
  ec4f9b8f3 Report holes when there are only metadata changes
  454365bba Fix dirty check in dmu_offset_next()
  66aca2473 SEEK_HOLE should not block on txg_wait_synced()

Also illumos/illumos-gate@c543ec060d illumos/illumos-gate@2bcf0248e9

It turns out both are actually required.

In the case of appending data to a newly created file, the dnode proper
is dirtied (at least to change the blocksize) and dirty records are
added.  Thus, a single logical operation is represented by separate
dirty indicators, and must not be separated.

The incorrect dirty check becomes a problem when the first block of a
file is being appended to while another process is calling lseek to skip
holes. There is a small window where the dnode part is undirtied while
there are still dirty records. In this case, `lseek(fd, 0, SEEK_DATA)`
would not know that the file is dirty, and would go to
`dnode_next_offset()`. Since the object has no data blocks yet, it
returns `ESRCH`, indicating no data found, which results in `ENXIO`
being returned to `lseek()`'s caller.

Since coreutils 9.2, `cp` performs sparse copies by default, that is, it
uses `SEEK_DATA` and `SEEK_HOLE` against the source file and attempts to
replicate the holes in the target. When it hits the bug, its initial
search for data fails, and it goes on to call `fallocate()` to create a
hole over the entire destination file.

This has come up more recently as users upgrade their systems, getting
OpenZFS 2.2 as well as a newer coreutils. However, this problem has been
reproduced against 2.1, as well as on FreeBSD 13 and 14.

This change simply updates the dirty check to check both types of dirty.
If there's anything dirty at all, we immediately go to the "wait for
sync" stage, It doesn't really matter after that; both changes are on
disk, so the dirty fields should be correct.

Sponsored-by: Klara, Inc.
Sponsored-by: Wasabi Technology, Inc.

module/zfs/vdev_trim.c | 28 19 + 9 - 0 !
1 file changed, 19 insertions(+), 9 deletions(-)

 [patch] zpool can start allocating from metaslab before trims have
 completed

When doing a manual TRIM on a zpool, the metaslab being TRIMmed is
potentially re-enabled before all queued TRIM zios for that metaslab
have completed. Since TRIM zios have the lowest priority, it is
possible to get into a situation where allocations occur from the
just re-enabled metaslab and cut ahead of queued TRIMs to the same
metaslab.  If the ranges overlap, this will cause corruption.

We were able to trigger this pretty consistently with a small single
top-level vdev zpool (i.e. small number of metaslabs) with heavy
parallel write activity while performing a manual TRIM against a
somewhat 'slow' device (so TRIMs took a bit of time to complete).
With the patch, we've not been able to recreate it since. It was on
illumos, but inspection of the OpenZFS trim code looks like the
relevant pieces are largely unchanged and so it appears it would be
vulnerable to the same issue.

lib/libshare/os/linux/nfs.c | 47 42 + 5 - 0 !
man/man8/zfs.8 | 2 1 + 1 - 0 !
2 files changed, 43 insertions(+), 6 deletions(-)

 [patch] libshare: nfs: pass through ipv6 addresses in bracket
 notation
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Recognize when the host part of a sharenfs attribute is an ipv6
Literal and pass that through without modification.