disk space : USED+FREE=TOTAL?

[Alan's Home for Wayward Notes File.]

In article <2697.26d4fadc at csc.anu.oz>, axt654 at csc.anu.oz writes:
> Hi,
> 	I've got a DECStation 3100 running Ultrix 2.1. We have a 600Mb hard disk
> with three partitions. Why doesn't USED+FREE=TOTAL ? I assume it isn't swap
> space as that's a separate partition (isn't it?) so maybe it's because the disk
> is fragmented? If so, how do you pack a ultrix disk? It seems we're missing
> over 50Mb!
> 
> Here is the output from df
> 
> Filesyste Total    kbytes   kbytes   %     
> node      kbytes   used     free     used  Mounted on
> /dev/rz1a   15551    9659    4337    69%   /
> /dev/rz1g  271848  215676   28988    88%   /usr
> /dev/rz1h  271849   71937  172728    29%   /u
> 
> 
> Thnaks in advance for any help
> tridge at aerodec.anu.oz.au

	As other replies have pointed out the biggest chunk of missing
	space is the 10% that's reserved.  If you consult the tunefs(8)
	manual page you'll that this can be changed.  The rest of it is
	a little harder to track if you aren't familar with the file
	system structure.

	A file system is made up of things called cylinder groups.  I
	think the default of number of cylinders in a group is 16, but
	this can be changed when you create the file system (see newfs(8)).
	Each cylinder group consists of a superblock, a cylinder group
	block, an inode table and data blocks.  The superblock and cylinder
	group block are probably 8 KB each, but the inode table is bigger.
	This non-data part of the file system is necessary overhead.  If
	you have lots of cylinder groups the amount of overhead adds up.

	Look at /usr/adm/install.FS.log to see the logs of the newfs
	commands that created the file.  From this you can find out
	how many cylinder groups your file systems were created with
	and from that estimate the overhead.

	Generally you don't need worry about file system fragmentation
	unless the file system gets very full.  When that happens all 
	the "good" place to allocate blocks are probably gone and ULTRIX 
	will just use the first suitable block it finds.  As long as the 
	file system stays full large files may be get blocks allocated
	from one end of the file system to the other.  Trying to reorganize
	the layout while the disk is full will only help file created early
	in the restore process.  Once the file system gets less full though
	you may have that were created when it was full.  These are the ones
	that will see the most improvment from being shuffled.  Currently
	the only supported way I know to reorganize is the use dump/newfs/
	restore.

	Keep in mind that this really only applies to large files.  Small
	files (file system block size or smaller) are inherently compressed.		For large files you can't really compress them anyway.  The way
	that blocks are generally allocated is that new directories tend
	to go into cylinder groups with the most free space.  Files created
	in those directories will prefer to be allocated in the same cylinder
	group.  Up to a certain size (setable with tunefs(8)) the file will
	be allocated block in that cylinder group.  After that, the blocks
	get allocated to other cylinder groups.  The result is that a very
	large file will tend to be spread in large chunks evenly across 
	the disk.

	For more information about the file system that ULTRIX uses
	refer to the paper:

		"A Fast File System for UNIX*", by Marshall Kirk
		McKusick, Willian N. Joy, Samuel J. Leffler, Robert
		S. Fabry.

	*UNIX is a trademark of AT&T.
	ULTRIX is a trademark of Digital Equipment Corp.
-- 
Alan Rollow				alan at nabeth.enet.dec.com