From owner-freebsd-current@FreeBSD.ORG Sun Jun 15 18:20:19 2008 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5DFA91065670; Sun, 15 Jun 2008 18:20:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (skuns.zoral.com.ua [91.193.166.194]) by mx1.freebsd.org (Postfix) with ESMTP id D21588FC1A; Sun, 15 Jun 2008 18:20:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m5FIOmm5062385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 21:24:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2) with ESMTP id m5FIKDBT029566; Sun, 15 Jun 2008 21:20:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.2/8.14.2/Submit) id m5FIKDoV029559; Sun, 15 Jun 2008 21:20:13 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 15 Jun 2008 21:20:12 +0300 From: Kostik Belousov To: Dmitry Morozovsky Message-ID: <20080615182012.GH94309@deviant.kiev.zoral.com.ua> References: <20080615130037.J43777@woozle.rinet.ru> <20080615101918.GA94309@deviant.kiev.zoral.com.ua> <20080615161718.R43777@woozle.rinet.ru> <20080615122331.GE94309@deviant.kiev.zoral.com.ua> <20080615163209.Y43777@woozle.rinet.ru> <20080615211951.W75021@woozle.rinet.ru> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Jr7V/D3tXZ2+JpAg" Content-Disposition: inline In-Reply-To: <20080615211951.W75021@woozle.rinet.ru> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: ClamAV version 0.91.2, clamav-milter version 0.91.2 on skuns.kiev.zoral.com.ua X-Virus-Status: Clean Cc: delphij@freebsd.org, current@freebsd.org Subject: Re: tmpfs panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 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: Sun, 15 Jun 2008 18:20:19 -0000 --Jr7V/D3tXZ2+JpAg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jun 15, 2008 at 09:25:53PM +0400, Dmitry Morozovsky wrote: > On Sun, 15 Jun 2008, Dmitry Morozovsky wrote: >=20 > DM> KB> > KB> I suspect this may be my mistake. > DM> KB> > KB> IN case you can reproduce it, please, try the patch below. > DM> KB> >=20 > DM> KB> > Well, it seems hard to reproduce, possibly some races in kernel= memory=20 > DM> KB> > allocation exist. Keep trying (run rsync -aH svn tree to tmpfs = in the loop) > DM> KB>=20 > DM> KB> Unmount is required to trigger the problem. Please, report to me = whatever > DM> KB> your results are. I will commit the patch then. > DM>=20 > DM> yes, the loop contains rsync, umount, mount. I'll let this run for se= veral=20 > DM> hours, then report back to you. >=20 > With about 80 turns without a panic I think it was great coincidence that= I'd=20 > encountered this panic. ;-) Thank you for testing. >=20 > BTW, side result: 128M for kern.maxswzone is enough for filling tmpfs > to 100% under amd64 with 4G RAM + 8G swap. > > Also, I can observe tmpfs is doing non-optimal; I did not found > straight ways to set block/frag size; I suppose for most tmpfs usage > they should be decreases to the lowest values, such as 4k/512 -- what > do you think? Block and fragment size concepts are not applicable to the tmpfs; basically, this is the point for having such fs in the system. Each file on the tmpfs is presented as the swap-backed vm object. Besides the set of the (mostly) known problems with correctness and stability, current implementation has quite unefficient implementation of the mmap and buffer cache interaction. The vm object (and pages) used for the vm operations are copied from the backing vm object instead of being reused. This means that we get essentially twice as much memory used, and copying. --Jr7V/D3tXZ2+JpAg Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) iEYEARECAAYFAkhVXVwACgkQC3+MBN1Mb4jSDACfVZ8b/zgJ7+Q+b/E2a/9cJTRD yi4An3sUlxiuFBRb5Iq5E2RZjVituBr5 =vzrN -----END PGP SIGNATURE----- --Jr7V/D3tXZ2+JpAg--