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>
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>
This does:
* fix get_transp() on non-bash
* re-indent of the code from #990745
* fix terminology: it's pool
* remove -e: I originally actually fixed -e,
but it turns out literally every bit that could fail
is already either || : or wasn't by accident (like in the #990745 code)
* simplify get_transp() and explain why we do it instead of matching nvme path
* use remove -L from the data we feed to lsblk, zpool w/o -L is measurably faster
* pipe the devices into while read to match rest of code
* use read -r in main loop
* match the userprop with case/esac instead of if tree
* shellcheck-clean the script
(cherry picked from debian-upstream[0]
commit 769a09407c6b65db981804a05a81ea63d004ebeb)
[0] https://salsa.debian.org/zfsonlinux-team/zfs
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>
following debian upstream (which pulled it in from Ubuntu in
44915cf387d45a123b11a8c24d3f30a8fdbcc532)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
following commit da40a1b007d2a99bac95bd67ec6dd7b8e217c0cf from
debian-upstream.
However since some of our rust-packages seem to depend on
libcurl4-gnutls-dev (via librust-curl-sys-dev) we add a
option for the dependency - I would assume that both should work
equally well (the callers are in upstream/lib/libzfs/libzfs_crypto.c)
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Thomas Lamprecht