Xref: utzoo comp.unix.questions:6192 comp.sys.att:2840
Path: utzoo!mnetor!uunet!husc6!bbn!mit-eddie!ll-xn!ames!eos!aurora!labrea!decwrl!pyramid!prls!philabs!micomvax!zap!iros1!mcgill-vision!mouse
From: mouse@mcgill-vision.UUCP (der Mouse)
Newsgroups: comp.unix.questions,comp.sys.att
Subject: Re: NO SPACE  Error message
Message-ID: <995@mcgill-vision.UUCP>
Date: 13 Mar 88 10:04:19 GMT
References: <225@mccc.UUCP>
Organization: McGill University, Montreal
Lines: 42
Keywords: 3b2/400, SysVr3.0

In article <225@mccc.UUCP>, pjh@mccc.UUCP (Peter J. Holsberg) writes:
> Last night in lab, I had about 12 users compiling small C programs
> [and "no space on disk 0 partition 0" messages started appearing].
> [/ was out of space, but some space appeared shortly thereafter.]

> I'm guessing that things are happening in /tmp, right?

Almost certainly.  Every UNIX C compiler I've seen uses /tmp to hold
intermediate results, and other programs do the same.  Circumstantial
evidence also indicates /tmp (the space hog vanished quickly, which
files in /tmp tend to do).

> Should I move the tmp directory to another files system?

If you can manage it, I would recommend giving /tmp a partition of its
own, so that when (not "if") it runs out of space, it doesn't take
anything else with it.  To do this, find or make a partition with as
much space as you want to give to /tmp (a few megs is probably enough)
and specify that it is to be mounted on /tmp just as for any other
filesystem (eg, /usr).  (On BSD systems I'm familiar with, this merely
consists of editing /etc/fstab; you might start looking there, or
perhaps you should start with the mount command.)

> Or is my partition 0 just "fragmented" so that an 'fsck' will take
> care of things?

Unless SVR3 has done something peculiar to the filesystem, I doubt that
fragmentation has anything to do with the problem, or that fsck will do
anything about either fragmentation or your problem.  Fsck might help
if you had orphaned files (files with no corresponding directory
entries); it certainly couldn't hurt to fsck that partition (but be
careful, running fsck on the root partition requires care).

There is another possibility: that programs have been creating files in
/tmp but somehow neglecting to remove them.  You might check /tmp for
files older than (say) four days and remove them, unless you have
something that keeps stuff in /tmp that you really want to remain there.

					der Mouse

			uucp: mouse@mcgill-vision.uucp
			arpa: mouse@larry.mcrcim.mcgill.edu