From owner-freebsd-current@FreeBSD.ORG Sat Jul 13 10:03:44 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 4DBD1FAA; Sat, 13 Jul 2013 10:03:44 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id B6B4F1951; Sat, 13 Jul 2013 10:03:43 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.7/8.14.7) with ESMTP id r6DA3ccd026051; Sat, 13 Jul 2013 13:03:38 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.3 kib.kiev.ua r6DA3ccd026051 Received: (from kostik@localhost) by tom.home (8.14.7/8.14.7/Submit) id r6DA3b9G026050; Sat, 13 Jul 2013 13:03:37 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 13 Jul 2013 13:03:37 +0300 From: Konstantin Belousov To: Ian FREISLICH Subject: Re: Filesystem wedges caused by r251446 Message-ID: <20130713100337.GK91021@kib.kiev.ua> References: <20130713054220.GJ91021@kib.kiev.ua> <20130712201051.GI91021@kib.kiev.ua> <201307110923.06548.jhb@freebsd.org> <201307091202.24493.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="IiQkvLGLJxajv8+M" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: freebsd-current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 10:03:44 -0000 --IiQkvLGLJxajv8+M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jul 13, 2013 at 10:14:06AM +0200, Ian FREISLICH wrote: > Konstantin Belousov wrote: > > On Fri, Jul 12, 2013 at 11:34:18PM +0200, Ian FREISLICH wrote: > > > (kgdb) print runningbufreq > > > $1 =3D 1 > > > (kgdb) print runningbufspace > > > $2 =3D 0 > > > (kgdb) print lorunningspace > > > $3 =3D 4587520 > > > (kgdb) print hirunningspace > > > $4 =3D 4194304 > >=20 > > This is extremely weird. The hirunningspace is less then lorunningspac= e, > > am I right ? This causes the runningbufspace machinery to never wake up >=20 > Yes. This state of affairs doesn't happen on r251445 and further > testing on my side shows it doesn't hapen on all my amd64 servers. > It appears that this particular server type (Dell R200) running > amd64 with geom_mirror is affected. I will have to test further > by destroying the mirror and removing it from the kernel and see > if I can still reproduce the issue. Perhaps r251446 exposes > insufficient locking on opperations affecting these variables. No. The lorunningspace is constant for the system lifetime. It can only be changed by the sysctl vfs.lorunningspace. Look into /etc/sysctl.conf or scripts which apply sysctl settings. Boot the system single-user and show the sysctl vfs.lorunningspace sysctl vfs.hirunningspace Compare the values from single user with the values after the system booted normal. >=20 > > I just verified on the 4G VM on amd64, my numbers for lo is 4587520, > > for high 6881280. Verify your tuning and kernel options, which you sho= uld > > have provided with the original report, I think. >=20 > Sorry about that (and I'm relieved:) I had originally compiled with > CPUTYPE?=3Dopteron which is incorrect for this CPU. However the > problem persists with CPUTYPE?=3Dcore2, but I'm not sure how much of > a difference this makes with clang. Also, I have another affected > host that's compiled with gcc and the correct CPUTYPE so I doubt > it's the compiler. >=20 This is irrelevant, CPU type cannot affect the calculation, unless the compiler is horribly broken. --IiQkvLGLJxajv8+M Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQIcBAEBAgAGBQJR4SX5AAoJEJDCuSvBvK1BqYsP+gMJ/db3BzdxhYpPZlP3CmgX xUz+cCtjTF0bLW6GgSV0Yd2aK4yHlanr38LmBAHUVuNXq5Mr9vvxhvebqCzyxrFq ar3JiR3v6rMu0J6I0shIqGSrRJeY7ZsHPn/Tb1hGLzaqtdXzFxs5fS4QGhBjnaMZ Mbg1zjNZjonSVkimFIhFSijklmRXfxIuihOi8bzpMmKWNW2ruYWb2kE9vHd7teEM AaSLhfaqTnlpXyyR/yEpZPigyE/ksUrzHOHvUDu1pMdXqcxZYEeg9KXJSJz/ro8R 6rFvImmT8MGBv43arbup5AGJ12RGc0INkKXj1KGQrLpM/mVrpYPAkLHhtv0miIxp Eymg/cUH13NYm9Et6pG7SQibE7leebmWYr6EIj63unM+H/wx2QVVJoUGJZHmUppF j16KlhqL1A9xWHoUIMQH5hWtkst5luFX+0ItyJesVKMDn60ck81cyGyqt5xiI9yI Xaw5zSK9RNC1Z4hXaTYmwkU7AvprX0s/hl9fuFW930TQYnYXP5/3PmkZyIgLAD8k tUcNV81+Du3nXMarDx+7196gQiFP9Ynz8SyoLU7aDRdmf0XgeZFizzy9TEB0BEe9 NXvaJ/m6wUWua/a1tGq3vD/3kF5y8w9EgA2ZNXkHNIV2gUZsYYYtKXNC6B/6OWu9 QO48a4CuxkzgK7sL2bon =xVOK -----END PGP SIGNATURE----- --IiQkvLGLJxajv8+M--