Hi Robie, You're right, the patch does essentially invert the problem. This is still the behavior upstream, and it currently works like you mentioned: if the user tries to set a min above the default max (ramsize/2), it fails.
I'm working on a patch to propose upstream that should fix this. We should be setting min/max values as a pairs else we'll run into a similar issue as the one reported here. I'm also going to double check other tunables to see if they exhibit similar issues, so we can avoid further problems on those too. For this particular LP bug, do you think we should wait until a "proper" fix upstream? I do understand the point about breaking setups relying on the current min/max behavior, but that will also happen when upgrading to newer releases. My (subjective) opinion is that users trying to reduce ZFS memory footprint are much more common than the alternative, and for high memory systems this is currently not possible due to this bug. What do you think? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to zfs-linux in Ubuntu. https://bugs.launchpad.net/bugs/1964992 Title: ZFS ignores ARC sizes below allmem/32 Status in zfs-linux package in Ubuntu: Fix Released Status in zfs-linux source package in Bionic: Fix Released Status in zfs-linux source package in Focal: Incomplete Bug description: [Impact] ZFS ignores tunable "zfs_arc_max" due to it being below allmem/32 threshold. This prevents users from properly restraining ARC sizes, and can cause increased memory contention in some systems. [Test Plan] 1. Deploy test system with ZFS storage and 32GB RAM 2. Add ARC tunables to /etc/modprobe.d/99-zfs-arc.conf # cat /etc/modprobe.d/99-zfs-arc.conf options zfs zfs_arc_min=536870912 options zfs zfs_arc_max=966367641 3. Reboot system 4. Verify ARC sizes through "arc_summary" # arc_summary | grep -A3 "ARC size" ARC size (current): < 0.1 % 1.3 MiB Target size (adaptive): 100.0 % 15.7 GiB Min size (hard limit): 3.2 % 512.0 MiB Max size (high water): 31:1 15.7 GiB For a 32GB test system, we should be able to set max ARC sizes below 1GB. [Fix] This has been fixed by upstream commit: - 36a6e2335c45 "Don't ignore zfs_arc_max below allmem/32" The commit has been introduced in upstream zfs-2.0.0, so it's needed for Bionic and Focal. Releases starting with Impish already have this commit by default: $ git describe --contains 36a6e2335c45 zfs-2.0.0-rc1~332 $ rmadison zfs-linux zfs-linux | 0.7.5-1ubuntu15 | bionic | source zfs-linux | 0.7.5-1ubuntu16.12 | bionic-updates | source zfs-linux | 0.8.3-1ubuntu12 | focal | source zfs-linux | 0.8.3-1ubuntu12.9 | focal-security | source zfs-linux | 0.8.3-1ubuntu12.13 | focal-updates | source zfs-linux | 0.8.3-1ubuntu12.14 | focal-proposed | source zfs-linux | 2.0.6-1ubuntu2 | impish | source zfs-linux | 2.0.6-1ubuntu2.1 | impish-updates | source zfs-linux | 2.1.2-1ubuntu3 | jammy | source [Regression Potential] The introduced commit essentially removes the limitation of setting ARC tunables below allmem/32, and re-arranges the order of how some of the tunables are parsed. Regressions would possibly show up as other tunables being ignored or not being set correctly due to parsing errors. We should validate whether other ARC related tunables are still being set correctly, and whether ZFS is using the set values for the ARC memory thresholds. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1964992/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
