ZFS 2.2.4 added new kstats for speculative prefetch in:
026fe796465e3da7b27d06ef5338634ee6dd30d8
Adapt our patch introduced with ZFS 2.1 (for the then added MFU/MRU
stats), to also deal with the now introduced values not being present
(because an old kernel-module does not offer them).
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Max Carrara <m.carrara@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
mostly - drop all patches we had queued up to get kernel 6.8
supported.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-by: Max Carrara <m.carrara@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this should fix failures of the template instances because either of
the two other import services picked up the pool in question first.
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Use the current ZFS 2.2.4 staging tree [0] with commit deb7a8423 ("Fix
corruption caused by mmap flushing problems") on top.
Additionally, include an open, but ack'd, pull request [1] that avoids
a potential general protection fault due to touching a vbio after it
was handed off to the kernel.
[0]: https://github.com/openzfs/zfs/commits/zfs-2.2.4-staging/
[1]: https://github.com/openzfs/zfs/pull/16049
Both should mostly touch the module code.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
If a zvol has more than 15 partitions, the minor device number
exhausts the slot count reserved for partitions next to the zvol
itself. As a result, the minor number cannot be used to determine the
partition number for the higher partition, and doing so results in
wrong named symlinks being generated by udev.
Since the partition number is encoded in the block device name anyway,
let's just extract it from there instead.
For upstream issue and PR discussion see:
https://github.com/openzfs/zfs/pull/15970https://github.com/openzfs/zfs/issues/15904
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
mostly support for newer kernel-versions, and fixes for the BRT bugs
discovered with 2.2.0 (BRT remains disabled by default).
The update contains a fix for CVE-2020-24370 in lua (which is present
in ZFS for channel-programs, which we do not use) - see:
https://github.com/openzfs/zfs/pull/15847 for more details.
One patch from Stefan Lendl was backported and is now in the ZFS 2.2
branch.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
When running `zfs mount -a`, prevent the exported datasets (with sharenfs)
to be truncated (unexported).
Adds tests to verify shares persist after mount -a
Signed-off-by: Stefan Lendl <s.lendl@proxmox.com>
ZFS 2.2.1 is currently being prepared, but the 3 patches added here
seem quite relevant, as the might cause dataloss/panics on setups
which run `zpool upgrade`.
See upstreams discussion for 2.2.1:
https://github.com/openzfs/zfs/pull/15498/
and the most critical issue:
https://github.com/openzfs/zfs/pull/15529
finally:
459c99ff23
should not hurt either
the change to the UBSAN patch (0013) is unrelate, cosmetic only and
happened by running export-patchqueue.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
While I think the huge performance optimization was at some point not
really that huge in practice - the feature sounds like it would
benefit our use-case:
https://github.com/openzfs/zfs/pull/13148
currently the feature is disabled in 2.2.0 (see the second patch),
because of the issues addressed by the first patch
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
This was integrated into upstreams autoconf in commit:
e69ade32e116e72d03068c03799924c3f1a15c95
(contrib: bash_completion.d: make install destination vendor
dependent)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Lots of targeted commands consisting of a single file as source got
moved a level up from their command-specific sub-directory to cmd/
directory directly.
A handful of build-artefacts like configure/m4 files generated by
auto-tools, was removed from being tracked by git.
Then some stuff was simple unused or broken and got deleted
(vdev_cache, zfs_spa).
Others where replaced (sha256 by general sha2 library, zstreamdump by
zstream).
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Cater to dh_missing complaints and ship new:
- zilstat tool
- zfs-lock and zfs-unlock manual pages in section 8
- vdevprops manual page in section 7
- systemd template unit files for trimming a specific pool, inclusive
timers to do so on a weekly and/or monthly basis. Keep those covered
by our default "no-stop-on-upgrade" rule for the dh_systemd helper.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
With ZFS 2.2. they're actually only installed if ZFS is being build
for FreeBSD, so not remvoing them here leads to a missing file error.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
vmexit's can cause the AMX registers to "misbehave" which can break
ZFS, even though ZFS doesn't use AMX at all.
This causes crashes and processes hanging forever in uninterruptible
sleep (the infamous D state) on Intel Xeon 4th gen HW, possible other
HW too, but we only got reports on Sapphire Rapids models.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Tested-by: Aaron Lauterer <a.lauterer@proxmox.com>
