> 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.
Well.. Quota would work here.. But the solution could indeed be nicer then
that.
>
> 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.
We have one: Quota. A ulimit based system would be nicer though.
> 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?-).
I think that when the system runs out of mem+swap it starts thrashing then
kills off processes biggest first (and for alot of unhappy folks, that
usually is X which ends up killing all their X apps, and sometimes leaving
the console unusable). Or perhaps they only die when they try to allocate
more.
> 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.
Actually, smart programmers should be able to create/open the file then
unlink it. As long as the program is running then it should be fine
(though it will only be able to share that file with itself and childern).
When the last program closes it then the file will no longer exist.
> 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.
Sounds like quotas to me.. :)
[snip]
>
> 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?
This actually makes sence.
> 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).
Well, look at what tmp needs: Fast, Fast, Fast, efficent storage of many
small files, shallow directory nesting.
and what it doesn't need: Longterm storag (never required across reboots)
Perhaps a super-dulited version of ReiserFS is in order. Using trees to
store metainfo and blockmaps and keeping the maps in ram.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu