From owner-freebsd-fs@FreeBSD.ORG Mon Oct 3 14:58:06 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 81D6E1065672 for ; Mon, 3 Oct 2011 14:58:06 +0000 (UTC) (envelope-from artemb@gmail.com) Received: from mail-yw0-f54.google.com (mail-yw0-f54.google.com [209.85.213.54]) by mx1.freebsd.org (Postfix) with ESMTP id 15F3E8FC08 for ; Mon, 3 Oct 2011 14:58:05 +0000 (UTC) Received: by ywp17 with SMTP id 17so4426729ywp.13 for ; Mon, 03 Oct 2011 07:58:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=A8yW7Qu12/qi+p0wf+m1Bvv3yiVosdtw1zfVVWKinWI=; b=myIXKwO7N9jvSIBarWrZ0R4RUMnDy3DMcTatcWNAqy+/efbNE7dgEFfeC/v9LX5+Hx k2Vl7ut4JW4v8cLrbdnNHe41k+oU853Jemrp/+GOf9aTELFcA9JpfpdgApjAvJY3eM/Q SQtiZu87vWadL+kis1qj44ISiP8gG/lLOkcio= MIME-Version: 1.0 Received: by 10.236.184.198 with SMTP id s46mr300505yhm.23.1317653885260; Mon, 03 Oct 2011 07:58:05 -0700 (PDT) Sender: artemb@gmail.com Received: by 10.236.102.147 with HTTP; Mon, 3 Oct 2011 07:58:04 -0700 (PDT) In-Reply-To: <4E899C8E.7040305@fsn.hu> References: <20111002020231.GA70864@icarus.home.lan> <4E899C8E.7040305@fsn.hu> Date: Mon, 3 Oct 2011 07:58:04 -0700 X-Google-Sender-Auth: ps670i5IGhsLfiZv1udT2enTwv0 Message-ID: From: Artem Belevich To: Attila Nagy Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-fs@freebsd.org, Adrian Chadd , delphij@freebsd.org 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 14:58:06 -0000 > 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 > =A0 root@buildervm:/data/usr/obj/data/usr/src/sys/BOOTCLNT =A0amd64 > $ df -h /tmp > Filesystem =A0 =A0Size =A0 =A0Used =A0 Avail Capacity =A0Mounted on > tmpfs =A0 =A0 =A0 =A0 =A0 0B =A0 =A0 =A00B =A0 =A0 =A00B =A0 100% =A0 =A0= /tmp > > I have no swap configured. The machine has 64 GB RAM. > vm.kmem_size=3D60G; vfs.zfs.arc_max=3D55G; vfs.zfs.arc_min=3D20G I'm curious -- does your ARC size ever reaches configured limit of 55G? My hunch that it's probably hovering around some noticeably lower number. On my ZFS setups a lot of memory seems to be lost due to fragmentation. On a system with 24G of RAM and rac_max=3D16G, I typically see more than 20G of memory wired. With kmem_size=3D60G, ARC is likely to use up most of available kmem space and that's probably what affects tmpfs. Besides, with kmem_size that close to arc_max you may be risking meeting "kmem too small" panic, though, considering that your kmem_size is rather large chances of that are smaller than on a system with smaller amounts of memory and kmem_size. I'd start with doubling kmem_size and, possibly, reducing arc_max to the point where it stops putting pressure on tmpfs. --Artem