From owner-freebsd-fs@FreeBSD.ORG Mon Oct 3 19:10:47 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 E7F1D106564A; Mon, 3 Oct 2011 19:10:46 +0000 (UTC) (envelope-from bra@fsn.hu) Received: from people.fsn.hu (people.fsn.hu [195.228.252.137]) by mx1.freebsd.org (Postfix) with ESMTP id 195958FC16; Mon, 3 Oct 2011 19:10:45 +0000 (UTC) Received: by people.fsn.hu (Postfix, from userid 1001) id 9E763A8E288; Mon, 3 Oct 2011 21:10:44 +0200 (CEST) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.2 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MF-ACE0E1EA [pR: 20.9654] X-CRM114-CacheID: sfid-20111003_21104_C19F9C6D X-CRM114-Status: Good ( pR: 20.9654 ) X-DSPAM-Result: Whitelisted X-DSPAM-Processed: Mon Oct 3 21:10:44 2011 X-DSPAM-Confidence: 0.9969 X-DSPAM-Probability: 0.0000 X-DSPAM-Signature: 4e8a08b4761682717815091 X-DSPAM-Factors: 27, From*Attila Nagy , 0.00010, FreeBSD, 0.00054, FreeBSD, 0.00054, >+I, 0.00087, >+On, 0.00099, to+>, 0.00171, wrote+>, 0.00179, bug, 0.00198, of+>, 0.00236, cache, 0.00256, cache, 0.00256, wrote+>>, 0.00267, it+>, 0.00279, )+>, 0.00279, >+>, 0.00288, >+>, 0.00288, References*mail.gmail.com>, 0.00295, References*mail.gmail.com>, 0.00295, root, 0.00454, wrote, 0.00495, wrote, 0.00495, it+does, 0.00510, STABLE, 0.00556, STABLE, 0.00556, /tmp, 0.00612, /tmp, 0.00612, X-Spambayes-Classification: ham; 0.00 Received: from [192.168.3.2] (japan.t-online.co.hu [195.228.243.99]) by people.fsn.hu (Postfix) with ESMTPSA id 011CAA8E26A; Mon, 3 Oct 2011 21:10:42 +0200 (CEST) Message-ID: <4E8A08B2.1010403@fsn.hu> Date: Mon, 03 Oct 2011 21:10:42 +0200 From: Attila Nagy User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.23) Gecko/20090817 Thunderbird/2.0.0.23 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: d@delphij.net References: <20111002020231.GA70864@icarus.home.lan> <4E899C8E.7040305@fsn.hu> <4E89ED58.6020104@delphij.net> <4E8A00BF.5000508@fsn.hu> <4E8A0232.1020005@delphij.net> In-Reply-To: <4E8A0232.1020005@delphij.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Adrian Chadd , freebsd-fs@freebsd.org, delphij@freebsd.org, Xin LI Subject: Re: is TMPFS still highly experimental? 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, 03 Oct 2011 19:10:47 -0000 On 10/03/2011 08:42 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 10/03/11 11:36, Attila Nagy wrote: >> On 10/03/2011 07:14 PM, Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Hi, Attila, >>> >>> On 10/03/11 04:29, Attila Nagy wrote: >>>> For me, the bug is still here: $ uname -a FreeBSD b 8.2-STABLE >>>> FreeBSD 8.2-STABLE #5: Wed Sep 14 15:01:25 CEST 2011 >>>> root@buildervm:/data/usr/obj/data/usr/src/sys/BOOTCLNT amd64 $ >>>> df -h /tmp Filesystem Size Used Avail Capacity Mounted >>>> on tmpfs 0B 0B 0B 100% /tmp >>>> >>>> I have no swap configured. The machine has 64 GB RAM. >>>> vm.kmem_size=60G; vfs.zfs.arc_max=55G; vfs.zfs.arc_min=20G >>> This sounds like a configuration issue. Running without swap is >>> not recommended anyways. >> I guess it depends on the workload. In general, you are possibly >> right, but if you need predictable response times and you can >> tolerate dying processes, swapping may not be the right thing to >> do. > Well, in that case one will have to tolerate tmpfs have no page to > allocate (note that it does need to reserve some pages for system use) > at this point. Currently it's working like a credit line -- use it > here and you can't use it elsewhere, e.g. if user process used it then > tmpfs can't use it... Sure, but we are talking here about ARC, which is a cache. I guess tmpfs work quite OK with UFS, where it will shrink its cache space. BTW, I don't care if tmpfs shows 2 GB free space when there is (>)2 GB, but currently I have: Mem: 564M Active, 3091M Inact, 55G Wired, 129M Cache, 71M Buf, 2957M Free and: Filesystem Size Used Avail Capacity Mounted on tmpfs 0B 0B 0B 100% /tmp That's the first problem. (the second could be to shrink ARC from tmpfs-land if needed) > I think the only solution we can have here is to teach tmpfs about > "dedicated reserve for tmpfs" so it pre-allocate a few pages that can > not be reused elsewhere? E.g. create a budget that make this part of > memory "tmpfs fund" :) > > There is md for that. Sure, it's harder, and using UFS (or any other FS) on md seems to be a waste of resources. For me it would be quite enough if tmpfs wouldn't loose all its space when there is free memory.