bug-findutils
[Top][All Lists]
Advanced

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

Re: [bug #13774] Why is updatedb prefering /var/tmp over /tmp for tempor


From: Bob Proulx
Subject: Re: [bug #13774] Why is updatedb prefering /var/tmp over /tmp for temporary files?
Date: Tue, 12 Jul 2005 14:14:17 -0600
User-agent: Mutt/1.5.9i

> This was originally reported by Arthur Korn in http://bugs.debian.org/317815
> 
> updatedb by default uses /var/tmp for temporary files.
> 
> | We had a problem today on one system where /var would be full every
> | night. We figured out that /var/tmp/ was full with hundreds of megabytes
> | of files with names like 'sortXb87kd'. Some inspection led me to |
> assumption that those are buffer files from sort, which it places |
> in TMPDIR, which is set to /var/tmp/ here:
> 
> Afaict from reading FHS /var/tmp should only be used instead of /tmp if the
> temporary files must not be deleted on reboot. I fail to see how this applies
> to updatedb.

I can't speak as to findutils's original use of /var/tmp but in the
old days when disks were small and filesystems limited in size the
/tmp and /usr/tmp directories would frequently be on different disks.
Frequently the /usr disk was larger than the / disk.  So /tmp was
limited in size for usable files and /usr/tmp available for possibly
much larger files.  It was typical for applications that used large
disk space for temporary files to use /usr/tmp for that purpose so
that they would not be limited by the sometimes quite small /tmp
filesystem.

> | Since those are absolutely temporary files, and can grow quite large on
> | systems with many files, I suggest to prefer /tmp over /var/tmp or to
> | reset TMPDIR to /tmp when calling sort.

Since those files may be quite large it is probably necessary on many
systems to use /var/tmp over /tmp or they won't fit.

This is probably something that should be a system configurable
parameter.  Probably something in /etc/default/findutils with the
default remaining /var/tmp.

> | Overflowing /var is bad enough, but when it happens like this it can be
> | pretty hard to track down and will lead to bizarre malfunctions.

The statement that it would lead to bizarre malfunctions confuses me
because the entire purpose of having a separate a filesystem is to
avoid breaking other parts of the system when a particular filesystem
fills up.  By putting /var on a separate filesystem if something fills
it up it should not bring down the other use of the machine.

On server configurations /var is frequently on a separate filesystem
specifically to contain the disk space growth of it.  Of course some
people do not like hard partitioned filesystems.  One is always free
to create the entire system as one partition in that case.

Bob




reply via email to

[Prev in Thread] Current Thread [Next in Thread]