From owner-freebsd-stable@FreeBSD.ORG Sat Oct 4 21:15:35 2014 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from hub.FreeBSD.org (hub.freebsd.org [IPv6:2001:1900:2254:206c::16:88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C6667BBB; Sat, 4 Oct 2014 21:15:34 +0000 (UTC) Date: Sat, 4 Oct 2014 17:15:30 -0400 From: Glen Barber To: Konstantin Belousov Subject: Re: Heads-up: Possible regression between 10.0-RELEASE and 10.1-BETA1 with '/ on ZFS' setup Message-ID: <20141004211530.GB1171@hub.FreeBSD.org> References: <20141004024011.GC1199@hub.FreeBSD.org> <20141004160052.GR26076@kib.kiev.ua> <20141004170137.GA1171@hub.FreeBSD.org> <1684676.g0E56GkSvf@overcee.wemm.org> <20141004174600.GU26076@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="jq0ap7NbKX2Kqbes" Content-Disposition: inline In-Reply-To: <20141004174600.GU26076@kib.kiev.ua> X-Operating-System: FreeBSD 11.0-CURRENT amd64 X-SCUD-Definition: Sudden Completely Unexpected Dataloss X-SULE-Definition: Sudden Unexpected Learning Event User-Agent: Mutt/1.5.23 (2014-03-12) Cc: FreeBSD Release Engineering Team , Steven Hartland , freebsd-stable@freebsd.org, Peter Wemm X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 21:15:35 -0000 --jq0ap7NbKX2Kqbes Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Oct 04, 2014 at 08:46:00PM +0300, Konstantin Belousov wrote: > On Sat, Oct 04, 2014 at 10:03:48AM -0700, Peter Wemm wrote: > > > If we cannot increase KSTACK_PAGES by default, do we have any > > > alternative solution outside of suggesting to avoid using ZFS on i386 > > > with more than one disk? > >=20 > > When zfs creates its kthreads it can specify how much stack it needs. = For=20 > > i386 it could ask for more for the zfs threads. Its not a good option = but its=20 > > better than more stack for everything when it's already easy to run out= =20 > > without zfs. >=20 > This one probably happens in the init thread, not some of the zfs hord. > Glen did not show the backtrace from ddb yet (I hope that ddb did not > regressed and can step over double-fault boundary). >=20 > We could specifically increment the init thread stack size as well, but > I have no idea if normal VFS calls into ZFS are affected and cause overfl= ow > for the normal threads after the multitasking is fired. As soon as I get the kernel built with debugging support, I'll be able to get the backtrace. This, however, is proving to be non-trivial. Glen --jq0ap7NbKX2Kqbes Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJUMGNyAAoJEAMUWKVHj+KTJtkP/R8xBLxZaTUQG6tNA5awl6PT ZOj9T/Qmkz9m9dO2FaGu0VbAqyzRBVjsLkIYmfIIw62r0NvWtEgMmKN3hiypLUQy qm1xgaxD0sVbJ2IgSW9S0EpmvKDlLmLPqaGLb0vpx5BiIxtC7OoPwOk3ieA9qGle WLK+sPoRM2wENatXwgyCNqnRzjzxOg1XCYnYyL8h56CtB1egb+a6cqJBbqbsYMv3 uzpMrSyaeC6eOMG1MgsfuV8rJ7m7wi0peEg0i/ndqwxNBI/HNVHVLY30LxZY6mCp BNqp9OCvHAmt/DCVuIrvH16akp3iypmdsX0tH5MORNqtSOPIbVOsz/J6ZOOWuCqb WLnFWTBJqnqzMGRLGkYPAlDVGPd6vsCXPX3gMgpuFHzx4VG+Tekci5NyYYi4+O/j tPBTa703yQ8qRSw8ScI0kOEd1+tIC8kzkKkK5aAFGfUHRQsSGl53/JNuC3P2c2at RhSDY/84OBC82LyZmXXY+Jvq+n+3eDveKOLAeg2Ps6mc2i/ONq2w4Ck0p3G22gnC eYvowd6+Q/CFq/06BA4ms7mrbtB36NgGkgUgmeeWv14hJ79FV1W9XxX2zy0a9tyZ QH8IiileuvzfqXrQ5RV+jvyP8gqyOoxqu//cJcdwM0IMnz8Br2adRCDyMgT4RJSx A9esWjZv7ZduNgJegSLG =P/OQ -----END PGP SIGNATURE----- --jq0ap7NbKX2Kqbes--