From owner-freebsd-stable@FreeBSD.ORG Mon Feb 7 14:36:18 2011 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2A18106566C; Mon, 7 Feb 2011 14:36:18 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-gx0-f182.google.com (mail-gx0-f182.google.com [209.85.161.182]) by mx1.freebsd.org (Postfix) with ESMTP id 533A38FC16; Mon, 7 Feb 2011 14:36:17 +0000 (UTC) Received: by gxk8 with SMTP id 8so1800504gxk.13 for ; Mon, 07 Feb 2011 06:36:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:from :date:x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=rmxLzAOtmwo26WcUYyMy8B5BD+SN/mbYkxoyjrU940I=; b=JGu4HVCUzuwIVcY0CCF8W/AsvxgT4qts2jmEb3c7Ymm96GclxvgUqqrBf0E3WU1SRB B03GTJOwI993I51OYfAQIXuHgpGvRm8ULZRwL+qUHfhrUl0FcBRrZbWAXbluy0h6xuMl /WoydmmVfvS/YDRljSXmQbead1tUVi9Aswg2U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=lTMispOnfVAD71Xe4+QozDpg8z0SFrAIyOa4XuJ62GEXZEifRd3scSqNz1/VJo8DzK Dx7HWReGwHTAERgYVD/ujzj8rdf8E2w1uYoqxRMNNFBo8ROgDHTfZsdjpEminNUWn7CP qh54zrHdHqDRzjNsoGxfXzlWTzYqlEvy8XJdw= Received: by 10.90.89.11 with SMTP id m11mr19712995agb.18.1297089377455; Mon, 07 Feb 2011 06:36:17 -0800 (PST) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.151.11.12 with HTTP; Mon, 7 Feb 2011 06:35:37 -0800 (PST) In-Reply-To: <20110207133748.GA16327@tops.skynet.lt> References: <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan> <4D36B85B.8070201@fsn.hu> <20110119150200.GY2518@deviant.kiev.zoral.com.ua> <20110207133748.GA16327@tops.skynet.lt> From: Ivan Voras Date: Mon, 7 Feb 2011 15:35:37 +0100 X-Google-Sender-Auth: YneYLcrX7-KEG3tpy4EENC0bbgQ Message-ID: To: Gleb Kurtsou Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Kostik Belousov , freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 14:36:18 -0000 On 7 February 2011 14:37, Gleb Kurtsou wrote: > It's up to user to mount tmpfs filesystems of reasonable size to prevent > resource exhaustion. Anyway, enormously large tmpfs killing all your > process is not the way to go. Of course not, but as I see it (from admin perspective), tmpfs should behave as close to regular processes in consuming memory as possible (where possible; obviously it cannot be subject to the OOM killer :) ). The problem described in this thread is that there is enough memory in various lists and tmpfs still reports "0 bytes free". See my message: the machine had more than 8 GB of "free" memory (reported by "top") and still "0 bytes free" in tmpfs - and that's not counting inactive and other forms of used memory which could be freed or swapped out (and also not counting swap). By "as close to regular processes in consuming memory" I mean that I would expect tmpfs to allocate from the same total pool of memory as processes and be subject to the same mechanisms of VM, including swap. If that is not possible, I would (again, as an admin) like to extend the tmpfs(5) man page and other documentation with information about what types of memory will and will not count towards available to tmpfs. > Unless there are objections, I'm planning to do the following: > > 1. By default set tmpfs size to max(all swap/2, all memory/2) and print > warning that filesystem size should be specified manually. > Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setu= p. You mean as a reservation, maximum limit or something else? If a tmpfs with "size" of e.g. 16 GB is configured, will the memory be preallocated? wired? I don't think there should be default hard size limits to tmpfs - it should be able to hold sudden bursts of large temp files (using swap if needed), but that could be achieved by configuring a tmpfs whose size is RAM+swap if the memory is not preallocated so not a big problem. > 3. Remove "live" filesystem size checks, i.e. do not depend on > free/inact memory. I'm for it, if it's possible in the light of #1 > 2. Add support for resizing tmpfs on the fly: > =C2=A0 =C2=A0 =C2=A0 =C2=A0mount -u -o size=3D /tmpfs ditto. > Reserving swap for tmpfs might not be what user expects: generally I use > tmpfs for work dir for building ports, it's unused most of the time. It looks like we think the opposite of it :) I would like it to be swapped out if needed, making room for running processes etc. as regular VM paging algorithms decide. Of course, if that could be controlled with a flag we'd both be happy :) > btw, what linux and opensolaris do when available mem/swap gets low due > to tmpfs and how filesystem size determined at real-time? There's some information here: http://en.wikipedia.org/wiki/Tmpfs