> On Fri, 28 Nov 1997, Chris Gilbert wrote:
> 
> > On Fri, 28 Nov 1997, Patrick Welche wrote:
> > 
> > > Stephen Hobbs wrote:
> > > 
> > > > / is 74% used however, and I created it as 32MB (I think) as 
> > > > suggested in the install guide. Should I have made it bigger?
> > 
> > Do you have a seperate /var partition, if you do it shouldn't need to be
> > bigger...
> >  
> 
> /var is indeed separate, 48MB ISTR. What I can't work out is how / has 
> almost nothing on it, but is almost full... Confusing.
> 

Some processes open a file, and then unlink it.  This creates a file on 
the disk, but it has no entry in the file system, which means that the 
disk space seems to have disappeared!  When the file is finally closed, 
the disk space is recovered.  I'm not saying that is the case here, but it 
is one possible cause.  A utility called lsof (I'm not sure if it's been 
ported to RiscBSD) can be used to find things like this.  Why do programs 
do this? well, that way, multiple copies of the program can run without 
overwriting each others files, even though they open the same file to 
start with.


> Should the compiler be working in something like /var/tmp then?
> I really should get a book on this stuff one day - any recommendations
> anyone?
> 

Some programs recognize the environment variables TMP, TEMP, TEMPDIR or 
TMPDIR (it's not very standardized).  You could try setting one of these 
to point to a large amount of spare disk.  Your run log in a previous post 
suggested that it was ar that was running out of space (not surprising if 
you were building a big library), so you could try running "strings" on 
the ar binary to find out if it respects any of the above.  If the ar in 
RiscBSD is based on GNU binutils, then it will probably respect the 
setting of TMPDIR.

Richard.