From owner-freebsd-fs@FreeBSD.ORG Wed May 21 04:10:01 2014 Return-Path: Delivered-To: freebsd-fs@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 872BEA36 for ; Wed, 21 May 2014 04:10:01 +0000 (UTC) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 72F79252A for ; Wed, 21 May 2014 04:10:01 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.8/8.14.8) with ESMTP id s4L4A1u1025235 for ; Wed, 21 May 2014 04:10:01 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.8/8.14.8/Submit) id s4L4A1GQ025225; Wed, 21 May 2014 04:10:01 GMT (envelope-from gnats) Date: Wed, 21 May 2014 04:10:01 GMT Message-Id: <201405210410.s4L4A1GQ025225@freefall.freebsd.org> To: freebsd-fs@FreeBSD.org Cc: From: Nathaniel W Filardo Subject: Re: kern/189865: [zfs] [patch] zfs_dirty_data_max{,_max,_percent} not exported as loader tunables Reply-To: Nathaniel W Filardo X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 May 2014 04:10:01 -0000 The following reply was made to PR kern/189865; it has been noted by GNATS. From: Nathaniel W Filardo To: Steven Hartland Cc: bug-followup@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--