Thanks for testing Nathan, that is the expected behaviour it might be nice if we had the concept of a sysctl which is at its auto value and hence we could use that to determine if we should recalculate said automatic values which hadn't been manually set but we don't have that unfortunately. On 08/07/2016 07:48, Nathan Bosley wrote: > I was just testing this a bit. > I can now set max in loader.conf as expected. > > I did notice one thing that I thought was a bit strange though. > > As a reference, here are my defaults without any ARC tunables/sysctls: > > vfs.zfs.arc_meta_limit: 3903459328 > vfs.zfs.arc_min: 1951729664 > vfs.zfs.arc_max: 15613837312 > > If I put vfs.zfs.arc_max="8589934592" in loader.conf, the results are: > > vfs.zfs.arc_meta_limit: 2147483648 > vfs.zfs.arc_min: 1073741824 > vfs.zfs.arc_max: 8589934592 > > So meta_limit and min are also changed, which is reasonable. > > If I remove all of my ARC tunables in loader.conf, so that I have the > default values after booting, and then use: > # sysctl vfs.zfs.arc_max="8589934592" > > The result is: > > vfs.zfs.arc_meta_limit: 2147483648 > vfs.zfs.arc_min: 1951729664 > vfs.zfs.arc_max: 8589934592 > > Max was set as requested. > meta_limit was set to max/4. > But min is still at the default. > > In other words, if I use loader.conf to set max, then min and > meta_limit are also recalculated. > But if I use sysctl to set max, only meta_limit is recalculated; min > remains at the default. > I'm not sure if that's the intent. > > Just a heads-up. > > Thanks again. > > On Wed, Jul 6, 2016 at 7:51 PM, Steven Hartland > <killing_at_multiplay.co.uk <mailto:killing_at_multiplay.co.uk>> wrote: > > On 06/07/2016 21:39, Eric van Gyzen wrote: > > On 07/06/16 03:35 PM, Steven Hartland wrote: > > The ARC settings and kmem aren't initialised when tunables > are loaded > so the tests fail. > > I've fixed this locally by blindly setting if ARC is not > configured. > Request to commit the fix is with re_at_ > > In the mean time the patch is attached. > > Thanks for the report and sorry about the breakage. > > No worries. Thanks for the quick fix. > > https://svnweb.freebsd.org/changeset/base/302382 > > _______________________________________________ > freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> > mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscribe_at_freebsd.org > <mailto:freebsd-current-unsubscribe_at_freebsd.org>" > >Received on Fri Jul 08 2016 - 13:04:51 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:06 UTC