From kurin@delete.org  Wed Jan 24 21:09:03 2007
Return-Path: <kurin@delete.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52])
	by hub.freebsd.org (Postfix) with ESMTP id B305016A401
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 24 Jan 2007 21:09:03 +0000 (UTC)
	(envelope-from kurin@delete.org)
Received: from cobalt.delete.org (cobalt.delete.org [198.177.254.162])
	by mx1.freebsd.org (Postfix) with ESMTP id 91C5B13C43E
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 24 Jan 2007 21:09:03 +0000 (UTC)
	(envelope-from kurin@delete.org)
Received: from localhost (localhost.delete.org [127.0.0.1])
	by cobalt.delete.org (Postfix) with ESMTP id 4252E84429
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 24 Jan 2007 15:38:09 -0500 (EST)
Received: from cobalt.delete.org ([127.0.0.1])
	by localhost (cobalt.delete.org [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id dMZq-V1n--1u for <FreeBSD-gnats-submit@freebsd.org>;
	Wed, 24 Jan 2007 15:37:39 -0500 (EST)
Received: by cobalt.delete.org (Postfix, from userid 1028)
	id C87DD8446A; Wed, 24 Jan 2007 15:37:39 -0500 (EST)
Message-Id: <20070124203739.C87DD8446A@cobalt.delete.org>
Date: Wed, 24 Jan 2007 15:37:39 -0500 (EST)
From: Toby Burress <kurin@delete.org>
Reply-To: Toby Burress <kurin@delete.org>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: dumpfs(8) lists wrong file system size [PATCH?]
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         108320
>Category:       bin
>Synopsis:       dumpfs(8) lists wrong file system size [PATCH?]
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 24 21:10:18 GMT 2007
>Closed-Date:    Thu Jan 25 13:30:33 GMT 2007
>Last-Modified:  Fri Jan 26 04:20:19 GMT 2007
>Originator:     Toby Burress
>Release:        FreeBSD 6.1-RELEASE amd64
>Organization:
>Environment:
/usr/src/sbin/dumpfs
>Description:
When using dumpfs(8) to check the file system size, and in particular
dumpfs -m to find a command that creates the file system, the size
listed is smaller than the actual size of the file system.
>How-To-Repeat:
Run the following shell script (without warranty, etc etc, it doesn't
do anything bad but don't blame me if your power supply explodes)
and note the df lines.

#!/bin/sh
touch testfile
FS=`mdconfig -a -t vnode -f testfile -s 200M`
fdisk -I /dev/${FS}
bsdlabel -w /dev/${FS}s1
newfs /dev/${FS}s1a
dumpfs -m /dev/${FS}s1a > newfsfile
mount /dev/${FS}s1a /mnt
df -h /mnt
umount /dev/${FS}s1a
sh newfsfile
mount /dev/${FS}s1a /mnt
df -h /mnt
umount /dev/${FS}s1a
mdconfig -d -u ${FS}
rm testfile newfsfile
>Fix:

In my case the reported file system size is 4 times too small.  This
just happens to be the size of the "ncg" parameter.  So I think a
fix might be:

--- dumpfs.c.old        Fri Apr  9 15:58:27 2004
+++ dumpfs.c    Wed Jan 24 14:57:19 2007
@@ -135,7 +135,7 @@
                printf("superblock location\t%jd\tid\t[ %x %x ]\n",
                    (intmax_t)afs.fs_sblockloc, afs.fs_id[0], afs.fs_id[1]);
                printf("ncg\t%d\tsize\t%jd\tblocks\t%jd\n",
-                   afs.fs_ncg, (intmax_t)fssize, (intmax_t)afs.fs_dsize);
+                   afs.fs_ncg, (intmax_t)fssize * afs.fs_ncg, (intmax_t)afs.fs_dsize);
                break;
        case 1:
                fssize = afs.fs_old_size;
@@ -144,7 +144,7 @@
                    afs.fs_magic, ctime(&fstime));
                printf("id\t[ %x %x ]\n", afs.fs_id[0], afs.fs_id[1]);
                printf("ncg\t%d\tsize\t%jd\tblocks\t%jd\n",
-                   afs.fs_ncg, (intmax_t)fssize, (intmax_t)afs.fs_dsize);
+                   afs.fs_ncg, (intmax_t)fssize * afs.fs_ncg, (intmax_t)afs.fs_dsize);
                break;
        default:
                goto err;
@@ -367,7 +367,7 @@
                break;
        }
        /* -p..r unimplemented */
-       printf("-s %jd ", (intmax_t)fs->fs_size);
+       printf("-s %jd ", (intmax_t)fs->fs_size * fs->fs_ncg);
        printf("%s ", disk.d_name);
        printf("\n");

Of course, long experience has taught me that I never know what I'm
talking about, so even though this gives the right answers, maybe
the fix is somewhere else?  Either way, dumpfs is wrong and needs
to be fixed.
>Release-Note:
>Audit-Trail:

From: Bruce Evans <bde@zeta.org.au>
To: Toby Burress <kurin@delete.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, freebsd-bugs@FreeBSD.org
Subject: Re: bin/108320: dumpfs(8) lists wrong file system size [PATCH?]
Date: Thu, 25 Jan 2007 18:56:23 +1100 (EST)

 On Wed, 24 Jan 2007, Toby Burress wrote:
 
 >> Description:
 > When using dumpfs(8) to check the file system size, and in particular
 > dumpfs -m to find a command that creates the file system, the size
 > listed is smaller than the actual size of the file system.
 
 No, dumpfs is correct.  It just reports the size being used ffs.  The
 size is in blocks (frags).  This size is reported by dumpfs as `fsize`.
 
 Bruce
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Thu Jan 25 13:30:05 UTC 2007 
State-Changed-Why:  
bde claims that this is the proper behavior. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=108320 

From: Bruce Evans <bde@zeta.org.au>
To: Toby Burress <kurin@delete.org>
Cc: freebsd-gnats-submit@freebsd.org, jmallett@freebsd.org
Subject: Re: bin/108320: dumpfs(8) lists wrong file system size [PATCH?]
Date: Fri, 26 Jan 2007 15:15:32 +1100 (EST)

 On Thu, 25 Jan 2007, Toby Burress wrote:
 
 > On Thu, Jan 25, 2007 at 06:56:23PM +1100, Bruce Evans wrote:
 >> On Wed, 24 Jan 2007, Toby Burress wrote:
 >>
 >>>> Description:
 >>> When using dumpfs(8) to check the file system size, and in particular
 >>> dumpfs -m to find a command that creates the file system, the size
 >>> listed is smaller than the actual size of the file system.
 >>
 >> No, dumpfs is correct.  It just reports the size being used ffs.  The
 >> size is in blocks (frags).  This size is reported by dumpfs as `fsize`.
 >
 > If dumpfs is correct, then why are the file systems created with
 > the command `dumpfs -m` smaller than the original file systems?
 
 Sorry, I didn't notice that you wanted -m to work (I didn't know that
 -m existed).  -m just never actually worked, except accidentally when
 the frag size equals the sector size.  It prints "-s <size in frags>"
 but newfs's -s arg takes a size in sectors.  These sizes normally
 differ by a factor of 4, since the frag size defaults to 2048 and most
 disks have a sector size of 512.  Another bug in -m is that it conflicts
 with NetBSD's -m.
 
 It's bogus for newfs to take a size in sectors.  The sector size is
 not recorded in struct fs or used by ffs.  It just needs to be a divisor
 of the frag size (and maybe a power of 2).  newfs normally determines
 it using a disk ioctl and only uses it to scale the sizes.  This default
 can can be overridden by specifying the size using newfs -S or -T.
 Another bug: -T apparently clobbers any setting by -S, even if -S is
 after -T on the command line.
 
 Possible fixes:
 - use a disk ioctl in dumpfs, so as to reverse the conversion of units
    that newfs will do.  I don't like this.  It doesn't work if the file
    system is a copy of a disk in a regular file.
 - use a fake sector size: print "-S <frag size>" in dumpfs.  This should
    give identical results since ffs doesn't actually use the sector size,
    except newfs randomizes some things in the new file system.  The
    undocumented -R flag can be used to avoid the randomness for testing.
 
 Bruce
>Unformatted:
