Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/3/84; site maynard.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!talcott!wjh12!maynard!campbell
From: campbell@maynard.UUCP (Larry Campbell)
Newsgroups: net.unix-wizards
Subject: Re: Re: dissappearing disk space (v7)
Message-ID: <149@maynard.UUCP>
Date: Sat, 7-Sep-85 20:09:34 EDT
Article-I.D.: maynard.149
Posted: Sat Sep  7 20:09:34 1985
Date-Received: Tue, 10-Sep-85 04:05:07 EDT
References: <124@wgivax.UUCP>
Organization: The Boston Software Works Inc., Maynard, MA
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.
> 
> Fred Toth
> Washburn Graphics, Inc.
> Charlotte, NC
> decvax!mcnc!unccvax!wgivax!fpt

Yes, indeed.  Last night it happened again and I went adb-ing through
the inode for /usr/lib/news/history.  It was a "large" file, with 70
blocks.  The first i_addr entry pointed to a perfectly reasonable
indirect block with 70 entries followed by zeroes.  But i_addr[1]
through i_addr[8] also contained pointers to indirect blocks, which
in turn pointed to all the lost disk space.  Copying the history
file and deleting the original freed up the lost blocks.

Later this weekend I'll try running the scani program you posted to see
if any other files are involved.  Any insights into what provokes the
bug, possible fixes or workarounds, would be greatly appreciated.
-- 
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.arpa