thomasm@elk.ingres.com (tom markson) (06/14/91)
I am running SCO ODT 1.1 with BNEWS and have found that the AFS (file system) seems to incorrectly deal with the expired history and active files. It appears that when expire is run, the old history file is not put back in the free list. Since these files tend to be quite large, my disk space is slowly consumed. In order to reclaim this space, I go into Single-user mode, umount the file system, and fsck it. Many POSSIBLE FILE SIZE ERRORs appear during this process and the fsck links lots of files into lost+found. Next, I mount the file system and rm /u/lost+found/*. I then umount the file system again and repeat the fsck/mount/rm/umount procedure until no more more files are connected into lost+found. This is pretty much a pain, because I have to do this every couple of days or mega-bytes simply vanish from the filesystem. My questions are three: 1. Is this a bug specifically related to AFS? (my old Xenix System never did this with the Xenix file system). 2. Are any of the other file systems better for this sort of thing? 3. Has anyone else run into this problem and found a fix (either in the OS or in Bnews)? Does Cnews do this too? Thanks 1 millions in advance -- Tom Markson Unix Systems email: thomasm@ingres.com Ingres Corp
caf@omen.COM (Chuck Forsberg WA7KGX) (06/15/91)
In article <1991Jun13.191114.6944@ingres.Ingres.COM> thomasm@elk.ingres.com (tom markson) writes:
-I am running SCO ODT 1.1 with BNEWS and have found that the AFS (file
-system) seems to incorrectly deal with the expired history and active
-files. It appears that when expire is run, the old history file is not
-put back in the free list. Since these files tend to be quite large, my
-disk space is slowly consumed.
I've been running bnews for years starting with 286 Xenix. My expire
is rm -rf most of the time as the real expire is much slower and I'm
the only news user. But I don't recall any file system problems on
any production versions of the kernel.
It sounds like some process has opened a history file and is hanging
around too long. Make sure no news related processes are running
when you stop the system.
-
- 3. Has anyone else run into this problem and found a fix (either
- in the OS or in Bnews)? Does Cnews do this too?
-
I've run cnews expire with no obvious problems beyone the obvious one that
expire doesn't do what trn's mthreads program needs. So I still do an
rm -rf.
When compiling cnews, do NOT use the optimizer (-O) if you are using the
dbz routines. I also had to configure cnews with 0 mask because C2 even when
releaxed seems to interfere with things.
--
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf
Author of YMODEM, ZMODEM, Professional-YAM, ZCOMM, and DSZ
Omen Technology Inc "The High Reliability Software"
17505-V NW Sauvie IS RD Portland OR 97231 503-621-3406sef@kithrup.COM (Sean Eric Fagan) (06/15/91)
In article <1991Jun13.191114.6944@ingres.Ingres.COM> thomasm@elk.ingres.com (tom markson) writes: >In order to reclaim this space, I go into Single-user mode, umount the file >system, and fsck it. Many POSSIBLE FILE SIZE ERRORs appear during this >process and the fsck links lots of files into lost+found. Next, I mount the >file system and rm /u/lost+found/*. I then umount the file system again and >repeat the fsck/mount/rm/umount procedure until no more more files are >connected into lost+found. I had a similar problem. It was the disk, not the filesystem or filesystem code. Try backing up the disk, and then remaking the filesystem (including testing the drive). I should also point out that SCO runs B News on their 3.2 machines, and never had a problem like that. (kithrup runs C News, with dbz instead of dbx, so that could make a difference, but I doubt it.) -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.