henry@chinet.chi.il.us (Henry C. Schmitt) (01/19/91)
I recently ran into a problem and wonder if anyone knows a solution.
While working on compiling a couple large programs, I started getting
the error: Out of disk space on file system /usr (or something to
that effect). I did a df which showed that /usr had over 10,000 free
blocks (> 5 MB!!). However, doing a df as a normal user (I was root
for compiling) in another window showed 0 free blocks on /usr!!!
The other file systems showed discrepancies of 15-30% in free space
depending on whether or not I was root. Why is there free space only
discernable by root, but not accessable by root? What's going on
here? I'm confused.
--
H3nry C. Schmitt | CompuServe: 72275,1456 (Rarely)
| GEnie: H.Schmitt (Occasionally)
Royal Inn of Yoruba | UUCP: Henry@chinet.chi.il.us (Best Bet)
peter@csn.org (Peter Steinauer) (01/20/91)
In article <1991Jan18.165524.4327@chinet.chi.il.us> henry@chinet.chi.il.us (Henry C. Schmitt) writes: >I recently ran into a problem and wonder if anyone knows a solution. >While working on compiling a couple large programs, I started getting >the error: Out of disk space on file system /usr (or something to >that effect). I did a df which showed that /usr had over 10,000 free >blocks (> 5 MB!!). However, doing a df as a normal user (I was root >for compiling) in another window showed 0 free blocks on /usr!!! > >The other file systems showed discrepancies of 15-30% in free space >depending on whether or not I was root. Why is there free space only >discernable by root, but not accessable by root? What's going on >here? I'm confused. >-- > H3nry C. Schmitt | CompuServe: 72275,1456 (Rarely) > | GEnie: H.Schmitt (Occasionally) > Royal Inn of Yoruba | UUCP: Henry@chinet.chi.il.us (Best Bet) Berkley unix file systems have a 'dead zone' on each partition that only root can see. This block is set aside as protection so that the disk partitions don't fill up beyond a 'safe' level... (Older versions didn't handle full file systems very well :-<... ) I hope that answers your question to some extent... Pete Steinauer University of Colorado Boulder CU UnixOps - Systems Apple Computer CU Student Rep... internet: peter@boulder.colorado.edu AppleLink: ST0604
rmtodd@servalan.uucp (Richard Todd) (01/20/91)
peter@csn.org (Peter Steinauer) writes: >In article <1991Jan18.165524.4327@chinet.chi.il.us> henry@chinet.chi.il.us (Henry C. Schmitt) writes: >>I recently ran into a problem and wonder if anyone knows a solution. >>While working on compiling a couple large programs, I started getting >>the error: Out of disk space on file system /usr (or something to >>that effect). I did a df which showed that /usr had over 10,000 free >>blocks (> 5 MB!!). However, doing a df as a normal user (I was root >>for compiling) in another window showed 0 free blocks on /usr!!! >Berkley unix file systems have a 'dead zone' on each partition that only > root can see. This block is set aside as protection so that the > disk partitions don't fill up beyond a 'safe' level... (Older > versions didn't handle full file systems very well :-<... ) More precisely, the Berkeley-style filesystem routines include a whole bunch of optimizations to try and make sure that file blocks are allocated near each other (so as to minimize head seek time). Obviously, such complicated allocation strategies can only work well if there's a lot of free space to work with; in particular, when the disk is over 90% full, the optimized allocation strategies start to fail, meaning the system is forced to allocate space wherever it can find it (even if it's not in an "optimal" place), and your disk thruput starts to go down the drain. So by default when a Berkeley-style filesystem is made, it's set up so that ordinary users (not root) can't use up the last 10% of the disk. However, if you, like me, have too many files and not enough cash for a new disk drive :-), you can alter the default percentage of free space reserved on that filesystem. The command you want is "tunefs", used as follows. Suppose that you've got /usr on slice 2 of SCSI drive 2. Then you'd do umount /usr # very important; you can't (easily) do this on a # mounted filesystem! tunefs -m 0 /dev/rdsk/c2d0s2 # set minfree to 0 on filesystem on # /dev/rdsk/c2d0s2 mount /usr Note that the unmount is very important; as the man. page says: This program should work on mounted and active file systems. Because the superblock is not kept in the buffer cache, the changes only take effect if the program is run on unmounted file systems. To change the root file system, the system must be rebooted after the file system is tuned. And for those of you setting this on the root filesystem, when they say "reboot", they don't mean "/etc/reboot" or "shutdown" (apparently these cause the old superblock info to be flushed to disk trampling over your changes); apparently you really have to do the tunefs on root and then hit the switch on the side. (Needless to say, you shouldn't try this except in single-user mode...) Perhaps in the next release they'll make tunefs a sash(8) utility so we don't have to deal with this bogosity when doing tunefs on the root fs... -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Try looking in the Yellow Pages under 'Psychotics'." -- Michael Santana