From owner-freebsd-current@FreeBSD.ORG Thu Feb 21 12:32:08 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5A6DB16A404; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 1137F13C468; Thu, 21 Feb 2008 12:32:08 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B5F9643CC85; Thu, 21 Feb 2008 14:32:06 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNNHte2ZE-y4; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 4905E43CAD5; Thu, 21 Feb 2008 14:32:06 +0200 (EET) Message-ID: <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 14:31:53 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> In-Reply-To: <47B81D07.7090208@icyb.net.ua> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 12:32:08 -0000 on 17/02/2008 13:39 Andriy Gapon said the following: > Should newfs_msdos be able to work on "whole" cdX/acdX device ? > [ufs/ffs] newfs can do it. > But with newfs_msdos I had to run disklabel first and then I could > create a filesystem on cdXa, but I couldn't do it on the whole disk. It seems that the reason for this newfs_msdos behavior is in the following lines: if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) errx(1, "Cannot get sector size, %s", strerror(errno)); if (ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) errx(1, "Cannot get number of sectors, %s", strerror(errno)); if (ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks)== -1) errx(1, "Cannot get number of heads, %s", strerror(errno)); While a failure to get sector size is a serious situation indeed, number of sectors per track and number of heads are just relics of the past and are not applicable to all types of should-be-supported media. What's even more funny is that those values can be set via command line options and in that case values from ioctl are not used at all. Because those numbers are used by msdosfs on-disk structures we have to provide some reasonable values for them even if they are meaningless with respect to physical media organization. An example of simple calculations can be found in bsdlabel.c. I see two approaches: 1) fake those properties in device drivers, primarily cd(4) and acd(4); benefit: this can help other utilities besides newfs_msdos 2) fake those properties in newfs_msdof; benefit: this would help with other physical devices that can host FAT; Or maybe do both. -- Andriy Gapon