shawn@mit-eddie.MIT.EDU (Shawn F. Mckay) (12/27/86)
I have a strange problem, running BSD 4.3. I have RFS installed in the kernel, and it seems to run fine on an adjacent machine. (Other machine runs Ultrix V1.1). The 4.3 machine runs on a 750 vax, with the RVD code compiled into it, but no RFS code. (The rvd code sits idle). It also has COMPAT compiled into it. I wanted to test a new kernel out, (make a clean kernel work before hacking), and did the generic config, make depend, and them make vmunix. I did the make vmunix at a nice of -20. When the whole thing started I had about 600 blocks free on /dev/ra0a. (My root partition). But I soon got messages saying I was out of space. In fact, doing a df show'd me being at 102%, 0 free. I figured I must have tossed in the wrong kernel, so I halted, and came up on a known good kernel, and did a df. Same results, so I ran fsck, and it said I had 616 free blocks. (Although df still says I have no space). I can copy /vmunix into /vmunix.junk without problem, so the kernel agrees with fsck. It would seem that the actual count of free blocks, and the count kept in the super block are different, I ran icheck -s in hopes of correcting this, but to no avail. Somehow I think fsck should pick up on the problem I am having, but it's not. In any case, I would like to know if by chance anyone out there has had this problem before, and might be able to lend some information my way. An idea on how to re-sync the superblock free count, and the real free count would also be welcome. Also, RFS doesn't document very well why it is affraid of being run with 'COMPAT', so I have to ask, does anyone know the reason behind this? Could this be behind my problem? Also, while we are talking about RFS, on the 4.3 machine when it works ok, I cannot seem to get it to let me setuid to my user id on the 4.3 system from the remote site. The 4.3 system prints all kinds of interrupted system call messages in the rfs_log file, and loggs me as guest... Anyone run into this before? Thanks for any help, -- Shawn
bzs@bu-cs.bu.EDU (Barry Shein) (12/27/86)
From: "Shawn F. Mckay" <shawn@mit-eddie.MIT.EDU> >When the whole thing started I had about >600 blocks free on /dev/ra0a. (My root partition). But I soon got messages >saying I was out of space. In fact, doing a df show'd me being at 102%, 0 >free. 4.x (x>1) reserves 10% (actually, it's settable, but that's the default) of the disk. Thus you can have a disk up to 110% full. The reason is that the disk block allocation routines start to slow down excessively with more than 90% of the disk full. The super-user is allowed to allocate this last 10%. Is this what is causing your "problem"? It's not a bug, it's a... The fact that you got errors at 102% could be caused by a number of things: a) If you were the super-user the other 8% might have been eaten up by a tmp file but released when the compile failed (ie. before you got a chance to do a 'df'.) b) If you weren't root something else was eating blocks while you were working, you were denied @100% but some other process ate the 2% (I dunno, a print spooler or mail daemon?) by the time you did a 'df'. Solution: free up some disk space on root (c'mon do you really need that oovmunix and /etc/termcap.orig file :-) or work on another disk. -Barry Shein, Boston University
chris@mimsy.UUCP (Chris Torek) (12/30/86)
In article <4384@mit-eddie.MIT.EDU> shawn@mit-eddie.MIT.EDU (Shawn >F. Mckay) writes: >... I soon got messages saying I was out of space. In fact, doing >a df show'd me being at 102%, 0 free. ... I ran fsck, and it said >I had 616 free blocks. (Although df still says I have no space). This is normal. Read the document on the 4.2 fast file system. By default, 10% of the free space on any file system is reserved to the super user. `df' hides this space, though not terribly effectively: all one need do is add up the `used' and `avail' values and note the discrepancy with `kbytes'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: seismo!mimsy!chris ARPA/CSNet: chris@mimsy.umd.edu