From owner-freebsd-fs@FreeBSD.ORG Mon Feb 7 13:38:09 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 103111065670; Mon, 7 Feb 2011 13:38:09 +0000 (UTC) (envelope-from gleb.kurtsou@gmail.com) Received: from mail-ey0-f182.google.com (mail-ey0-f182.google.com [209.85.215.182]) by mx1.freebsd.org (Postfix) with ESMTP id 41C608FC2B; Mon, 7 Feb 2011 13:38:07 +0000 (UTC) Received: by eyf6 with SMTP id 6so2187805eyf.13 for ; Mon, 07 Feb 2011 05:38:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=Gr/xYSgbW5jls1s50a5kLAtrAEN2TY0rnCdFU32OorI=; b=fm6oQ7z4s69GZLqToD9G0BqhqLI87UAMPliG6RIwb/Ho/vOxtZwfqhKx5TInSyvUDd 5pIscrNs79NayEDx+SA7Mr2J3sWC7uLkeis2f1odWASeRgCgSF91pSEiYRuQZY8/FpSK PRIPjVxEcx0zrr6owzrDBparnm8UP7qx0Cyok= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; b=AVmSTS8w8DAj3wbrvtsQ0UR+nvxvFIUkshpJR7EKgNuQc+agzYT5PYEz3U/2EwFoXt GqwQNrShad4mBzzKXBkOl/4QVZCHCrCKE811uoYdqP7GGvydDnG4VmNz9JZZ/h4pmZ4e Iwbxes8zfO0ZbZvm17VM+bqiezFCHT5YNbgL4= Received: by 10.103.233.16 with SMTP id k16mr10857347mur.132.1297085887121; Mon, 07 Feb 2011 05:38:07 -0800 (PST) Received: from localhost (lan-78-157-92-5.vln.skynet.lt [78.157.92.5]) by mx.google.com with ESMTPS id a6sm819372fak.3.2011.02.07.05.38.05 (version=SSLv3 cipher=OTHER); Mon, 07 Feb 2011 05:38:06 -0800 (PST) Date: Mon, 7 Feb 2011 15:37:48 +0200 From: Gleb Kurtsou To: Ivan Voras Message-ID: <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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) 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: Mon, 07 Feb 2011 13:38:09 -0000 On (19/01/2011 17:27), Ivan Voras wrote: > On 19 January 2011 16:02, Kostik Belousov wrote: > > >> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch > >> > >> I don't think this is a complete solution but it's a start. If you can, > >> 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. > > Thank you for your explanation! I'm still not very familiar with VM > and VFS. Could you also read my report at > http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html > ? I'm curious about the fact that there is lots of 'free' memory here > in the same situation. > > Do you think that there is something which can be done as a band-aid > without a major modification to tmpfs? 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. 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 setup. 3. Remove "live" filesystem size checks, i.e. do not depend on free/inact memory. 2. Add support for resizing tmpfs on the fly: mount -u -o size= /tmpfs 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. btw, what linux and opensolaris do when available mem/swap gets low due to tmpfs and how filesystem size determined at real-time? Thanks, Gleb.