From owner-freebsd-hackers@FreeBSD.ORG Thu Jun 28 21:55:04 2012 Return-Path: Delivered-To: freebsd-hackers@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 385E91065675; Thu, 28 Jun 2012 21:55:04 +0000 (UTC) (envelope-from marcel@xcllnt.net) Received: from mail.xcllnt.net (mail.xcllnt.net [70.36.220.4]) by mx1.freebsd.org (Postfix) with ESMTP id D48328FC19; Thu, 28 Jun 2012 21:55:03 +0000 (UTC) Received: from sa-nc-common3-173.static.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mail.xcllnt.net (8.14.5/8.14.5) with ESMTP id q5SLsnfc037954 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 28 Jun 2012 14:54:58 -0700 (PDT) (envelope-from marcel@xcllnt.net) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Marcel Moolenaar In-Reply-To: <20120628214902.00004e34@unknown> Date: Thu, 28 Jun 2012 14:54:43 -0700 Content-Transfer-Encoding: 7bit Message-Id: <146B8DC1-4B66-4E78-BBB3-3954DC305424@xcllnt.net> References: <4FE9B01C.30306@yandex.ru> <201206270807.23347.jhb@freebsd.org> <4FEB0079.7050008@yandex.ru> <201206271028.54477.jhb@freebsd.org> <4FEB5A3C.5050900@borderworlds.dk> <1900D4C1-E5E5-446F-ABBF-976A2DFEB36B@xcllnt.net> <4FEC22A0.9000109@freebsd.org> <4FEC2D86.2040505@freebsd.org> <8D85513D-CDFC-4D62-AA5A-F82F46E28CE5@xcllnt.net> <20120628214902.00004e34@unknown> To: Alexander Leidinger X-Mailer: Apple Mail (2.1278) X-Mailman-Approved-At: Thu, 28 Jun 2012 22:50:38 +0000 Cc: Doug Rabson , Marcel Moolenaar , Pawel Jakub Dawidek , Christian Laursen , freebsd-hackers , Andriy Gapon , Stefan Esser , "Andrey V. Elsukov" , freebsd-current Subject: Re: [CFC/CFT] large changes in the loader(8) code X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jun 2012 21:55:04 -0000 On Jun 28, 2012, at 12:49 PM, Alexander Leidinger wrote: > On Thu, 28 Jun 2012 08:33:17 -0700 Marcel Moolenaar > wrote: > >> My advise is to leave disk mirroring to H/W or firmware solutions and >> use FreeBSD mirroring for FreeBSD partitions only. If you want to >> mirror the whole disk, don't partition the disk with non-FreeBSD >> partitioning schemes and partition only with FreeBSD-specific schemes >> or put a FreeBSD file system on the whole disk. In other words: make >> the whole disk private to FreeBSD. > > If I gmirror the entire disk, I already expressed my interest to make > the whole disk private to FreeBSD, haven't I? No. All you've done is type some commands. There's no inherent value in it that relays that you know what you're doing. I have no problem accepting that you do in fact know what you're doing, but that doesn't mean that anyone who types the same sequence of commands is as skilled as you are -- that would be a silly inference. What you need to do is not have it be about you, but about some random user. > Or are you suggesting to > convince all BIOS vendors to include the ability to boot from some kind > of FreeBSD private partitioning scheme (not MBR as it is not > suitable, not GPT as you are not OK to use it on a gmirror)? I would be having less problems if the mirroring didn't force the backup GPT header in anything but the last sector. If the metadata was somewhere else, then we wouldn't need to kluge various places to deal with the ambiguity and visible interoperability problems of the various tools and OSes. Thus, it's not that I object to the mirroring per se, just to the mirroring as it is currently implemented with gmirror. > What about multipathing? In case the disk is attached via two paths but > multipath is not enabled, the OS sees the same disk (and the same > identical unique disk identifier) multiple times. Is this a violation > of the spec too? It's the same disk, isn't it? The OS can actually use the property of the ID to infer that it has already seen this disk and not create multiple device nodes. -- Marcel Moolenaar marcel@xcllnt.net