From owner-freebsd-fs@FreeBSD.ORG Sun Jun 16 00:59:45 2013 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id A9276C1C for ; Sun, 16 Jun 2013 00:59:45 +0000 (UTC) (envelope-from beastie@tardisi.com) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by mx1.freebsd.org (Postfix) with ESMTP id 6EFDB1014 for ; Sun, 16 Jun 2013 00:59:45 +0000 (UTC) Received: from ip70-179-144-108.fv.ks.cox.net ([70.179.144.108] helo=zen.lhaven.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Uo0cr-000PnN-3T for freebsd-fs@freebsd.org; Sun, 16 Jun 2013 00:15:21 +0000 Received: from lhaven.homeip.net (localhost [127.0.0.1]) by zen.lhaven.homeip.net (8.14.7/8.14.5) with ESMTP id r5G0FESI034168 for ; Sat, 15 Jun 2013 19:15:14 -0500 (CDT) (envelope-from beastie@tardisi.com) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 70.179.144.108 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19M2bPmYL2XPf9gD4VDaseYirXt7BgLNb4= X-Authentication-Warning: zen.lhaven.homeip.net: Host localhost [127.0.0.1] claimed to be lhaven.homeip.net MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 15 Jun 2013 19:15:09 -0500 From: The BSD Dreamer To: freebsd-fs@freebsd.org Subject: Re: /tmp: change default to mdmfs and/or =?UTF-8?Q?tmpfs=3F?= In-Reply-To: References: Message-ID: <5079bfde7e7154fd266d26c5f0e908c7@lhaven.homeip.net> X-Sender: beastie@tardisi.com User-Agent: Roundcube Webmail/0.8.6 X-Spam-Status: No, score=-2.9 required=4.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on zen.lhaven.homeip.net X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 00:59:45 -0000 On 2013-06-10 03:43, Dmitry Morozovsky wrote: > On Mon, 10 Jun 2013, Julian Elischer wrote: > >> > > > what do you think about stop using precious disk or even SSD resources >> > > > for >> > > > /tmp? >> > > > >> > > > For last several (well, maybe over 10?) years I constantly use md >> > > > (swap-backed) >> > > > for /tmp, usually 128M in size, which is enough for most of our server >> > > > needs. >> > > > Some require more, but none more than 512M. Regarding the options, we >> > > > use >> > > > tmpmfs_flags="-S -n -o async -b 4096 -f 512" >> > > [...] >> >> I sometimes use virtual filesystems but there are cases when I am looking >> to >> store HUGE amounts of trace data in /tmp and end up cursing and remounting >> a >> real disk partition. > > Hmm, don't /var/tmp exist for such a task? Well, providing you make /var/tmp sufficiently and separate from the rest of /var....since filling up /var can be bad. Though it seems to be the trend to have /var be in the same fs as /, but its not the way I do my systems. Since before my return to FreeBSD, I had been doing primarily Solaris. I was used to /tmp being tmpfs, with /var/tmp a real fs. Since there are files that are temporary, but you want them to survive across a reboot (such as vi.recover). So, I've been using tmpfs for /tmp on all my FreeBSD servers. I had also a few years back done something similar to all my Linux servers....before they started discussing whether they should be doing such things....I don't know what they had decided. Though I may get to find out when have to setup a new Linux system at home for something that only has Linux or Windows drivers available for it. On most of my FreeBSD systems, I go with 4GB /tmp tmpfs, though for some reason I went with a 8GB /tmp tmpfs on my home workstation. Though my work workstation also has 4G mdmfs /cache filesystem (which I use by starting chromium with '--disk-cache-dir=/cache', I've also wondered about what would be involved in getting profile-sync-daemon working on FreeBSD, but I never seem to get around to it.) I knew from experience that I should set a size for tmpfs, even on my personal systems. At work, somebody would see all that free space in /tmp and fill it up and then wonder why the system ran out of memory..... But, then I ran into the problem on a home server as well, because there was a boinc project that could copy all of the boinc client directory to /tmp for no good reason at the end of a run. And, when people demanded to know why and to have them stop....and got no acceptable response....we voted with our 'feet'. What we have at work for the people that needed somewhere to store HUGE amounts of trace data....was to eventually give them a large /scratch NFS filesystem (or rather mounted as /scratch, since other groups then wanted their own /scratch for their servers...) since it went from store temporarily to view from another system, and then to use to distribute dumps to other systems... Which was intended to be temporary for the particular situation, but hasn't gone away (had to be migrated to new NAS when old NAS was decommissioned -- delete and recreate wasn't acceptable) now appears on more and more systems, and has gotten bigger.... -- Name: Lawrence "The Dreamer" Chen Call: W0LKC Snail: 1530 College Ave, A5 Email: beastie@tardisi.com Manhattan, KS 66502-2768 Blog: http://lawrencechen.net