Subject: install/8177: mkfs can make a file system that passes fsck, but df reports bogus info
To: None <gnats-bugs@gnats.netbsd.org>
From: None <nate@portents.com>
List: netbsd-bugs
Date: 08/08/1999 13:09:52
>Number: 8177
>Category: install
>Synopsis: mkfs can make a file system that passes fsck, but df reports bogus info
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: install-manager (NetBSD system installation bug manager)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Aug 8 13:05:00 1999
>Last-Modified:
>Originator: Nathan Raymond
>Organization:
>Release: 1.4 mac68k
>Environment:
NetBSD speedbump 1.4 NetBSD 1.4 (GENERIC) #0: Sat May 8 20:54:59 PDT 1999 root2@c610:/usr/src/sys/arch/mac68k/compile/GENERIC mac68k
>Description:
I formatted a 2GB partition on a 3GB drive successfully with Mkfs 1.45 and noticed that df reported the empty partition was 37% full (about the size of the 1GB partition!), yet it was an empty partition:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/sd1a 3038071 1014244 1720019 37% /pub
The output of "du /pub":
8 /pub/lost+found
9 /pub
Unmounting the drive and running fsck -f returned no errors. After rebooting it was still there. Someone recommended changing the fslevel, so I changed it from a level 1 to a level 2 with:
fsck -T ffs:"-c 2" /pub
Remounted, problem still persisted. Then changed it to a level 3, still there. Finally gave up, and since it was an empty partition, ran newfs on it in netbsd. The output of df is now accurate:
Filesystem 1K-blocks Used Avail Capacity Mounted on
/dev/sd1a 2023869 1 1922674 0% /pub
Here is the top output of dumpfs on the Mkfs formatted fslevel 3 file system and the newfs formatted file system, for comaprison:
Before with Mkfs and fsck -T ffs:"-c 3" /pub:
Endian big-endian magic 11954 time Sat Aug 7 09:01:53 1999
cylgrp dynamic inodes 4.4BSD fslevel 3
nbfree 252977 ndir 2 nifree 505339 nffree 11
ncg 329 ncyl 5264 size 2092290 blocks 3038071
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
frag 8 shift 3 fsbtodb 1
cpg 16 bpg 795 fpg 6360 ipg 1536
minfree 10% optim space maxcontig 1 maxbpg 2048
rotdelay 4ms headswitch 0us trackseek 0us rps 60
ntrak 5 nsect 159 npsect 159 spc 795
symlinklen 60 trackskew 0 interleave 1 contigsumsize 0
nindir 2048 inopb 64 nspf 2
sblkno 16 cblkno 24 iblkno 32 dblkno 224
sbsize 3072 cgsize 2048 cgoffset 80 cgmask 0xfffffff8
csaddr 224 cssize 6144 shift 9 mask 0xfffffe00
cgrotor 0 fmod 0 ronly 0 clean 0x01
After newfs:
Endian big-endian magic 11954 time Sat Aug 7 19:42:45 1999
cylgrp dynamic inodes 4.4BSD fslevel 3
nbfree 252982 ndir 1 nifree 510717 nffree 12
ncg 285 ncyl 4549 size 2092290 blocks 2023869
bsize 8192 shift 13 mask 0xffffe000
fsize 1024 shift 10 mask 0xfffffc00
frag 8 shift 3 fsbtodb 1
cpg 16 bpg 920 fpg 7360 ipg 1792
minfree 5% optim time maxcontig 8 maxbpg 2048
rotdelay 0ms headswitch 0us trackseek 0us rps 60
ntrak 5 nsect 184 npsect 184 spc 920
symlinklen 60 trackskew 0 interleave 1 contigsumsize 8
nindir 2048 inopb 64 nspf 2
sblkno 16 cblkno 24 iblkno 32 dblkno 256
sbsize 2048 cgsize 2048 cgoffset 96 cgmask 0xfffffff8
csaddr 256 cssize 5120 shift 9 mask 0xfffffe00
cgrotor 0 fmod 0 ronly 0 clean 0x01
>How-To-Repeat:
Seems to have to do with formatting two partitions on a drive (maybe a large drive?) with Mkfs, though its very strange that the bogus info in one of those partitions is coming up as clean in fsck. I guess this could be a bug in Mkfs, fsck, and/or the kernel.
>Fix:
No real fix, just a workaround (use newfs if possible). I have no idea where the real problem lies.
>Audit-Trail:
>Unformatted: