campbell@maynard.UUCP (Larry Campbell) (09/02/85)
A few weeks ago I posted a message (to net.unix-wizards only)
describing a problem with mysteriously disappearing and reappearing
disk space on my VENIX (V7 port) system. I got a few responses that
were helpful in eliminating possibilities, but none that explained the
problem.
Well, it just happened again... 8,000 blocks just *zap* disappeared
without a trace. This time I discovered that deleting my news history
file (which claimed to be only about 32K bytes long) freed up the
space! Of course, now that the file is gone I have no evidence to sift
through. Next time it happens I'll know where to look (but it happens
only about once or twice a month).
Has anyone else ever seen the history file do this kind of thing?
I am running 2.10.2 news under VENIX/86 (a fairly vanilla V7 port).
Larry Campbell decvax!genrad
The Boston Software Works, Inc. \
120 Fulton St. seismo!harvard!wjh12!maynard!campbell
Boston MA 02109 / /
ihnp4 cbosgd
ARPA: campbell%maynard.uucp@harvard.arpacampbell@maynard.UUCP (Larry Campbell) (09/05/85)
I've been getting the same few suggestions repeatedly in response to
my original question, so here's what I should have posted earlier --
a summary of hypotheses people have offered that have not panned out:
(Synopsis: VENIX/86 system mysteriously loses many thousands of blocks
of disk space which later mysteriously come back. Latest
discovery is that deleting /usr/lib/news/history frees up the
space, even though that file claims to be fairly small.
VENIX/86 is a V7 port; news software here is 2.10.2.)
Several people have suggested a temporary file that gets unlinked
but not closed. Nope, reloading doesn't free up the space.
Another suggestion was a filesystem mounted on a nonempty directory.
Very plausible, but not the case here.
A third suggestion was holes in a file (lseek past EOF). I wrote a
test program to try this out, and only succeeded in getting du and
quot to think that the file occupied MORE blocks than it really did.
My problem is the reverse -- that du and quot think the filesystem has
lots of space, but it really doesn't.
Since du seems to believe the EOF pointer (st_size field of stat(2)),
it's occurred to me that perhaps /usr/lib/news/history is somehow
getting blocks allocated past EOF. I can't think of a way to make
that happen, though. Any suggestions?
--
Larry Campbell decvax!genrad
The Boston Software Works, Inc. \
120 Fulton St. seismo!harvard!wjh12!maynard!campbell
Boston MA 02109 / /
ihnp4 cbosgd
ARPA: campbell%maynard.uucp@harvard.arpacampbell@maynard.UUCP (Larry Campbell) (03/22/86)
A few months back I initiated a discussion in this newsgroup about
disappearing disk space. Apparently both V6 and V7 have bugs that
can cause files n bytes long to own many more than (n+511)/512 blocks.
I have just posted a program to net.sources (written for V7 by Fred
Toth and modified for V6 by me) which finds such files, so you can
delete them and free up the space. It just found 5300 blocks for me
this morning. Thank you, Fred.
--
Larry Campbell The Boston Software Works, Inc.
ARPA: maynard.UUCP:campbell@harvard.ARPA 120 Fulton Street
UUCP: {harvard,cbosgd}!wjh12!maynard!campbell Boston MA 02109jsdy@hadron.UUCP (Joseph S. D. Yao) (03/25/86)
I'll have to go back and dig up the code and fix for the "Black
Hole" bug, presented at Boulder. Directories were getting more
files than they could legitimately hold, causing singularities,
wherein the directory would collapse and no files could be
retrieved from them or perceived in them, although more files
could be put in them and thus disappear from the face of the disk.
This was presented as a detective story, on how the reason for
disk space disappearing was discovered. It was named before we
knew that the theatre in which it was presented was showing the
Disney film of the same name.
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}