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>
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>
As among possibly other things, it addresses a patch that got
backported to kernel 6.2.8 too.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
As reported having set 'mountpoint=legacy' on the root dataset (for a
default install this would be 'rpool/ROOT/pve-1') for mounting through
e.g. /etc/fstab breaks booting in initramfs
The cherry-picked patch is already applied to zfs-2.1.8-staging
upstream so will be included in the next zfs point release.
reproduced the issue on a VM with ZFS on root by:
* booting into a PVE 7.3 iso (to have zfs and an inactive
rpool/ROOT/pve-1)
* `zpool import -ocachefile=none -N -f rpool
* `zfs set mountpoint=legacy rpool/ROOT/pve-1`
* `mount -t zfs rpool/ROOT/pve-1 /mnt
* `echo "rpool/ROOT/pve-1 / zfs defaults 0 0" >> /mnt/etc/fstab`
* `zpool export rpool`
* reboot - the boot breaks with zfs-initramfs 2.1.7-pve1 but works
with this patch applied
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
While checking the current state of 2.1.6 we noticed that there were
some changes in debian-upstream [0] resulting from a bug-report in
zfs-upstream [1].
Our packages should be unaffected (they do not ship the
init-scripts in the first place).
Since the issue was fixed by zfs-upstream already on the
zfs-2.1.7-staging branch we should include it as well as it might save
users, who somehow got debian-upstream's zfs-packages installed on PVE
some trouble.
The other 2 changes seem small and isolated enough so including them
as well.
[0] https://salsa.debian.org/zfsonlinux-team/zfs/-/commits/master
[1] https://github.com/openzfs/zfs/issues/14010
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the changes to zvol_open added to 2.1.2 (for coping with kernel
changes in 5.13) seem to have introduced a lock order inversion [0].
(noticed while reviewing the 2.0.6->2.0.7 changes (the patch was
applied after 2.1.2 was already tagged)
[0] https://github.com/openzfs/zfs/pull/12863
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This commit updates Thomas' patch to deal with a 2.0 kernel module
with 2.1 arc_summary/arcstat
Tested by adding a cache-device to a zpool and running both commands
to verify no KeyError exception is thrown.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the patch fixes a potential panic on systems running ZFS > 2.0.0 and
is already queued for inclusion in 2.0.3 - see [0] for a related
github issue.
[0] https://github.com/openzfs/zfs/issues/11474
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
This patch addresses the problems some users experience when some zpools are
created/imported with cachefile (which then causes other pools not to get
imported during boot) - when our tooling creates a pool we explictly
instantiate the service with the pool's name, ensuring that it will get
imported by scanning.
Suggested-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
the last series of cherry-picks from salsa.d.o includes one patch for the
zfs-source, but the patch file does not contain ident-information.
This prevents it from being applied by import-patchqueue.
Fixed by adding ident based on the original patches commit message and
importing and exporting the patchqueue.
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Of the zedlet scripts shipped by upstream, a subset are enabled by
default, by creating symlinks in /etc/zfs/zed.d. These symlinks are
shipped in the zfs-zed package. dpkg, however, does not support
conffile handling of symlinks, and therefore any changes (removals) to
the symlinks are not preserved on package upgrade.
To address this policy violation, we:
1. During package build, create a list of enabled-by-default zedlets,
instead of creating symlinks.
2. On package removal, identify all enabled-by-default zedlets whose
symlinks do not exist (i.e., were removed by the user). This is done
by creating "whiteout" links to /dev/null in their place).
3. On package installation, create links to enabled-by-default zedlets
UNLESS there is already a file there (i.e., abort if there is a
whiteout link).
4. We also clean up broken symlinks to removed zedlets at package
postinst.
(cherry picked and adapted from 5cee380324d74e640d5dd7a360faba3994c8007f [0])
[0] https://salsa.debian.org/zfsonlinux-team/zfs.git
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
