Date: Fri, 1 Jul 2011 21:15:30 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@spoerlein.net> To: "Sean M. Collins" <sean@coreitpro.com> Cc: freebsd-current@freebsd.org Subject: Re: Thoughts on TMPFS no longer being considered "highly experimental" Message-ID: <20110701191530.GA76888@acme.spoerlein.net> In-Reply-To: <4E0DE8D6.3090806@coreitpro.com> 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> <4E0DE8D6.3090806@coreitpro.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 01.07.2011 at 11:33:42 -0400, Sean M. Collins wrote: > 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. You just cannot use them both, yet. On amd64 with 8GB of RAM and a ZFS volume that is a couple of hundred G (and world-readable) - Run with tmpfs /tmp - Wait overnight for /etc/periodic/weekly/310.locate to kick in - Come back next morning and have 0 bytes free in /tmp Exporting the pool might bring the memory back, but with open files on the pool and of course in /tmp (think Xorg ...) this is impractical. Uli
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110701191530.GA76888>