Messages in this thread | | | Date | Sun, 24 May 1998 18:54:31 +0000 ( ) | From | Jelle Foks <> | Subject | Re: /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
| |