From owner-freebsd-stable@FreeBSD.ORG Tue Jan 6 06:19:09 2009 Return-Path: Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A024A106564A for ; Tue, 6 Jan 2009 06:19:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.freebsd.org (Postfix) with ESMTP id 648DE8FC0C for ; Tue, 6 Jan 2009 06:19:09 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.14.3/8.14.3) with ESMTP id n065n7JH056597 for ; Mon, 5 Jan 2009 21:49:07 -0800 (PST) (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.14.3/8.14.3/Submit) id n065n7f2056596 for freebsd-stable@FreeBSD.ORG; Mon, 5 Jan 2009 21:49:07 -0800 (PST) (envelope-from david) Date: Mon, 5 Jan 2009 21:49:07 -0800 From: David Wolfskill To: freebsd-stable@FreeBSD.ORG Message-ID: <20090106054907.GP4100@albert.catwhisker.org> Mail-Followup-To: David Wolfskill , freebsd-stable@FreeBSD.ORG References: <20090102153455.GR4100@albert.catwhisker.org> <200901051923.n05JNrwt038325@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="1xCX6FQ4xS7iUK7H" Content-Disposition: inline In-Reply-To: <200901051923.n05JNrwt038325@lurza.secnetix.de> User-Agent: Mutt/1.4.2.3i Cc: Subject: Re: newfs(8) parameters from "dumpfs -m" have bad -s value? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Jan 2009 06:19:10 -0000 --1xCX6FQ4xS7iUK7H Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote: > ... > > pool10(7.1-RC1)[36] dumpfs -m /dev/da1s1d > > # newfs command for /dev/da1s1d (/dev/da1s1d) > > newfs -O 2 -U -a 8 -b 16384 -d 16384 -e 2048 -f 2048 -g 16384 -h 64 -m= 8 -o time -s 879031908 /dev/da1s1d=20 >=20 > This seems to be a bug in dumpfs(8). It simply prints > the value of the fs_size field of the superblock, which > is wrong. >=20 > The -s option of newfs(8) expects the available size in > sectors (i.e. 512 bytes), but the fs_size field contains > the size of the file system in 2KB units. This seems to > be the fragment size, but I'm not sure if this is just > coincidence (the docs state that it's the size in blocks, > but this is misleading because the blocksize is usually > different; the default is 16K). >=20 > So, dumpfs(8) needs to be fixed to perform the proper > calculations when printing the value for the -s option. > Unfortunately I'm not sufficiently much of a UFS guru > to offer a fix. My best guess would be to multiply the > fs_size value by the fragment size (measured in 512 byte > units), i.e. multiply by 4 in the most common case. > But I'm afraid the real solution is not that simple. Empirically, I find that -- at least in the case in question -- using the superblock's dsize, multiplied by 2, gets the correct result: Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da1s1d 1702753030 2744 1566530044 0% /b Extract from "ffsinfo -l 1": =3D=3D=3D=3D=3D END CYLINDER SUMMARY TOTAL =3D=3D=3D=3D=3D time ufs_time_t 1231206211 size int64_t 0x000000003464f664 dsize int64_t 0x0000000032bef983 csaddr ufs2_daddr_t 0x0000000000000bb8 A bit of messing about with dc(1): g1-35(6.4-S)[4] dc 16 i 32BEF983 2 * p 1702753030 g1-35(6.4-S)[5]=20 Then again, it isn't especially common in my experience to want a file system that occupies an amount of space different from the amount that is available for the file system (e.g., the partition size). So if that were wanted, providing a way to have dumpfs(8) merely make no claims whatsoever about or for the newfs(8) "-s" parameter might be adequate. My circumvention of piping the result through sed(1) accomplishes that, at some additional complexity and potential confusion. Peace, david --=20 David H. Wolfskill david@catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key. --1xCX6FQ4xS7iUK7H Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkli8NMACgkQmprOCmdXAD19hgCfUlo7/9N8Cdym7gil6uH1c23b mwUAnRRQYHy4cCqd37JkF9uwxVoi8j54 =DLji -----END PGP SIGNATURE----- --1xCX6FQ4xS7iUK7H--