kern/189865: [zfs] [patch] zfs_dirty_data_max{,_max,_percent} not exported as loader tunables
Nathaniel W Filardo
nwf at cs.jhu.edu
Wed May 21 04:10:01 UTC 2014
The following reply was made to PR kern/189865; it has been noted by GNATS.
From: Nathaniel W Filardo <nwf at cs.jhu.edu>
To: Steven Hartland <killing at multiplay.co.uk>
Cc: bug-followup at freebsd.org
Subject: Re: kern/189865: [zfs] [patch] zfs_dirty_data_max{,_max,_percent}
not exported as loader tunables
Date: Wed, 21 May 2014 00:09:20 -0400
--wwU9tsYnHnYeRAKj
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, May 20, 2014 at 09:38:04AM +0100, Steven Hartland wrote:
> Exposing zfs_dirty_data_max directly doesn't make sense as its
> a calculated value based off zfs_dirty_data_max_percent% of
> all memory and capped at zfs_dirty_data_max_max.
I'm pretty sure the intention is that it is computed that way only if not
set already -- there's a comparison for =3D=3D 0 before the value is assign=
ed.
See arc_init():
http://fxr.watson.org/fxr/source/cddl/contrib/opensolaris/uts/common/fs/zfs=
/arc.c?im=3Dexcerpts#L4150
And in the Old World, the zfs.write_limit_override was similarly exported to
override the similar computation of zfs.write_limit_max. That said, no,
I don't really care too much about this particular tunable; I was just
mirroring Solaris.
=20
> Given this it could be limited via setting zfs_dirty_data_max_max.
Sure.
=20
> The following could be exposed:-
> zfs_dirty_data_max_max
> zfs_dirty_data_max_percent
> zfs_dirty_data_sync
> zfs_delay_min_dirty_percent
> zfs_delay_scale
>=20
> Would that forfull your requirement?
It's overkill for my case, but yes, those should probably all be exposed.
Cheers,
--nwf;
--wwU9tsYnHnYeRAKj
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iEYEARECAAYFAlN8Ju8ACgkQTeQabvr9Tc/DSgCfal/L6J9s0NE+FhhAG5E+IS0J
u4QAn0u66uK6MINAPKpcdCgVNSwJhIwk
=Mnqx
-----END PGP SIGNATURE-----
--wwU9tsYnHnYeRAKj--
More information about the freebsd-fs
mailing list