From owner-freebsd-geom@FreeBSD.ORG Sun Feb 17 11:39:56 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8F06616A418; Sun, 17 Feb 2008 11:39:56 +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 4701C13C448; Sun, 17 Feb 2008 11:39:56 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 035A743E0A7; Sun, 17 Feb 2008 13:39:55 +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 10027) with ESMTP id 8kNWJUcDSl5H; Sun, 17 Feb 2008 13:39:54 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 6393443E068; Sun, 17 Feb 2008 13:39:54 +0200 (EET) Message-ID: <47B81D07.7090208@icyb.net.ua> Date: Sun, 17 Feb 2008 13:39:51 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-geom@freebsd.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: Subject: newfs_msdos and dvd-ram X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 11:39:56 -0000 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. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Mon Feb 18 11:07:08 2008 Return-Path: Delivered-To: freebsd-geom@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C7F3C16A417 for ; Mon, 18 Feb 2008 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id B751413C448 for ; Mon, 18 Feb 2008 11:07:08 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m1IB784v039394 for ; Mon, 18 Feb 2008 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.2/8.14.1/Submit) id m1IB78gg039390 for freebsd-geom@FreeBSD.org; Mon, 18 Feb 2008 11:07:08 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 18 Feb 2008 11:07:08 GMT Message-Id: <200802181107.m1IB78gg039390@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-geom@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-geom@FreeBSD.org X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 11:07:08 -0000 Current FreeBSD problem reports Critical problems Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/73177 geom kldload geom_* causes panic due to memory exhaustion o kern/76538 geom [gbde] nfs-write on gbde partition stalls and continue o kern/83464 geom [geom] [patch] Unhandled malloc failures within libgeo o kern/84556 geom [geom] GBDE-encrypted swap causes panic at shutdown o kern/87544 geom [gbde] mmaping large files on a gbde filesystem deadlo s kern/89102 geom [geom_vfs] [panic] panic when forced unmount FS from u o bin/90093 geom fdisk(8) incapable of altering in-core geometry o kern/90582 geom [geom_mirror] [panic] Restore cause panic string (ffs_ o kern/98034 geom [geom] dereference of NULL pointer in acd_geom_detach o kern/104389 geom [geom] [patch] sys/geom/geom_dump.c doesn't encode XML o kern/113419 geom [geom] geom fox multipathing not failing back o kern/113957 geom [gmirror] gmirror is intermittently reporting a degrad o kern/115572 geom [gbde] [patch] gbde partitions fail at 28bit/48bit LBA o kern/120021 geom net-p2p/qbittorrent crashes system when it works thoug o kern/120231 geom [geom] GEOM_CONCAT error adding second drive 15 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- o bin/78131 geom gbde "destroy" not working. o kern/79251 geom [2TB] newfs fails on 2.6TB gbde device o kern/94632 geom [geom] Kernel output resets input while GELI asks for f kern/105390 geom [geli] filesystem on a md backed by sparse file with s o kern/107707 geom [geom] [patch] [request] add new class geom_xbox360 to p bin/110705 geom gmirror control utility does not exit with correct exi o kern/113837 geom [geom] unable to access 1024 sector size storage o kern/113885 geom [geom] [patch] improved gmirror balance algorithm o kern/114532 geom [geom] GEOM_MIRROR shows up in kldstat even if compile o kern/115547 geom [geom] [patch] [request] let GEOM Eli get password fro o kern/119743 geom [geom] geom label for cds is keeped after dismount and o kern/120044 geom [msdosfs] [geom] incorrect MSDOSFS label fries adminis f kern/120091 geom [geom] [geli] [gjournal] geli does not prompt for pass 13 problems total. From owner-freebsd-geom@FreeBSD.ORG Mon Feb 18 21:23:29 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9E10016A41B for ; Mon, 18 Feb 2008 21:23:29 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.233]) by mx1.freebsd.org (Postfix) with ESMTP id 1163013C44B for ; Mon, 18 Feb 2008 21:23:28 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: by hu-out-0506.google.com with SMTP id 28so1051194hub.8 for ; Mon, 18 Feb 2008 13:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; bh=jQUQFQy9eaxQwyj9oQ68JaDTegohXEJu/ZYFt1kPwGs=; b=GDnk8f3hCRTJhOAq5SJRUSwKzfHWgF0Ax9v43P4Rn4W/d7BV5F9OEwVkOAPMEIELnbl8dAdi5+Nhgn1kQpx7a5dt3iEaaAmG3W0xifS1eiz5lUyUevjvpx/qJ6RCz4O5W8faLcy0kLB/W5Yt5dEoDnirGD5oAgXZRn5eK+GvF98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; b=JlamrH9Ux4T/G2/1mD4YPJoHATICa4R1nqKdNDsDj1+5frC8iFxS2bCiHcnaX8HniR9MH2c5vTf74b+LFXZFuv1vm6BBFLdR1ujfHSR5lbwl+z8ZalQnx1FRoGDgtyZZxbAllH4baGZDWYYmTC8hdU4NqB9fllalzDy/tEk0C6Y= Received: by 10.82.181.7 with SMTP id d7mr12694382buf.8.1203369806046; Mon, 18 Feb 2008 13:23:26 -0800 (PST) Received: from ?81.200.127.6? ( [81.200.127.6]) by mx.google.com with ESMTPS id c24sm12876559ika.10.2008.02.18.13.23.23 (version=SSLv3 cipher=OTHER); Mon, 18 Feb 2008 13:23:24 -0800 (PST) Date: Tue, 19 Feb 2008 00:10:52 +0300 From: Michael Monashev Organization: SoftSearch.ru X-Priority: 3 (Normal) Message-ID: <15910342939.20080219001052@gmail.com> To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Synchronization request failed (error=1) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Monashev List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 21:23:29 -0000 Hi. I did: >gmirror forget root >gmirror list root Geom name: root State: COMPLETE Components: 1 Balance: split Slice: 4096 Flags: NONE GenID: 7 SyncID: 1 ID: 1926374852 Providers: 1. Name: mirror/root Mediasize: 134217216 (128M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: da1s1a Mediasize: 134217728 (128M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 7 SyncID: 1 ID: 600760959 >gmirror insert root /dev/da0s1a and got nothing: >gmirror list root Geom name: root State: COMPLETE Components: 1 Balance: split Slice: 4096 Flags: NONE GenID: 7 SyncID: 1 ID: 1926374852 Providers: 1. Name: mirror/root Mediasize: 134217216 (128M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: da1s1a Mediasize: 134217728 (128M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 7 SyncID: 1 ID: 600760959 and some errors in /var/log/messages: Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a detected. Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Synchronization request failed (error=1). da0s1a[WRITE(offset=0, length=131072)] Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a disconnected. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a stopped. How to correct this error and insert da0s1a into the root? >bsdlabel /dev/da0s1a # /dev/da0s1a: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 63 4.2BSD 2048 16384 16392 b: 33554432 262207 swap c: 976768002 63 unused 0 0 # "raw" part, don't edit d: 524288 33816639 4.2BSD 2048 16384 32776 e: 41943040 34340927 4.2BSD 2048 16384 28528 f: 4194304 76283967 4.2BSD 2048 16384 28528 g: 41943040 80478271 4.2BSD 2048 16384 28528 h: 854346754 122421311 4.2BSD 2048 16384 28528 partition a: partition extends past end of unit partition b: offset past end of unit partition b: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit partition g: offset past end of unit partition g: partition extends past end of unit partition h: offset past end of unit partition h: partition extends past end of unit >bsdlabel /dev/da1s1a # /dev/da1s1a: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 63 4.2BSD 0 0 0 c: 46781217 63 unused 0 0 # "raw" part, don't edit d: 524288 262207 4.2BSD 0 0 0 e: 41800481 4980799 4.2BSD 0 0 0 f: 4194304 786495 4.2BSD 0 0 0 partition a: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit -- Michael From owner-freebsd-geom@FreeBSD.ORG Mon Feb 18 21:37:10 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EBACA16A418 for ; Mon, 18 Feb 2008 21:37:09 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.187]) by mx1.freebsd.org (Postfix) with ESMTP id D41D613C4D3 for ; Mon, 18 Feb 2008 21:37:08 +0000 (UTC) (envelope-from softsearch@gmail.com) Received: by nf-out-0910.google.com with SMTP id b2so639030nfb.33 for ; Mon, 18 Feb 2008 13:37:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; bh=jQUQFQy9eaxQwyj9oQ68JaDTegohXEJu/ZYFt1kPwGs=; b=BYhyAQA0OsrMYWGOXxw/tygZMlJ46IPF6sWvv4mWgNq/xMyzxmaD5FrTR6mbuPn3h0sivkBM4xiJDHQG//3CMEX8xZs0Kt0TE1fCIFYYR8XYFljYr4IRlg9Oe8WQeuQyBDStOaB0mWR2i7fc497qYNg6rBDn0opQGIPKa3cJP1o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:reply-to:organization:x-priority:message-id:to:subject:mime-version:content-type:content-transfer-encoding; b=JlamrH9Ux4T/G2/1mD4YPJoHATICa4R1nqKdNDsDj1+5frC8iFxS2bCiHcnaX8HniR9MH2c5vTf74b+LFXZFuv1vm6BBFLdR1ujfHSR5lbwl+z8ZalQnx1FRoGDgtyZZxbAllH4baGZDWYYmTC8hdU4NqB9fllalzDy/tEk0C6Y= Received: by 10.78.189.5 with SMTP id m5mr10004361huf.16.1203369078498; Mon, 18 Feb 2008 13:11:18 -0800 (PST) Received: from ?81.200.127.6? ( [81.200.127.6]) by mx.google.com with ESMTPS id z33sm12879993ikz.0.2008.02.18.13.11.14 (version=SSLv3 cipher=OTHER); Mon, 18 Feb 2008 13:11:17 -0800 (PST) Date: Tue, 19 Feb 2008 00:10:52 +0300 From: Michael Monashev Organization: SoftSearch.ru X-Priority: 3 (Normal) Message-ID: <15910342939.20080219001052@gmail.com> To: freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Synchronization request failed (error=1) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Monashev List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 21:37:10 -0000 Hi. I did: >gmirror forget root >gmirror list root Geom name: root State: COMPLETE Components: 1 Balance: split Slice: 4096 Flags: NONE GenID: 7 SyncID: 1 ID: 1926374852 Providers: 1. Name: mirror/root Mediasize: 134217216 (128M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: da1s1a Mediasize: 134217728 (128M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 7 SyncID: 1 ID: 600760959 >gmirror insert root /dev/da0s1a and got nothing: >gmirror list root Geom name: root State: COMPLETE Components: 1 Balance: split Slice: 4096 Flags: NONE GenID: 7 SyncID: 1 ID: 1926374852 Providers: 1. Name: mirror/root Mediasize: 134217216 (128M) Sectorsize: 512 Mode: r1w1e1 Consumers: 1. Name: da1s1a Mediasize: 134217728 (128M) Sectorsize: 512 Mode: r1w1e1 State: ACTIVE Priority: 0 Flags: NONE GenID: 7 SyncID: 1 ID: 600760959 and some errors in /var/log/messages: Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a detected. Feb 17 18:17:03 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Synchronization request failed (error=1). da0s1a[WRITE(offset=0, length=131072)] Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: provider da0s1a disconnected. Feb 17 18:17:05 host2 kernel: GEOM_MIRROR: Device root: rebuilding provider da0s1a stopped. How to correct this error and insert da0s1a into the root? >bsdlabel /dev/da0s1a # /dev/da0s1a: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 63 4.2BSD 2048 16384 16392 b: 33554432 262207 swap c: 976768002 63 unused 0 0 # "raw" part, don't edit d: 524288 33816639 4.2BSD 2048 16384 32776 e: 41943040 34340927 4.2BSD 2048 16384 28528 f: 4194304 76283967 4.2BSD 2048 16384 28528 g: 41943040 80478271 4.2BSD 2048 16384 28528 h: 854346754 122421311 4.2BSD 2048 16384 28528 partition a: partition extends past end of unit partition b: offset past end of unit partition b: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit partition g: offset past end of unit partition g: partition extends past end of unit partition h: offset past end of unit partition h: partition extends past end of unit >bsdlabel /dev/da1s1a # /dev/da1s1a: 8 partitions: # size offset fstype [fsize bsize bps/cpg] a: 262144 63 4.2BSD 0 0 0 c: 46781217 63 unused 0 0 # "raw" part, don't edit d: 524288 262207 4.2BSD 0 0 0 e: 41800481 4980799 4.2BSD 0 0 0 f: 4194304 786495 4.2BSD 0 0 0 partition a: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: partition c doesn't cover the whole unit! bsdlabel: An incorrect partition c may cause problems for standard system utilities partition d: offset past end of unit partition d: partition extends past end of unit partition e: offset past end of unit partition e: partition extends past end of unit partition f: offset past end of unit partition f: partition extends past end of unit -- Michael From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 12:32:08 2008 Return-Path: Delivered-To: freebsd-geom@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-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations 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 From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 14:37:38 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 99AD716A400; Thu, 21 Feb 2008 14:37:38 +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 E9F9C13C448; Thu, 21 Feb 2008 14:37:37 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id B3CDC43D995; Thu, 21 Feb 2008 16:37:36 +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 qMIl64jZnwjr; Thu, 21 Feb 2008 16:37:36 +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 2A1C543D699; Thu, 21 Feb 2008 16:37:36 +0200 (EET) Message-ID: <47BD8CAF.9090908@icyb.net.ua> Date: Thu, 21 Feb 2008 16:37:35 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20080123) MIME-Version: 1.0 To: Bruce Evans References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> In-Reply-To: <20080222005213.W5655@besplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:37:38 -0000 on 21/02/2008 16:27 Bruce Evans said the following: > On Thu, 21 Feb 2008, Andriy Gapon wrote: > >> 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. > > Also, it needs the BIOS geometry, but has been broken to ask for, and Bruce, you lost me after this. I understand that you speak about a general case, but is there a "BIOS geometry" for DVD-RAM disk ? Would any information about physical structure of DVD-RAM disk prove useful for FAT on it ? I thought that all those CHS parameters were useful only in times when CHS was the disk access mode (and maybe for performance optimizations). I don't see how those parameters can be of any real use now. P.S. I must declare that I know zero about FAT. -- Andriy Gapon From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 14:56:19 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A98816A406; Thu, 21 Feb 2008 14:56:19 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.freebsd.org (Postfix) with ESMTP id D956213C4E7; Thu, 21 Feb 2008 14:56:18 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from c220-239-252-11.carlnfd3.nsw.optusnet.com.au (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail16.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LEuEZS016153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:56:16 +1100 Date: Fri, 22 Feb 2008 01:56:14 +1100 (EST) From: Bruce Evans X-X-Sender: bde@delplex.bde.org To: Andriy Gapon In-Reply-To: <47BD8CAF.9090908@icyb.net.ua> Message-ID: <20080222014649.X29998@delplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> <20080222005213.W5655@besplex.bde.org> <47BD8CAF.9090908@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, Bruce Evans , freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 14:56:19 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > on 21/02/2008 16:27 Bruce Evans said the following: >> On Thu, 21 Feb 2008, Andriy Gapon wrote: >> >>> 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. >> >> Also, it needs the BIOS geometry, but has been broken to ask for, and > you lost me after this. I understand that you speak about a general > case, but is there a "BIOS geometry" for DVD-RAM disk ? Probably not. Docs say "for interrupt 0x13... only relevant for media that have a geometry". > Would any information about physical structure of DVD-RAM disk prove > useful for FAT on it ? The geometry fields might only be used by the bootstrap even on media that has a geometry. Since newfs_msdos writes a dummy bootstrap that doesn't support media accesses, we don't have to initialize them for that. > I thought that all those CHS parameters were useful only in times when > CHS was the disk access mode (and maybe for performance optimizations). > I don't see how those parameters can be of any real use now. That is probably correct, but since we don't control all uses of these fields, we should try to initialize them correctly. Bruce From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 20:18:36 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E29C916A404; Thu, 21 Feb 2008 20:18:36 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from fallbackmx07.syd.optusnet.com.au (fallbackmx07.syd.optusnet.com.au [211.29.132.9]) by mx1.freebsd.org (Postfix) with ESMTP id 45AC313C474; Thu, 21 Feb 2008 20:18:34 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by fallbackmx07.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LERYCE024929; Fri, 22 Feb 2008 01:27:34 +1100 Received: from besplex.bde.org (c220-239-252-11.carlnfd3.nsw.optusnet.com.au [220.239.252.11]) by mail01.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id m1LERONJ022421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:27:25 +1100 Date: Fri, 22 Feb 2008 01:27:24 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Andriy Gapon In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Message-ID: <20080222005213.W5655@besplex.bde.org> References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 20:18:37 -0000 On Thu, 21 Feb 2008, Andriy Gapon wrote: > 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. Also, it needs the BIOS geometry, but has been broken to ask for, and normally use, the firmware geometry. Setting the values on the command line is a fairly easy workaround. It's actually better for the ioctls and make you give the correct parameters on the command line instead of succeeding and giving wrong values. The "hidden sectors" calculation has also been broken. This can be fixed by setting the value on the command line too. The correct setting is normally or always the offset of the partition in sectors. > 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. Those don't give the BIOS geometry, which isn't a problem in disklabel since disklabel doesn't need any geometry, but newfs_msdos, fsck_msdosfs fdisk and sysinstall need more. newfs_msdos, fdisk and sysinstall used to read values from the label (including the label for the whole disk), and these parameters used to be set to the kernel's best guess at the BIOS geometry, so that everything saw a consistent geometry. fsck_msdosfs has never missed not being able to determine the correct values, since it has never checked or fixed the values. WinXP silently fixes at least "hidden sectors" at boot time. > 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. This won't help for other utilities that need the BIOS geometry. I use the following fixes in newfs_msdos. They reduce mainly to complaints about the breakage and trying alternative ioctls so that the same binary has some chance of working on new and old versions of FreeBSD. I didn't restore the DIOCGSLICEINFO ioctl or the code that uses it to determine "hidden sectors". Another possible fix for this is to use the NetBSD version, which last time I looked was just the FreeBSD version with all the unportable ioctls and code ifdefed out. The 2004/09/24 version of it reduces to assuming that the correct (BIOS) values are in the label. It attempts to calculate "hidden sectors" where FreeBSD now sets it to 0. I think this works iff the offsets in the label are absolute. FreeBSD used to virtualize these offsets to well to be 0-based, and I think these offsets can be physically 0-based now. It is necessary to know the base, which my unimplemented DICOMEDIAOFFSET ioctl returns. % Index: newfs_msdos.c % =================================================================== % RCS file: /home/ncvs/src/sbin/newfs_msdos/newfs_msdos.c,v % retrieving revision 1.20 % diff -u -2 -r1.20 newfs_msdos.c % --- newfs_msdos.c 17 Feb 2004 02:02:18 -0000 1.20 % +++ newfs_msdos.c 22 Apr 2004 10:36:28 -0000 % @@ -711,56 +711,165 @@ % struct bpb *bpb) % { % - struct disklabel *lp, dlp; % - struct fd_type type; % - off_t ms, hs; % - % - lp = NULL; % - % - /* If the user specified a disk type, try to use that */ % + struct fd_type fdtype; % + struct disklabel label, *lp; % + off_t ms, mo; % + u_int heads, secpertrack, secsize; % + u_int cruftmap, fwheads, fwsectors; % + % +#define NO_MEDIASIZE (1 << 0) % +#define NO_MEDIAOFFSET (1 << 1) % +#define NO_SECTORSIZE (1 << 2) % +#define NO_HEADS (1 << 3) % +#define NO_SECPERTRACK (1 << 4) % +#define NO_FWHEADS (1 << 5) % +#define NO_FWSECTORS (1 << 6) % +#define NO_FDTYPE (1 << 7) % +#define NO_LABEL (1 << 8) % + cruftmap = 0; % + % + /* First, try to use only the "right" primitive ioctls. */ % + if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % + cruftmap |= NO_MEDIASIZE; % +#ifdef DIOCGMEDIAOFFSET % + if (ioctl(fd, DIOCGMEDIAOFFSET, &mo) == -1) % +#endif % + cruftmap |= NO_MEDIAOFFSET; % + if (ioctl(fd, DIOCGSECTORSIZE, &secsize) == -1) % + cruftmap |= NO_SECTORSIZE; % +#ifdef DIOCGHEADS % + if (ioctl(fd, DIOCGHEADS, &nheads)== -1) % +#endif % + cruftmap |= NO_HEADS; % +#ifdef DIOCGSECPERTRACK % + if (ioctl(fd, DIOCGSECPERTRACK, &secpertrack) == -1) % +#endif % + cruftmap |= NO_SECPERTRACK; % + % + /* Prepare fallbacks. */ % + if (ioctl(fd, DIOCGFWHEADS, &fwheads) == -1) % + cruftmap |= NO_FWHEADS; % + if (ioctl(fd, DIOCGFWSECTORS, &fwsectors) == -1) % + cruftmap |= NO_FWSECTORS; % + if (ioctl(fd, FD_GTYPE, &fdtype) == -1) % + cruftmap |= NO_FDTYPE; % if (dtype != NULL) { % lp = getdiskbyname(dtype); % - hs = 0; % + if (lp == NULL) % + errx(1, "%s: unknown disk type", dtype); % + label = *lp; % + } else if (ioctl(fd, DIOCGDINFO, &label) == -1) % + cruftmap |= NO_LABEL; % + % + /* % + * Preliminary fallback for firmware heads and sectors: use floppy ones. % + * Non-GEOM drivers don't have DIOCGFWHEADS or DIOCGFWSECTORS, and % + * we know how to recover for the fd driver only. We could get the % + * media size and sector size from fdtype too, but shouldn't need them. % + */ % + if ((cruftmap & (NO_FWHEADS | NO_FDTYPE)) == NO_FWHEADS) { % + fwheads = fdtype.heads; % + cruftmap &= ~NO_FWHEADS; % } % - % - /* Maybe it's a floppy drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGMEDIASIZE, &ms) == -1) % - errx(1, "Cannot get disk size, %s", strerror(errno)); % - if (ioctl(fd, FD_GTYPE, &type) != -1) { % - dlp.d_secsize = 128 << type.secsize; % - dlp.d_nsectors = type.sectrac; % - dlp.d_ntracks = type.heads; % - dlp.d_secperunit = ms / dlp.d_secsize; % - lp = &dlp; % - hs = 0; % - } % + if ((cruftmap & (NO_FWSECTORS | NO_FDTYPE)) == NO_FWSECTORS) { % + fwsectors = fdtype.sectrac; % + cruftmap &= ~NO_FWSECTORS; % } % % - /* Maybe it's a fixed drive */ % - if (lp == NULL) { % - if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { % - 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)); % - dlp.d_secperunit = ms / dlp.d_secsize; % + /* Prefer to fall back to label info. */ % + if ((cruftmap & (NO_MEDIASIZE | NO_LABEL)) == NO_MEDIASIZE) { % + /* This shouldn't be needed. */ % + ms = label.d_secperunit * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIASIZE; % + } % + if (cruftmap & NO_MEDIAOFFSET) { % +#ifdef NO_GEOM_LOSSAGE % + if (!(cruftmap | NO_LABEL)) { % + /* % + * XXX: lost non-GEOM code that handled this. The label info or % + * currently implemented primitive ioctls suffice for most file % + * systems, but msdosfs wants the absolute disk offset for one % + * thing (the number of hidden sectors). We can still use the old % + * code plus yet more compatibility cruft. In the GEOM case, GEOM % + * sysctl output must be parsed as in libdisk, or perhaps libdisk % + * can be used. libdisk takes a measly 300-400 lines and doesn't % + * seem to support more than the 2 layers (slice/partition) needed % + * for i386's, and demonstrates that xml is too hard to use by not % + * using it. % + * % + * Strangely, GEOM's breakage of compatibility for labels makes it % + * easy to determine the absolute disk offset here in some cases: % + * GEOM returns raw disk offsets in label.d_partitions[part].p_offset; % + * these already include the slice offset if the label is backwards % + * compatible, and we can determine if it is backwards compatible % + * by looking at the offset of the raw partition (until GEOM breaks % + * compatibility of that too). We would still need messy parsing % + * of the disk name to determine its partition number, if any. % + */ % + mo = ds.dss_slices[slice].ds_offset * (off_t)label.d_secsize; % + mo += label.d_partitions[part].p_offset * (off_t)label.d_secsize; % + cruftmap &= ~NO_MEDIAOFFSET; % } % +#else % + mo = 0; % + cruftmap &= ~NO_MEDIAOFFSET; % +#endif % + } % + if ((cruftmap & (NO_SECTORSIZE | NO_LABEL)) == NO_SECTORSIZE) { % + /* This shouldn't be needed. */ % + secsize = label.d_secsize; % + cruftmap &= ~NO_SECTORSIZE; % + } % + if ((cruftmap & (NO_HEADS | NO_LABEL)) == NO_HEADS) { % + heads = label.d_ntracks; % + cruftmap &= ~NO_HEADS; % + } % + if ((cruftmap & (NO_SECPERTRACK | NO_LABEL)) == NO_SECPERTRACK) { % + secpertrack = label.d_nsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % % - hs = (ms / dlp.d_secsize) - dlp.d_secperunit; % - lp = &dlp; % + /* % + * Fall back to "firmware" heads and sectors. % + * % + * XXX: this is quite broken, since we want the BIOS numbers, not the % + * firmware ones. GEOM has broken support for determining the BIOS % + * numbers in fdisk(8) and sysinstall(8) even more by changing things % + * to supply and use only the firmware numbers. Here we have a % + * preferred fallback to the numbers in the label, which can at least % + * be edited to give the BIOS numbers if they don't have them already. % + * Old labels defaulted to having BIOS numbers if possible, but GEOM % + * has got at new labels. % + */ % + if ((cruftmap & (NO_HEADS | NO_FWHEADS)) == NO_HEADS) { % + heads = fwheads; % + cruftmap &= ~NO_HEADS; % } % + if ((cruftmap & (NO_SECPERTRACK | NO_FWSECTORS)) == NO_SECPERTRACK) { % + secpertrack = fwsectors; % + cruftmap &= ~NO_SECPERTRACK; % + } % + % + /* % + * XXX this is too strict. We don't necessarily need the full disk % + * type, since we may have specified parts of it on the command line. % + * % + * Also, we don't support specifying the disk type in the normal way % + * (-T option in newfs). % + */ % + if ((cruftmap & (NO_MEDIASIZE | NO_MEDIAOFFSET | NO_SECTORSIZE | % + NO_HEADS | NO_SECPERTRACK)) != 0) % + warnx("%s: can't determine disk info; disk type must be specified", % + fname); % % if (bpb->bps == 0) % - bpb->bps = ckgeom(fname, lp->d_secsize, "bytes/sector"); % + bpb->bps = ckgeom(fname, secsize, "bytes/sector"); % if (bpb->spt == 0) % - bpb->spt = ckgeom(fname, lp->d_nsectors, "sectors/track"); % + bpb->spt = ckgeom(fname, secpertrack, "sectors/track"); % if (bpb->hds == 0) % - bpb->hds = ckgeom(fname, lp->d_ntracks, "drive heads"); % + bpb->hds = ckgeom(fname, heads, "drive heads"); % if (bpb->bsec == 0) % - bpb->bsec = lp->d_secperunit; % + bpb->bsec = ms / secsize; % if (bpb->hid == 0) % - bpb->hid = hs; % + bpb->hid = mo / secsize; % } % % @@ -802,5 +911,5 @@ % errx(1, "%s: no default %s", fname, msg); % if (val > MAXU16) % - errx(1, "%s: illegal %s %d", fname, msg, val); % + errx(1, "%s: illegal %s value %u", fname, msg, val); % return val; % } Bruce From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 20:53:56 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5F67816A400; Thu, 21 Feb 2008 20:53:56 +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 C70D713C46E; Thu, 21 Feb 2008 20:53:55 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7F1C4744007; Thu, 21 Feb 2008 22:53:54 +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 10027) with ESMTP id INKj9A8S7SWX; Thu, 21 Feb 2008 22:53:54 +0200 (EET) Received: from [10.74.70.239] (unknown [193.138.145.53]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id 1FA35744006; Thu, 21 Feb 2008 22:53:52 +0200 (EET) Message-ID: <47BDE4D7.9000007@icyb.net.ua> Date: Thu, 21 Feb 2008 22:53:43 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071208) MIME-Version: 1.0 To: freebsd-geom@freebsd.org, freebsd-fs@freebsd.org, freebsd-current@freebsd.org References: <47B81D07.7090208@icyb.net.ua> <47BD6F39.7080105@icyb.net.ua> In-Reply-To: <47BD6F39.7080105@icyb.net.ua> Content-Type: multipart/mixed; boundary="------------070705030706070407090301" Cc: Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 20:53:56 -0000 This is a multi-part message in MIME format. --------------070705030706070407090301 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Please found attached a patch to newfs_msdos that allows it to work on media for which CHS parameters do not make sense (e.g. DVD-RAM disks). First, newfs_msdos would not try to query parameters for which a user has provided override values via command line options. Second, newfs_msdos would fake values for CHS parameters like "sectors per track", "number of heads" which are not supported by the media and for which the user has not provided any values. These numbers/logic are borrowed from bsdlabel.c P.S. a line in the patch marked with XXX is a legacy of current code, not a new addition. P.S. this is not as extensive patch as that by Bruce Evans; its only merit is much smaller changeset versus current code/behavior. on 21/02/2008 14:31 Andriy Gapon said the following: > 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 --------------070705030706070407090301 Content-Type: text/x-patch; name="newfs-chs.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="newfs-chs.patch" --- newfs_msdos.c.orig 2008-02-21 21:35:00.000000000 +0200 +++ newfs_msdos.c 2008-02-21 21:56:13.000000000 +0200 @@ -739,13 +739,25 @@ /* Maybe it's a fixed drive */ if (lp == NULL) { if (ioctl(fd, DIOCGDINFO, &dlp) == -1) { - if (ioctl(fd, DIOCGSECTORSIZE, &dlp.d_secsize) == -1) + if (bpb->bps == 0 && 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)); + + /* XXX Should we use bpb->bps if it's set? */ dlp.d_secperunit = ms / dlp.d_secsize; + + if (bpb->spt == 0 && ioctl(fd, DIOCGFWSECTORS, &dlp.d_nsectors) == -1) { + warnx("Cannot get number of sectors per track, %s", strerror(errno)); + dlp.d_nsectors = 63; + } + if (bpb->hds == 0 && ioctl(fd, DIOCGFWHEADS, &dlp.d_ntracks) == -1) { + warnx("Cannot get number of heads, %s", strerror(errno)); + if (dlp.d_secperunit <= 63*1*1024) + dlp.d_ntracks = 1; + else if (dlp.d_secperunit <= 63*16*1024) + dlp.d_ntracks = 16; + else + dlp.d_ntracks = 255; + } } hs = (ms / dlp.d_secsize) - dlp.d_secperunit; --------------070705030706070407090301-- From owner-freebsd-geom@FreeBSD.ORG Thu Feb 21 22:51:41 2008 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E43A416A403 for ; Thu, 21 Feb 2008 22:51:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id A619A13C459 for ; Thu, 21 Feb 2008 22:51:41 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 2E2FC1710A; Thu, 21 Feb 2008 22:33:39 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1LDRqGW000890; Thu, 21 Feb 2008 13:27:52 GMT (envelope-from phk@critter.freebsd.dk) To: Andriy Gapon From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 21 Feb 2008 14:31:53 +0200." <47BD6F39.7080105@icyb.net.ua> Date: Thu, 21 Feb 2008 13:27:52 +0000 Message-ID: <889.1203600472@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-fs@freebsd.org, freebsd-current@freebsd.org, freebsd-geom@freebsd.org Subject: Re: newfs_msdos and dvd-ram (fwsectors, fwheads) X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:51:42 -0000 In message <47BD6F39.7080105@icyb.net.ua>, Andriy Gapon writes: >on 17/02/2008 13:39 Andriy Gapon said the following: >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 No. The geom attributes are provided if they are available only. It is the responsibility of the application code to decide and handle their absence. >2) fake those properties in newfs_msdof; > benefit: this would help with other physical devices that can host > FAT; This is the way to do it, but it might make sense to make a library routine do it, to get consistent behaviour. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.