[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Moving /tmp to tmpfs is fine



On Sat, May 26, 2012 at 06:59:35PM +0100, Wookey wrote:
> I hesitate to prolong this thread further, but I do have a couple of
> data points. (and couldn't let Neil's nonsense go).
> 
> +++ Neil Williams [2012-05-25 16:15 +0100]:
> > > So instead of fixing the defaults you suggest everybody to drop the
> > > programs they use (mc, firefox, mysql)? ;)
> > 
> > On machines which don't have the resources for those programs, yes.
> > There are alternatives out there - change to a less hungry program or
> > expand the hardware.
> 
> The idea that there are machines without the resources for mc is
> silly. It's a very low-resource console-based program.
> 
> But there is this issue of the way its vfs does temporay unpacking in
> /tmp. That makes sense in the 'this is temporary, it should go away on
> reboot' sense, but some big files will use up a lot of ram when /tmp
> is tmpfs. 
> 
> I don't know what the right thing to do about this is, but the 'set
> TMPDIR' sugestion is useless IMHO. When I start mc I have no idea what
> things will be unpacked under the VFS over the next days/weeks. I
> don't want _everything_ to go in /var/tmp and not get cleaned up
> automatically (is there cron job that does this for old files?)
> 
> Perhaps mc should get clever and change TMPDIR itself on the fly for
> large files, but I don't know how practical that is. 

Or, it should get clever and not unpack everything. There are plenty of
software that are able to read into archives without extracting from
them. There are even fuse filesystems to do that if it doesn't want to
do it itself. Using a temporary directory, be it on disk or in RAM, is
*always* going to be a limitation. As a matter of fact, i remember some
virtualization solution (vserver or lxc, i think) that gave me a 16MB /tmp
by default. It doesn't matter if it's on disk or in RAM at this point.
If mc is going to try to unpack a kernel archive in there, it's going to
blatantly fail. Yet, there's no excuse for it to not do better.

Mike


Reply to: