From owner-freebsd-stable@FreeBSD.ORG Tue Jan 6 06:51:22 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 EEF92106566C for ; Tue, 6 Jan 2009 06:51:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.16.84]) by mx1.freebsd.org (Postfix) with ESMTP id A54758FC14 for ; Tue, 6 Jan 2009 06:51:22 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by kabab.cs.huji.ac.il with esmtp id 1LK5mY-0008AF-R5; Tue, 06 Jan 2009 08:51:18 +0200 X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.2 To: rick-freebsd2008@kiwi-computer.com In-reply-to: <20090105221352.GB35524@keira.kiwi-computer.com> References: <20090102153455.GR4100@albert.catwhisker.org> <200901051923.n05JNrwt038325@lurza.secnetix.de> <20090105221352.GB35524@keira.kiwi-computer.com> Comments: In-reply-to "Rick C. Petty" message dated "Mon, 05 Jan 2009 16:13:52 -0600." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 06 Jan 2009 08:51:18 +0200 From: Danny Braniss Message-ID: Cc: freebsd-stable@FreeBSD.ORG 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:51:23 -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". > don't assume 512, in the iscsi world I have seen all kinds of sector sizes, making it a PITA to get things right. > 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 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >