dave@elandes.UUCP (Dave Mathis @ ELAN designs) (09/23/88)
Recently my system lost some inodes and decided that the disk was full (it wasn't). In itself, that wasn't too disasterous, a simple set of fsck's can take care of the results. The real problem started when uucico started up for a news feeding. There were still inodes available so files could be created, but no writes on new files could succeed. HOWEVER, it seems that uucico never checks to see if a write to a TM* file succeeds, it just kept receiving news, not being able to write it and responding to the other system that the file was OK. This has happened on a few occasions, and by loosing the free list, having the file system really fill up, or by a bad write/sector confusing the file system. In general, I think this is antisocial behavior and would expect that uucico would either hang up the conversation or tell the other system that the receive didn't go so well. So, can anyone explain to me what is really happening, and if there is a way to prevent this. The system is SCO Xenix 2.2 (286) on a real IBM AT. Dave Mathis UUCP oliveb!elandes!dave
craig@n8ino.UUCP (R. Craig Peterson ) (09/25/88)
In article <585@elandes.UUCP> dave@elandes.UUCP (Dave Mathis @ ELAN designs) writes: >Recently my system lost some inodes and decided that the disk was full >(it wasn't). In itself, that wasn't too disasterous, a simple set of >fsck's can take care of the results. The real problem started when .... > is a way to prevent this. The system is SCO Xenix 2.2 (286) on a real > IBM AT. >Dave Mathis UUCP oliveb!elandes!dave There is a known bug in most UNIX releases that causes systems to loose track of free inodes when there are alot of file deletions/creations, as is the case with running news. I don't remember the details of the actual problem, but you would certainly need source to the kernel file system code in order to fix it. Maybe Microsoft/SCO has a fix to this problem. If not, you will have to go on fsck'ing. BTW I think a corrected code fragment was posted to the net, give or take a year ago... I don't know if I still have it around. This is one bug that isn't unique to XENIX. -- R. Craig Peterson (N8INO) mcdchg!n8ino!craig craig@n8ino.UUCP E Pluribus Unum (NSA stuff - terrorist, DES, cipher, secret, NRO, CIA)
dave@elandes.UUCP (D. Mathis) (09/25/88)
In article <58@n8ino.UUCP>, craig@n8ino.UUCP (R. Craig Peterson ) writes: : In article <585@elandes.UUCP> dave@elandes.UUCP (Dave Mathis @ ELAN designs) writes: : : :Recently my system lost some inodes and decided that the disk was full : :(it wasn't). In itself, that wasn't too disasterous, a simple set of : :fsck's can take care of the results. The real problem started when : :Dave Mathis UUCP oliveb!elandes!dave : : There is a known bug in most UNIX releases that causes systems to : loose track of free inodes when there are alot of file : deletions/creations, as is the case with running news. : : BTW I think a corrected code fragment was posted to the net, give or : take a year ago... I don't know if I still have it around. : : R. Craig Peterson (N8INO) I guess I didn't make my main concern evident. The real problem is not the lost inodes, I know that at times the kernel loses track of the free list. The REAL PROBLEM is that uucico doesn't check for valid writes when it is receiving files, thereby creating any number of 'valid' 0 length files. I beleive it should fail on the write and fail on the receive. -- Dave Mathis, ELAN designs UUCP ...oliveb!elandes!dave
john@basser.oz (John Mackin) (09/26/88)
In article <58@n8ino.UUCP> craig@n8ino.UUCP (R. Craig Peterson (n8ino)) writes: > There is a known bug in most UNIX releases that causes systems to > loose track of free inodes when there are alot of file > deletions/creations, as is the case with running news. Absolutely incorrect. Change `most UNIX releases' into `some releases of System V' for the correct version. > This is one bug that isn't unique to XENIX. No, just unique to System V. `Consider it broken.' John Mackin, Basser Department of Computer Science, University of Sydney, Sydney, Australia john@basser.oz.AU (john%basser.oz.AU@UUNET.UU.NET) {uunet,mcvax,ukc,nttlab}!munnari!basser.oz!john
campbell@redsox.UUCP (Larry Campbell) (09/29/88)
In article <587@elandes.UUCP> dave@elandes.UUCP (D. Mathis) writes: } }I guess I didn't make my main concern evident. The real problem is not }the lost inodes, I know that at times the kernel loses track of the free }list. The REAL PROBLEM is that uucico doesn't check for valid writes }when it is receiving files, thereby creating any number of 'valid' 0 length }files. I beleive it should fail on the write and fail on the receive. Get Honey DanBer. Probably the single most winning feature of HDB is that it Does The Right Thing when the disk fills up.