> On Sun, 24 May 1998, Jelle Foks wrote:
> > 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.
Unless we look a bit more carefully to find the process (or parent-child
chain of processes) that has been growing with the fastest rate in the
last few seconds. Maybe also use the time that a process has been running,
which works if we can assume that processes that have been around for a
while can be 'trusted' not to be the wrongdoers. In case of a process
going bezerk (on purpose or not), this type of rules will mean the bezerk
process will be asked to leave, not just the largest process.
> > 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.
Too bad that not all programmers are model programmers all the time,
and too bad not all /tmp traffic is between parents and children. Of
course, when all things are done well, a process doesn't ever segfault and
never leaves files in /tmp. But we have to deal with an imperfect user
space, and I think it would be nice if the kernel provided some protection
(in fact, I believe that's the most imporant feature of a 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.
>
> Sounds like quotas to me.. :)
I am under the impression that quota's are absolute (soft- and
hard-)limits on disk usage per uid, independent from partition free-space.
Therefore, I don't think that it's exactly 'quota'. I suggested such a
space control as a way to ensure processes filling up /tmp would always
leave some free swap in the integrated /tmp and swap disk space.
> [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.
Do you think that could significantly beat ext2fs (did you see the
benchmarks posted by Larry McVoy last saturday)?
Could you tell me where I can find more about this Reiserfs? (I must admit
that I'm not a filesystem expert...).
I'm beginning to get the idea that good space control for swap and /tmp
and integrating the two in one solution are two separate things
that should be looked at separately.
Greetings,
Jelle.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu