>Number:         21123
>Category:       bin
>Synopsis:       UFS2 newfs(8) mismatch with disklabel(5)
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    bin-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Apr 13 08:00:00 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     Luke Mewburn
>Release:        NetBSD 1.6Q
>Organization:
The NetBSD Foundation
>Environment:
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 lukem@argo.mewburn.net:/var/obj/i386/usr/src/sys/arch/i386/compile/ARGO i386
Architecture: i386
Machine: i386
>Description:
	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
	sblock.fs_cpg field.

	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"


>How-To-Repeat:
	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",
		    sblock.fs_fpg, sizeof(sblock.fs_fpg),
		    pp->p_cpg, sizeof(pp->p_cpg));

	Run:
	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.


>Fix:
	No idea.

	[ 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. ]
>Release-Note:
>Audit-Trail:
>Unformatted: