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.