pjh@mccc.UUCP (Peter J. Holsberg) (02/18/88)
Last night in lab, I had about 12 users compiling small C programs --
maybe 30 lines each --, and I started to get "no space on disk 0
partition 0" messages. A fast df -t revealed that I had 0 blocks left
in /, but another df -t some 10 seconds later showed that 350-450 blocks
remained.
I don't understand where in / these blocks are being used, and why --
allof a sudden, / is crowded. (My system has 3 file systems: /, /usr,
and /usr2.) I'm guessing that things are happening in /tmp, right?
Should I move the tmp directory to another files system? Is it possible
to do that? Or is my partition 0 just "fragmented" so that an 'fsck'
will take care of things?
Thanks for your help.
--
Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh
Technology Division CompuServe: 70240,334
Mercer College GEnie: PJHOLSBERG
Trenton, NJ 08690 Voice: 1-609-586-4800russ@llama.rtech.UUCP (Russ Spence) (02/21/88)
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 -- >maybe 30 lines each --, and I started to get "no space on disk 0 >partition 0" messages. A fast df -t revealed that I had 0 blocks left >in /, but another df -t some 10 seconds later showed that 350-450 blocks >remained. > >I don't understand where in / these blocks are being used, and why -- >allof a sudden, / is crowded. (My system has 3 file systems: /, /usr, >and /usr2.) I'm guessing that things are happening in /tmp, right? >Should I move the tmp directory to another files system? Is it possible >to do that? Or is my partition 0 just "fragmented" so that an 'fsck' >will take care of things? /tmp is used by the compiler to store temporary files. When compiling a very large file (or many small files) you run out of space on / because of the amount of space used in /tmp for C compilations. You should probably increase the size of / (or move /tmp to another file system, or its own file system). Unfortunately, this is usually a painful process on a 3B. You have to boot from floppy, it trashes the disks and you have to recover from floppy or cartridge backups, etc. Fixing a similar problem on my old 3B2/400 (increasing swap space in order to run INGRES) took about 4 hours of real time. -- Russell Spence Relational Technology Inc. {sun,mtxinu,ihnp4}!rtech!russ Then you'll... never hear... surf music... again.
jgy@hropus.UUCP (John Young) (02/22/88)
On 3B2 compilers you can set the environment variable TMPDIR (export it) to be the directory used by most of the SGS sub-processes.
charles@dragon.UUCP (Charles Wolff) (02/23/88)
In article <1733@rtech.UUCP> russ@llama.UUCP (Russ Spence) writes: >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 -- >>maybe 30 lines each --, and I started to get "no space on disk 0 > > /tmp is used by the compiler to store temporary files. When > compiling a very large file (or many small files) you run out > of space on / because of the amount of space used in /tmp for > C compilations. You should probably increase the size of > / (or move /tmp to another file system, or its own file system). A simpler solution may be to have your users set the $TMPDIR environment variable in their .profiles - at least on our machine, "cc" recognizes this env var and puts your temporary files in the directory you specify. If /tmp is overloaded, you can put temp files in /usr/tmp, /usr2/dogstuff, or whereever there is space... check the manual for your system to see if there's a similar env var you can use... -- Thus the unfacts, did we possess them, are too| Charles Wolff imprecisely few to warrant our certitude... | Motorola Microsystems -James Joyce, Finnegan's Wake | Tempe, AZ (602) 438-3432
wjc@ho5cad.ATT.COM (02/24/88)
In article <1733@rtech.UUCP> russ@llama.rtech.UUCP (Russ Spence) writes: >In article <225@mccc.UUCP> pjh@mccc.UUCP (Peter J. Holsberg) writes: >>I don't understand where in / these blocks are being used, and why -- >>allof a sudden, / is crowded. (My system has 3 file systems: /, /usr, >>and /usr2.) I'm guessing that things are happening in /tmp, right? > >/tmp is used by the compiler to store temporary files. When >compiling a very large file (or many small files) you run out >of space on / because of the amount of space used in /tmp for >C compilations. You should probably increase the size of >/ (or move /tmp to another file system, or its own file system). >Unfortunately, this is usually a painful process on a 3B. You > There is some luck possible here. If the only thing you're having problems with is during compile sorts of things, then it is easy to change the temporary directory used by many versions of "cc". Obviously, this won't cure all your problems if some other sorts of stuff are crowding /tmp. Assuming you have plenty of space in /usr/tmp, try TMPDIR=/usr/tmp; export TMPDIR (some "cc"'s use TEMPDIR instead). To see if this causes "cc" to use /usr/tmp, just do a medium long compile and abort it in the middle. The scratch files are usually left hanging around, so see if they show up in /usr/tmp. If so, put the above line in /etc/profile and that should unclog /tmp for you. (Some "cc"'s use /tmp by default, others /usr/tmp.) Bill Carpenter (AT&T gateways)!ho5cad!wjc HO 1L-410, (201)949-8392, OCW x4367
ejw@sask.UUCP (Eric Woodsworth) (02/29/88)
> Last night in lab, I had about 12 users compiling small C programs -- > maybe 30 lines each --, and I started to get "no space on disk 0 > partition 0" messages. A fast df -t revealed that I had 0 blocks left > in /, but another df -t some 10 seconds later showed that 350-450 blocks > remained. > Peter Holsberg UUCP: {rutgers!}princeton!mccc!pjh We get the same behaviour on /dev/root when we are running a lot of pipes, since root is being used on our system for temporary pipe storage. You can change the filesystem used for this, but this is pointless if your bootup procedure uses pipes. I suggest that if the free space on /dev/root is insufficient, expand the filesystem or delete some files to free up space. -- ------- Eric Woodsworth / Canadian Wildlife Service / Saskatoon / Canada UUCP: pmbrc!ejw BITNET: WOODSWORTH@SASK Tel: (306)-975-4087
olapw@olgb1.oliv.co.uk (Tony Walton) (03/02/88)
In article <1733@rtech.UUCP>, russ@llama.rtech.UUCP (Russ Spence) writes: > 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 -- > >maybe 30 lines each --, and I started to get "no space on disk 0 > > > /tmp is used by the compiler to store temporary files... ... If you're using the AT&T Issue 4.1 (possibly Issue 3.0 as well, I can't remember) you can set the TMPDIR environment variable to some directory where there's space. Use the # option to cc to see where the beast is putting its temporary files - if you set TMPDIR=/usr/tmp and export TMPDIR, and cc still puts its files in /tmp it's not going to work and you'll have to either expand root or put /tmp on a separate filesystem. -- Tony Walton, OEM/VAR Division, British Olivetti Ltd., Wellington House, 154-160 Upper Richmond Road, London, England SW15 2FN LONDON, SW15 2FN. Tel: (+44) 1 789 6699 Telefax: (+44) 1 785 6670 Telex:27258 Uucp : { ukc | mcvax!olnl1 | ihnp4!cuuxb | iconet | olhqma } !olgb1!olapw
mouse@mcgill-vision.UUCP (der Mouse) (03/13/88)
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
edw@IUS1.CS.CMU.EDU (Eddie Wyatt) (03/24/88)
In article <995@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) 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). Sun's version of cc has a switch which allows you to use pipes instead of intermediate files - the "-pipe" option. -- Eddie Wyatt e-mail: edw@ius1.cs.cmu.edu
pgn@iwtpm.ATT.COM (Novorolsky) (03/25/88)
From article <1206@PT.CS.CMU.EDU>, by edw@IUS1.CS.CMU.EDU (Eddie Wyatt): > In article <995@mcgill-vision.UUCP>, mouse@mcgill-vision.UUCP (der Mouse) 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? > > Sun's version of cc has a switch which allows you to use pipes Careful! Pipes are actually I/O on any implementation of UNIX (TM) that I have seen. The way these work is to use disk blocks as buffer space. That is that although the use of a pipe will greatly reduce the amount of disk space used, it does not avoid the use of the filesystem altogether, and you may still run out of disk space if space is really tight. Unless someone has changed the system configuration, the root disk partition is also used as the PIPEDEV (which defines what device is used to buffer pipes) The "/etc/sysdef" command can be used to verify the PIPEDEV. (It can also be found in the /etc/system file) Paul Novorolsky Indian Hill West Naperville, Ill
gwyn@brl-smoke.ARPA (Doug Gwyn ) (03/25/88)
In article <127@iwtpm.ATT.COM> pgn@iwtpm.ATT.COM (Novorolsky) writes: >From article <1206@PT.CS.CMU.EDU>, by edw@IUS1.CS.CMU.EDU (Eddie Wyatt): >> Sun's version of cc has a switch which allows you to use pipes >Careful! Pipes are actually I/O on any implementation of UNIX (TM) >that I have seen. Well, of course they're I/O. I know of three essentially different implementations of pipes on genuine UNIX variants, and other methods on UNIX emulators. The real UNIX methods are: ripped-off inodes from pipedev (typically same as root fs) socket-pairs cross-coupled streams The key to using pipes in cc is that they avoid the need to store the entire intermediate file between passes, so total required storage can indeed be reduced by this method.