From owner-freebsd-fs@FreeBSD.ORG Wed Jan 19 15:02:05 2011 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A85ED1065674; Wed, 19 Jan 2011 15:02:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id 232438FC14; Wed, 19 Jan 2011 15:02:04 +0000 (UTC) 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 p0JF206q096768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 19 Jan 2011 17:02:00 +0200 (EET) (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.4/8.14.4) with ESMTP id p0JF20wt018365; Wed, 19 Jan 2011 17:02:00 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.4/8.14.4/Submit) id p0JF20U8018364; Wed, 19 Jan 2011 17:02:00 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 19 Jan 2011 17:02:00 +0200 From: Kostik Belousov To: Ivan Voras Message-ID: <20110119150200.GY2518@deviant.kiev.zoral.com.ua> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SoGQxgZEULAMOcJz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-3.4 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00, DNS_FROM_OPENWHOIS autolearn=no version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jan 2011 15:02:05 -0000 --SoGQxgZEULAMOcJz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 19, 2011 at 11:39:41AM +0100, Ivan Voras wrote: > On 19/01/2011 11:09, Attila Nagy wrote: > >On 01/19/11 09:46, Jeremy Chadwick wrote: > >>On Wed, Jan 19, 2011 at 09:37:35AM +0100, Attila Nagy wrote: > >>>I first noticed this problem on machines with more memory (32GB > >>>eg.), but now it happens on 4G machines too: > >>>tmpfs 0B 0B 0B > >>>100% /tmp > >>>FreeBSD builder 8.2-PRERELEASE FreeBSD 8.2-PRERELEASE #0: Sat Jan 8 > >>>22:11:54 CET 2011 > >>> > >>>Maybe it's related, that I use zfs on these machines... > >>> > >>>Sometimes it grows and shrinks, but generally there is no space even > >>>for a small file, or a socket to create. > >>http://lists.freebsd.org/pipermail/freebsd-stable/2011-January/060867.h= tml > >> > >> > >Oh crap. :( > > > >I hope somebody can find the time to look into this, it's pretty > >annoying... >=20 > http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch >=20 > I don't think this is a complete solution but it's a start. If you can,= =20 > try it and see if it helps. This is not a start, and actually a step in the wrong direction. Tmpfs is wrong now, but the patch would make the wrongness even bigger. Issue is that the current tmpfs calculation should not depend on the length of the inactive queue or the amount of free pages. This data only measures the pressure on the pagedaemon, and has absolutely no relation to the amount of data that can be put into anonymous objects before the system comes out of swap. vm_lowmem handler is invoked in two situations: - when KVA cannot satisfy the request for the space allocation; - when pagedaemon have to start the scan. None of the situations has any direct correlation with the fact that tmpfs needs to check, that is "Is there enough swap to keep all my future anonymous memory requests ?". Might be, swap reservation numbers can be useful to the tmpfs reporting. Also might be, tmpfs should reserve the swap explicitely on start, instead of making attempts to guess how much can be allocated at random moment. --SoGQxgZEULAMOcJz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk02/OgACgkQC3+MBN1Mb4gbqACcCcdPv4prz3YTuFFXcJdjgXtC xs4AoIpe5GpZ9t49sjimGrOvG382V2of =EWf5 -----END PGP SIGNATURE----- --SoGQxgZEULAMOcJz--