From owner-freebsd-stable@FreeBSD.ORG Mon Jan 5 22:13:53 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 7344D106566C for ; Mon, 5 Jan 2009 22:13:53 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: from kiwi-computer.com (keira.kiwi-computer.com [63.224.10.3]) by mx1.freebsd.org (Postfix) with SMTP id 075B98FC08 for ; Mon, 5 Jan 2009 22:13:52 +0000 (UTC) (envelope-from rick@kiwi-computer.com) Received: (qmail 37597 invoked by uid 2001); 5 Jan 2009 22:13:52 -0000 Date: Mon, 5 Jan 2009 16:13:52 -0600 From: "Rick C. Petty" To: freebsd-stable@FreeBSD.ORG, david@catwhisker.org Message-ID: <20090105221352.GB35524@keira.kiwi-computer.com> References: <20090102153455.GR4100@albert.catwhisker.org> <200901051923.n05JNrwt038325@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 Reply-To: rick-freebsd2008@kiwi-computer.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Jan 2009 22:13:53 -0000 On Mon, Jan 05, 2009 at 08:23:53PM +0100, Oliver Fromme wrote: > > 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. > > 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 This *is* the fragment size. UFS/FFS uses the plain term "block" to mean the fragment size. All blocks are indexed with this number, unlike "block size" which is almost always 8 fragments ("blocks"). Confusing. > 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. The sector size and filesystem size parameters in newfs are remnants. Everything is converted to number of media sectors (sector size as specified by the device). So one could assume for dumpfs to always use 512, since it's rarely different, and multiply fs_size by fs_fsize and divide by 512, and then output "-S 512". Better yet would be to add a parameter ("-z" perhaps) to newfs(8) to accept number of bytes instead of multiples of sectorsize. I would be willing to write up patches for dumpfs and newfs to both add the raw byte size and the 512-byte sector size handling to correct said mistake, unless someone else would rather. -- Rick C. Petty