lkml.org 
[lkml]   [1998]   [May]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: /tmp in swap space
On Fri, 22 May 1998, Jim Wilcoxson wrote:

> Disk space is dirt cheap and getting cheaper all the time. Plus, there
> could be a reliability concern here. If a program goes wild and fills /tmp
> (which just happened to me last week btw), I wouldn't want my machine to
> crash because it couldn't swap.

That's exactly why I asked the question about using the ulimit settings as
disk quota for the filesystem. That way, a process limited to a certain
amount of RAM is equally limited to trashing in /tmp.

Just as we need a way to control /tmp usage now, it would still be
necessary to control usage for the combined /tmp and swap. Ideal would be
a filesystem that is optimized for temporary storage and that takes ulimit
settings into account.

Currently, processes get an 'out of memory' or 'out of disc space' when
swap or /tmp is full. It may be possible to design a set of rules for
killing and suspending processes when /tmp or swap runs out. With these
rules, it may be possible, in case of /tmp or swap filling or trashing, to
find and kill just the process that is trashing (-hmm, wouldn't that be
possible just for swap in the current kernel?-).

Currently, if one program fills /tmp and/or swap, then other programs that
try to use additional /tmp and/or swap fail (exit, get killed,etc.). I
dont think it is impossible to counteract some trashing of /tmp. For
example, in addition to limiting the amount of space per process, if a
process creates files in /tmp, and then does not exit normally (gets
killed as a result of an error (segmentation fault)), its files in /tmp
could be removed automatically. This may even be controllable by the
program itself, telling the kernel which return values from 'exit(n)' mean
that the temporary files should or should not be kept, or telling the
kernel the maximum lifetime of its /tmp files (with lifetime in
hh:mm:ss, but maybe also related to other (child?) processes still
running). Probably, most of this kind of space usage control does not
have to be done in the kernel, but could be done in userspace. However,
the daemon would need special information from the kernel.

The basic version of such space control rules could for example return
'out of disc space' to processes before all space is used, disallowing a
process which fills /tmp to also fill all swap.

> Wouldn't it be difficult to figure out disk space requirements for this
> configuration? It seems like if I knew that at times I needed 100MB for
> /tmp, and 100MB for swap, I'd be forced into making sure there was 200MB
> available in /tmp if the two shared that area.

Determining the amount of space needed for the integrated /tmp and
swap would be done the same way you now determine the amount of swap you
need and the amount of /tmp space you need. I think this is mostly done by
using experience from the past, by examining the amount of used space in a
similar configuration, etc. The difference is that, if /tmp and swap are
integrated you only have to determing one amount for both, instead of two
separately. It would seem to me that it becomes easier with /tmp and swap
integrated (Yes of course, the first time when you change to integrated
/tmp and swap, your best guess will be to add the amounts for /tmp and
swap).

The reason I thought about the possibility to use the same disk
space for /tmp and swap is not the saving of some drive space. The reason
is that both the swap and /tmp contain the same type of data: temporary
storage. Why have two different kinds of temporary storage if you can use
a single integrated solution?

If there are enough reasons to not integrate /tmp and swap, then I
still think that there are some good reasons to design a special fileystem
just for /tmp (that only already looks like a lot of work to me). In that
case, I would like to ask people for pointers (preferrable on the net)
about publications about filesystem types and their relative advantages
(in order to find a good candidate for /tmp).

> Jim
>
>
> At 06:43 PM 5/22/98 +0000, Jelle Foks wrote:
> >Hello,
> >
> >I recently saw that Solaris shares the drive space for swap and for the
> >files in the /tmp directory (/tmp is mounted from the swap partition as
> >filesystem type swapfs).
> >
> >Has anybody thought about this? Has this already been done for linux in
> >some patch somewhere? Are there solid reasons not to do this? would a
> >significant performance impact be unavoidable? Would it be difficult to
> >use the ulimit settings for quota on the '/tmp-filesystem'?=20
> >
> >Greetings,
> >
> >Jelle.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans