Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site wgivax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!unccvax!wgivax!fpt
From: fpt@wgivax.UUCP (Fred Toth #7252)
Newsgroups: net.unix-wizards
Subject: Re: dissappearing disk space (v7)
Message-ID: <124@wgivax.UUCP>
Date: Fri, 6-Sep-85 14:58:14 EDT
Article-I.D.: wgivax.124
Posted: Fri Sep  6 14:58:14 1985
Date-Received: Sun, 8-Sep-85 16:37:16 EDT
Lines: 31

Version 7 had a bug that would allow more blocks to be allocated
to an inode than the size field required. This was totally
consistant, in that fsck would not complain. Allocated blocks
plus free blocks still equaled total blocks.

I suspect this is your problem.

We first found this problem after porting the SV program dcopy
to our version 7 system. After running a test dcopy to reorganize
the disk, we ended up with a few thousand more free blocks. Hmm,
must be a bug in the port, right? Well, after much head scratching
and studying of the dcopy source, I decided to write a program
to check the above mentioned condition. Sure enough, our missing
blocks were there all along, allocated to files that had no use
for them.

I will post a copy of scani.c to net.sources. If you don't get it
and you want a copy, drop me a line. Scani reads the disk directly,
and reports inode numbers that fall into this class. You can use
ncheck to get the names. Copying and deleting the original files
will free up the space.

I never bothered to look for the problem in v7. Maybe someone else
out there knows about this bug and how to fix it. 

Obviously it's still around.

Fred Toth
Washburn Graphics, Inc.
Charlotte, NC
decvax!mcnc!unccvax!wgivax!fpt