From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 15:33:46 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E454C1065673 for ; Fri, 1 Jul 2011 15:33:46 +0000 (UTC) (envelope-from sean@coreitpro.com) Received: from masakari.coreitpro.com (masakari.coreitpro.com [38.98.245.188]) by mx1.freebsd.org (Postfix) with ESMTP id A76358FC08 for ; Fri, 1 Jul 2011 15:33:46 +0000 (UTC) Received: from Uller.local (static-74-109-127-34.phlapa.fios.verizon.net [74.109.127.34]) (authenticated bits=0) by masakari.coreitpro.com (8.14.4/8.14.4) with ESMTP id p61FXj3n063009 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Fri, 1 Jul 2011 11:33:46 -0400 (EDT) (envelope-from sean@coreitpro.com) Message-ID: <4E0DE8D6.3090806@coreitpro.com> Date: Fri, 01 Jul 2011 11:33:42 -0400 From: "Sean M. Collins" Organization: Core IT Pro User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20110623163109.GA508@dragon.NUXI.org> <4E0B8CBC.8080601@gmail.com> <4E0CA5D4.4010002@coreitpro.com> <4E0D54AA.7000808@coreitpro.com> <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> In-Reply-To: <1A9CA8A0-F477-4A6A-9363-8A357DAB7441@lassitu.de> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" 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: Fri, 01 Jul 2011 15:33:47 -0000 On 7/1/11 2:42 AM, Stefan Bethke wrote: > The box shouldn't wedge in this situation. If tmpfs can create > a memory starvation situation on the kernel level, it is not production ready. The full message was "swap zone exhausted, increase kern.maxswzone" - I guess that actual swap wasn't exhausted, but just space for metadata. So in tmpfs' defense, AMD64 boots with a kern.maxswzone of 32MB like i386, which only allows ~7 GB of swap to be allocated. I'll see if I can get the machine to wedge again, then increase kern.maxswzone, and repeat. -- Sean Collins Core IT Pro, LLC www.coreitpro.com