Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 15 Jun 2013 19:15:09 -0500
From:      The BSD Dreamer <beastie@tardisi.com>
To:        freebsd-fs@freebsd.org
Subject:   Re: /tmp: change default to mdmfs and/or =?UTF-8?Q?tmpfs=3F?=
Message-ID:  <5079bfde7e7154fd266d26c5f0e908c7@lhaven.homeip.net>
In-Reply-To: <alpine.BSF.2.00.1306101242500.48048@woozle.rinet.ru>
References:  <alpine.BSF.2.00.1306101242500.48048@woozle.rinet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5079bfde7e7154fd266d26c5f0e908c7>