Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site jplgodo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!oberon!smeagol!jplgodo!steve
From: steve@jplgodo.UUCP (Steve Schlaifer x3171 156/224)
Newsgroups: net.unix
Subject: Re: 4.2BSD Filesystem troubles....
Message-ID: <549@jplgodo.UUCP>
Date: Fri, 17-Jan-86 13:15:19 EST
Article-I.D.: jplgodo.549
Posted: Fri Jan 17 13:15:19 1986
Date-Received: Mon, 20-Jan-86 04:49:04 EST
References: <12700003@pbear.UUCP>
Organization: Jet Propulsion Labs, Pasadena, CA
Lines: 21

> 
> I am working with a vanilla 4.2BSD VAX system, and I have been noticing that
> disk space is vanishing from my filesystems. I have a 45Mb filesystem that
> fsck says has 13Mb free, but df states is full.!!..??? (and can't be written to)
> 
I don't know if this applies in your case but on a Ridge 32 running ROS 3.3
(a derivative of system V) file space is allocated in 4K chunks.  If you
build a 100 byte file, for example, its size is reported (by ls -l) as 100
bytes but it takes up 4K bytes of disk space.  If you build lots of small files
this way, you will use up the disk but adding up the file sizes will still
indicate that there is lots of room left.  df uses the number of 4K blocks
available to report the amount of free space left and will show that the disk
is full.  One solution is to build an archive file (using ar or tar) to put
all the small files in.  This could then fit 40 100 byte files into a 4K block
rather than using 160K bytes of disk to hold them if they are seperated.

...smeagol\			Steve Schlaifer
......wlbr->!jplgodo!steve	Advance Projects Group, Jet Propulsion Labs
....group3/			4800 Oak Grove Drive, M/S 156/204
				Pasadena, California, 91109
					+1 818 354 3171