Subject: bin/21123: UFS2 newfs(8) mismatch with disklabel(5)
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 04/14/2003 00:59:39
>Synopsis: UFS2 newfs(8) mismatch with disklabel(5)
>Arrival-Date: Sun Apr 13 08:00:00 PDT 2003
>Originator: Luke Mewburn
>Release: NetBSD 1.6Q
The NetBSD Foundation
System: NetBSD argo.mewburn.net 1.6Q NetBSD 1.6Q (ARGO from GENERIC-$Revision: 1.546 $) #0: Wed Apr 2 09:17:18 EST 2003 email@example.com:/var/obj/i386/usr/src/sys/arch/i386/compile/ARGO i386
Before newfs was modified to support UFS2 in mkfs.c rev 1.68,
the partition table's "p_cpg" field was set to the calculated
In mkfs.c 1.68, UFS2 support was added, and the code was
significantly changed. newfs now sets the partition's p_cpg
field to the sblock.fs_fpg. (Note: _f_pg, not _c_pg).
The problem is that (struct fs).fs_fpg is an int32_t, and
(struct partition).p_cpg is an int16_t, and the former can
often contain values that won't fit in the latter. This
means that the disklabel may now contain a "cpg" [*] field
which is different to the "fpg" field which dumpfs will
report for the file system.
This is immensely confusing, especially in light of the recent
lossage that many people have had since the UFS2 import...
[*] which is mislabelled and should now be "fpg"
Modify newfs to print out the fs_fpg and p_cpg fields at the
end of mkfs.c::mkfs(). I used:
printf("sblock.fs_fpg %d (%d), pp->p_cpg %d (%d)\n",
newfs -b 16k -f 2k -i 16k -s 2g -F /var/tmp/image
/var/tmp/image: 2048.0MB (4194304 sectors) block size 16384, fragment size 2048
using 11 cylinder groups of 202.12MB, 12936 blks, 13056 inodes.
super-block backups (for fsck -b #) at:
32, 413984, 827936, 1241888, 1655840, 2069792, 2483744, 2897696,
3311648, 3725600, 4139552,
sblock.fs_fpg 103488 (4), pp->p_cpg 37952 (2)
Run dumpfs on the image and notice that fpg is 103488.
If you'd done this on a real disk, the partition entry
would have a cpg field of 37952.
[ I can't easily find any documentation about why the
(struct partition).p_cpg was changed from storing the
(now obsolete) fs_old_cpg field to the fs_fpg field.
This could result in an incorrect p_cpg field due to integer
overflow as descriped above. ]