Subject: Re: df block count + minfree == disk full
To: Balazs Bela Kosaras <bbk201@is8.nyu.edu>
From: Frederick Bruckman <fb@enteract.com>
List: port-mac68k
Date: 09/24/1999 10:07:37
On Fri, 24 Sep 1999, Balazs Bela Kosaras wrote:

> That's fine, but how can the used block count be so high when the /tmp
> directory is supposed to be cleared at boot time? The result is that ed/vi
> cannot create a file because it thinks that /tmp is full (see below). (As
> root, ed/vi doesn't complain about /tmp being full, of course.) Am I
> pushing my luck with large partitions or is this something else?

Not only that, but all those blocks are used by an empty file system
(only 2 inodes).
 
> Another weird thing has to do with nsectors and ntracks. Mkfs uses 218
> sectors/track and 5 tracks/cylinder to format the partitions. disklabel
> now shows 217 sectors/track; at other times, disklabel reports 32
> sectors/track and 64 tracks/cylinder. Is this relevant at all here?

Try 'umount /tmp; newfs /dev/rsd0h; fsck -f /tmp; mount /tmp'.

> # cat /etc/fstab
> /dev/sd0a	/	ffs	rw 1 1
> /dev/sd0b	none	swap	sw 0 0
> /dev/sd0g	/var	ffs	rw 1 2
> /dev/sd0d	/usr	ffs	rw 1 3
> /dev/sd0e	/usr/local	ffs	rw 1 4
> /dev/sd0f	/home	ffs	rw 1 5
> /dev/sd0h	/tmp	ffs	rw 1 6
                                     ^
> kern		/kern	kernfs	rw 0 0
> proc		/proc	procfs	rw 0 0

The allowable choices in that last column are '0', '1', and '2'.
[fstab(5)]. Don't see how that would cause a problem with "df", unless
maybe the system crashed at one time and /tmp never got fsck'd.