From owner-freebsd-stable@FreeBSD.ORG Wed Mar 20 18:58:16 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 37D4C605; Wed, 20 Mar 2013 18:58:16 +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 BB3AFE3A; Wed, 20 Mar 2013 18:58:15 +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 r2KIw8KU071488; Wed, 20 Mar 2013 20:58:08 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.8.0 kib.kiev.ua r2KIw8KU071488 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r2KIw8Wk071487; Wed, 20 Mar 2013 20:58:08 +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 20:58:08 +0200 From: Konstantin Belousov To: John Baldwin Subject: Re: Core Dump / panic sleeping thread Message-ID: <20130320185808.GJ3794@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> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZZEGMFFBHS0xR+g5" Content-Disposition: inline In-Reply-To: <201303200943.20356.jhb@freebsd.org> 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 18:58:16 -0000 --ZZEGMFFBHS0xR+g5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 wrote: > > >=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 change ? >=20 > Will changing the size always result in an mtime change forcing the clien= t to > throw away the data on the next read or fault anyway (or does it only aff= ect > ctime)? UFS only modifies ctime on truncation, it seems. --ZZEGMFFBHS0xR+g5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJRSga/AAoJEJDCuSvBvK1BfAYP/1EgLiteMNeP9kXLF2tMgTju suAOy0hYjAYl4leyyYS4l93n7Z2prDo8Ml+OrnJkTC52VdDwgag4z1+QuXK2a6SK crbxb6It+7kILt+WG12ydX8p28DI0zx2RR+lf6B3OP3Dk5eYww62sBGZ9fIqr3zz ELZozO2ehVoSSIGlxmcznoWudtQTKZ/PYDV6vvDS0sQ9/5DcqXupAoAlwFYxDGRB CSlg9B45Bm/MEc/MK2+KE1ut4nBRjteXjB5snKlKv0e630ycNKQovby1rJXQGLGh CKKSHG6TuOtI8MFSl7+8Wvzw2vVVtps2bzMJgspsDpO0rtLJEolcLqXR+aVPfCxv 2wvxG0v67bqvLOSGRKBC9TE+Lddh9oBHPRIqFwYX5lmQh8i6JBPT74H4BlNMRRAb gKCdh6RHiYohFGKe+v/ZK+GSq7ptbjqQu/jmG6Po2hFY/QO8p4q3RNolkGwXKOVf qmb58Uzt/4J8wAd3vPej0F6RNflw0/d2CJ1nGYx+ZSnNJ0TnmJTCsI3jiJ7GOug6 uyFB6CmJp6XPubBT1+9qLrVWw8v6irBnZKcDzl/800LQEChWwbhcHnM+6dDjStiB ueBkNOsvc4RL7jNeRTa3uIT13QiBELyIpA3Fn26PldHWtCPcbpvDqTukVq5ExCji wAZpvjsinWbW4eroNlVg =cpXk -----END PGP SIGNATURE----- --ZZEGMFFBHS0xR+g5--