From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 19:33:39 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 95F6CDD3; Wed, 20 Mar 2013 19:33:39 +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 3754EFBA; Wed, 20 Mar 2013 19:33:39 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r2KJXZJE077667; Wed, 20 Mar 2013 21:33:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KJXZJE077667 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KJXZSX077666; Wed, 20 Mar 2013 21:33:35 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 20 Mar 2013 21:33:35 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320193335.GK3794@kib.kiev.ua> References: <5148A454.1080303@FreeBSD.org> <424B99CB-A6D3-4219-A21E-62E5FB778E82@FreeBSD.org> <20130320132222.GC3794@kib.kiev.ua> <201303200943.20356.jhb@freebsd.org> <20130320185808.GJ3794@kib.kiev.ua> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4K1DhCUNwbLbQ12L" Content-Disposition: inline In-Reply-To: <20130320185808.GJ3794@kib.kiev.ua> 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: Jeremy Chadwick , Michael Landin Hostbaek , Rick Macklem , freebsd-stable@freebsd.org, Andriy Gapon X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2013 19:33:39 -0000 --4K1DhCUNwbLbQ12L Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 20, 2013 at 08:58:08PM +0200, Konstantin Belousov wrote: > On Wed, Mar 20, 2013 at 09:43:20AM -0400, John Baldwin wrote: > > On Wednesday, March 20, 2013 9:22:22 am Konstantin Belousov wrote: > > > On Wed, Mar 20, 2013 at 12:13:05PM +0100, Michael Landin Hostbaek wro= te: > > > >=20 > > > > On Mar 20, 2013, at 10:49 AM, Konstantin Belousov =20 > > wrote: > > > > >=20 > > > > > I do not like it. As I said in the previous response to Andrey, > > > > > I think that moving the vnode_pager_setsize() after the unlock is > > > > > better, since it reduces races with other thread seeing half-done > > > > > attribute update or making attribute change simultaneously. > > > >=20 > > > > OK - so should I wait for another patch - or?=20 > > >=20 > > > I think the following is what I mean. As an additional note, why nfs > > > client does not trim the buffers when server reported node size chang= e ? > >=20 > > Will changing the size always result in an mtime change forcing the cli= ent to > > throw away the data on the next read or fault anyway (or does it only a= ffect > > ctime)? >=20 > UFS only modifies ctime on truncation, it seems. No, I was wrong. ffs_truncate() indeed only sets both IN_CHANGE | IN_UPDATE flags for the inode, and IN_UPDATE causes mtime update in ufs_itimes(), called from UFS_UPDATE(). --4K1DhCUNwbLbQ12L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSg8OAAoJEJDCuSvBvK1BBiUP+wWERkRa1csAo+2rUrItibqV ephUWDg5To2Jc0vPh8keZNUZrSmAQp47YSL9nUPV3LjGTYVR4Bfty2Uw78P6bcwO +BtgxBRcFZ6T9ix4tto3ptuptx1Vjq+issOXLRMlTJMqcTCFLqoWDOxPQhD+IwIJ WNb8gIFehtEsOv5FdBnYLwPtIya5ExNFnKOD9+I+jDJNhUlpKHN/6OUDZnQBI9/o /MeEVOQgBEGpceH+KgUStSPsCEKyzlMCV8EDwy866mFkZQUq752coKp7oGKpz/LF c3iVzwh5M3sXuFbt6ZW+wilAqdbhz+JS0ZHJnUGd1Fsy0TsI8eGJBEG3zbly82pr +SlUjViPcsVeVScyll05Sry4wlI4ZJzq3qtBkmyjoeAqpWMemLKDXEXYpXpn3ro+ THzsvKtUJC4MA74ukZMOjKiwBPbCWmcHOAftnwsO1by+hFr2k5gFUZD9SMU/+m1p On0FN5DDV+owWZVCS3XzBGVXi8Kx863L42t7GLvlsJf3eAzZzVk/AIjpoj7PFJs5 BHShhPyapUNKkVJHWCopPm9pA/OUEOUgYab+dpWGJlz3m6KOv7zu0GT36uxDNzj3 ytu+ucrKrZvK2U3vn9FfiA1AGr7YNOLrfNXtxsBXGwauH3r7tF0x0XMZQv7LNTsK YAgrEGQ7OPPq2BOqqdR4 =5MTz -----END PGP SIGNATURE----- --4K1DhCUNwbLbQ12L--