From owner-freebsd-fs@FreeBSD.ORG Thu Mar 3 19:23:47 2011 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 0946E106566B; Thu, 3 Mar 2011 19:23:47 +0000 (UTC) (envelope-from freebsd-listen@fabiankeil.de) Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) by mx1.freebsd.org (Postfix) with ESMTP id 8B2968FC0C; Thu, 3 Mar 2011 19:23:46 +0000 (UTC) Received: from [78.34.156.215] (helo=r500.local) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1PvE7k-0002Pi-Ha; Thu, 03 Mar 2011 20:23:44 +0100 Date: Thu, 3 Mar 2011 20:23:39 +0100 From: Fabian Keil To: Alexander Leidinger Message-ID: <20110303202339.585b0c0b@r500.local> In-Reply-To: <20110303135147.20096fpe1ntz75k8@webmail.leidinger.net> References: <20110227202957.GD1992@garage.freebsd.pl> <20110228192129.119cac0c@r500.local> <20110228214847.0000078c@unknown> <20110303130130.29a066a1@r500.local> <20110303135147.20096fpe1ntz75k8@webmail.leidinger.net> X-Mailer: Claws Mail 3.7.8 (GTK+ 2.22.1; amd64-portbld-freebsd9.0) X-PGP-KEY-URL: http://www.fabiankeil.de/gpg-keys/freebsd-listen-2008-08-18.asc Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/rAZvbCaHCnRG73fv8zdj+23"; protocol="application/pgp-signature" X-Df-Sender: 775067 Cc: freebsd-fs@FreeBSD.org, freebsd-current@FreeBSD.org, Pawel Jakub Dawidek Subject: Re: HEADS UP: ZFSv28 is in! X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 19:23:47 -0000 --Sig_/rAZvbCaHCnRG73fv8zdj+23 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Alexander Leidinger wrote: > Quoting Fabian Keil (from Thu, 3 Mar =20 > 2011 13:01:30 +0100): >=20 > > Alexander Leidinger wrote: > > > >> On Mon, 28 Feb 2011 19:21:29 +0100 Fabian Keil > >> wrote: > >> > >> > Pawel Jakub Dawidek wrote: > >> > > >> > > I just committed ZFSv28 to HEAD. > >> > > >> > I updated the system without removing the tuning for ZFSv15 > >> > first, and somehow this completely messed up the performance. > >> > Booting the system took more than ten minutes and even once > >> > it was up it was next to unresponsive. > >> > > >> > I'm not sure which sysctl was to blame, but after removing > >> > all but vfs.zfs.arc_max=3D"800M" and rebooting, the problem > >> > was gone. > >> > >> When you add the tuning back, does it take minutes again to boot? If > >> not, I assume it was cleaning up some leftovers the old version was not > >> able to cleanup. > > > > I haven't tried that yet, but as I didn't upgrade the system's > > storage pool I don't think ZFS is supposed to do any such clean-ups. >=20 > AFAIK the new code knows how to remove some superfluous parts in your =20 > pool (no matter at which version the pool is), which the old code just =20 > skipped over. Such leftovers may not be in all pools, they show up =20 > just in some use cases. For this reason I asked to verify by adding =20 > the tuning back to this system (if possible). I don't have an exact list of sysctls I used earlier, but after commenting in all the zfs sysctls in loader.conf (some of which must have been commented out for quite some time) the problem was back. I interrupted the boot process after 14 minutes at which point the ezjail rc script was running for several minutes already, but still busy with the first jail. Usually this takes only a few seconds. The sysctls used were: #vfs.zfs.txg.timeout=3D5 Seems to be the default now. # vfs.zfs.zil_disable=3D1 No longer supported. # vfs.zfs.prefetch_disable=3D0 The default seems to be 1. # vfs.zfs.write_limit_override=3D15 Clearly the value makes no sense, so this may not have been active at the time of the update. I had a back-ported patch to add the sysctl, so at least in theory it should have caused problems with v15, too, unless there was a sanity check to ignore obviously incorrect values. The auto-tuned write-limit values are: vfs.zfs.write_limit_max: 258863616 vfs.zfs.write_limit_min: 33554432 # vfs.zfs.vdev.max_pending=3D15 The auto-tuned value is 10. vfs.zfs.arc_max=3D"800M" # vfs.zfs.arc_min=3D"500M" # vfs.zfs.vdev.cache.size=3D"5M" The auto-tuned value is 10485760 which seems close enough. # vfs.zfs.txg.synctime=3D1 This sysctl doesn't seem to exist (anymore). #vfs.zfs.cache_flush_disable=3D1 The default is 0. # vfs.zfs.txg.write_limit_override=3D134217728 Doesn't seem to exist (anymore) either. #vfs.zfs.vdev.max_pending=3D2 #vfs.zfs.vdev.min_pending=3D1 The auto-tuned values are vfs.zfs.vdev.min_pending: 4 vfs.zfs.vdev.max_pending: 10 > If it is not a production-like system which does not accept downtime, =20 > this verification consumes less resources than sending out a developer =20 > hunting for a problem which may not even exist. It wasn't my intention to send anyone hunting. Fabian --Sig_/rAZvbCaHCnRG73fv8zdj+23 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iEYEARECAAYFAk1v6sEACgkQBYqIVf93VJ1ryACgsaHxQhqQqQLB594YBLCtmZlS K/kAn0Cf3I6HqwPrhQJBE/+t+E8H+gz5 =WKq1 -----END PGP SIGNATURE----- --Sig_/rAZvbCaHCnRG73fv8zdj+23--