the following patch seems applicable and might fix an issue observed
in our enterprise support a while ago. containers run in their own
cgroups, thus were probably not scanned by the kernel shrinker - this
resulted in Dnode cache numbers of 300+% reported in arc_summary.
FWICT the issue was introduced in ZFS 2.2.7
(commit 5f73630e9cbea5efa23d16809f06e0d08523b241 see:
https://github.com/openzfs/zfs/issues/17052#issuecomment-3065907783)
but I assume that the increase of zfs_arc_max by default makes it
trigger OOMs far easier.
The discussion of the PR was quite instructive:
https://github.com/openzfs/zfs/pull/17542
minimally tested on a pair of trixie VMs (building + running
replication of a couple of containers)
Suggested-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Link: https://lore.proxmox.com/20250723181453.1082366-1-s.ivanov@proxmox.com
minor changes found by `diff -ru` on debian/ with the one in
debian-upstream
based on https://salsa.debian.org/zfsonlinux-team/zfs/
commits: 3b029ca123417535a53efa23f54975649924c66c
3b029ca123417535a53efa23f54975649924c66c
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
adapted commit e1e64f07af5c4ca2a313625a15c24e4ad6fb42f1 from
debian-upstream https://salsa.debian.org/zfsonlinux-team/zfs/:
- arc_summary and zilstat do not require privilege.
- arcstat does not need root, but the name is taken by nordugrid-arc-client.
- dbufstat needs root permission to read /proc/spl/kstat.
See: #1064835, #1063457
Originally-by: Shengqi Chen <harry-chen@outlook.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
moving file canonical locations from e.g. /lib to /usr/lib (usr-merge)
while renaming a package (libzfs4linux -> libzfs6linux) could result
in file deletions during upgrades. The following workaround has been
used in debian upstream.
see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1092598 for the
details.
based on commit 0431247714965007bc156fd57852689b395b2bae
https://salsa.debian.org/zfsonlinux-team/zfs/
Originally-by: Shengqi Chen <harry-chen@outlook.com>
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Drop the package-supports-alternative-init-but-no-init.d-script
overrides, as that is an alien-tag for lintian nowadays.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
> Since Debian Trixie, the base-files package sets up symbolic links
> such as /bin pointing to usr/bin. Installing files in /bin directly
> thus triggers undefined behaviour in dpkg.
-- lintian-explain-tags aliased-location
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
Otherwise one gets a error on configure. Found when building inside a
clean sbuild environment.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
The 6.13 kernel is supported without any additional changes required
and 6.14 needs only two smaller ones, so backport them to 2.2.7 to be
able to provide a more recent opt-in kernel soonish.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
zfs-initramfs ships an initramfs-tools boot script that
unconditionally activates all LVs on boot. This can cause issues if
the LV resides on a shared LVM VG on top of a shared LUN, in
particular Fibre Channel / directed-attached SAS LUNs, as these are
usually visible at boot time. See bug #4997 [1] for more details.
To avoid this, patch zfs-initramfs such that it performs LVM
autoactivation instead. Thus, it honors the `--setautoactivation n`
flag that is normally used to disable autoactivation during boot for
particular VGs/LVs.
[1] https://bugzilla.proxmox.com/show_bug.cgi?id=4997
Signed-off-by: Friedrich Weber <f.weber@proxmox.com>
Reviewed-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
[TL: resolve merge conflict in d/patches with another fix that got
applied sooner and improve subject]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
this broke with 2.2.7, and can potentially cause data loss or
inconsistency. the patch basically reverts to pre-2.2.7 behaviour,
verified via a fio benchmark.
reported on our forum: https://forum.proxmox.com/threads/163066
cherry-picked from upstream master
Signed-off-by: Fabian Grünbichler <f.gruenbichler@proxmox.com>
Tested-by: Stoiko Ivanov <s.ivanov@proxmox.com>
Reviewed-by: Stoiko Ivanov <s.ivanov@proxmox.com>
[TL: more telling subject]
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
drop the cherry-picked kernel 6.11 compatibility patches.
this upstream release [0] is a bit larger than usual, and might have a bit
of potential for regressions.
apart from the compatibilty fixes for newer kernels (up until 6.12),
fixes to the testsystem,ci and fixes for FreeBSD the following might be
interesting for our use-cases:
* 308d04ac3 ("Fix inconsistent mount options for ZFS root")
* bc0d89bfc ("Fix an uninitialized data access (#16511)")
* f4e66db40 ("vdev_disk: move abd return and free off the interrupt handler")
* 0f86fcc2a ("Linux: Fix zfs_prune panics")
* cf80a803d ("zvol: ensure device minors are properly cleaned up")
* 299da6ace ("Fix race in libzfs_run_process_impl")
* 0bd8481aa ("add get_name implementation for exports. (#16833)")
I did some minimal testing on 2 VM's with a few nested containers and
storage replication, additionally I installed that version on a VM with
/ on ZFS - mostly for checking 308d04ac3 in our environment.
[0] https://github.com/openzfs/zfs/releases/tag/zfs-2.2.7
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
All merged already into upstream, only one conflict with (missing)
change in context had to be resolved for the flex-array in ZFS log
patch.
Signed-off-by: Thomas Lamprecht <t.lamprecht@proxmox.com>
When initially packaging libzfsbootenv1linux a .install file was
commited in addtion to the .install.in (which contains the proper path
with the multiarch component). This wasn't noticed during building
because the .install got clobbered while building
Fixes: fd0cc4becd
Signed-off-by: Stoiko Ivanov <s.ivanov@proxmox.com>
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>
