From owner-freebsd-geom@FreeBSD.ORG Mon Jun 2 22:27:07 2014 Return-Path: Delivered-To: geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C346790A; Mon, 2 Jun 2014 22:27:07 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 986102B79; Mon, 2 Jun 2014 22:27:07 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s52MR6eR026764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Jun 2014 15:27:06 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s52MR6hL026763; Mon, 2 Jun 2014 15:27:06 -0700 (PDT) (envelope-from jmg) Date: Mon, 2 Jun 2014 15:27:06 -0700 From: John-Mark Gurney To: Pawel Jakub Dawidek Subject: Re: diskid documentation Message-ID: <20140602222706.GA43976@funkthat.com> Mail-Followup-To: Pawel Jakub Dawidek , geom@freebsd.org, FreeBSD Current , Ryan Stone , Allan Jude , "Michael W. Lucas" References: <20140601134147.GA99583@bewilderbeast.blackhelicopters.org> <538C7B71.20109@freebsd.org> <20140602153651.GB4116@bewilderbeast.blackhelicopters.org> <20140602180108.GX43976@funkthat.com> <20140602202639.GA1668@garage.freebsd.pl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140602202639.GA1668@garage.freebsd.pl> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 02 Jun 2014 15:27:07 -0700 (PDT) Cc: geom@freebsd.org, FreeBSD Current , Ryan Stone , "Michael W. Lucas" , Allan Jude X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jun 2014 22:27:08 -0000 Pawel Jakub Dawidek wrote this message on Mon, Jun 02, 2014 at 22:26 +0200: > On Mon, Jun 02, 2014 at 11:01:08AM -0700, John-Mark Gurney wrote: > > Michael W. Lucas wrote this message on Mon, Jun 02, 2014 at 11:36 -0400: > > > On Mon, Jun 02, 2014 at 10:45:52AM -0400, Ryan Stone wrote: > > > > On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude wrote: > > > > > It also tends to sometimes hide the gpt label provider on me (not sure > > > > > in which cases it does this, but it is annoying) > > > > > > > > This happens when something (e.g. zfs) happens to open the diskid > > > > provider instead of the gpt label. For me this ended up being a bit > > > > more than annoying; my swap was mounted in /etc/fstab via a gpt label > > > > so I silently lost my swap when I did an upgrade. > > > > > > Wait-- one type of one label can hide another? > > > > > > I thought a big point of labels was to remove ambiguity... > > > > Surprisingly, yes... I didn't think about this, but it's true... > > > > A disk will get exported via two different devices, diskid and normal > > da/ada... The tasting will go through and create all the necessary > > sub devices, but the problem is that we now have two different paths, > > and if something opens the diskid path, then the da/ada paths all > > disappear... > > > > This sounds like we need to fix geom to "bind" the two together so > > that when one opens, the other doesn't disappear... The problem is > > that geom views them as two separate disks when in fact they are the > > same... someone who knows geom well should think about how to solve > > this problem, as diskid isn't the first time this has happened, just > > most prevalent w/ ZFS and diskid. > > The problem is that GPT labels (or GPT IDs for that matter) should not > be implemented within GLABEL. This is wrong. It should be implemented as > part of GPART, so that GPART would create ada0p1, gpt/label and > gptid/whatever. Opening one of those should not make the others > disappear then. Only opening ada0 for writting would make them disappear. even gpart would be wrong IMO... What happens if there is another provider like GPART, but different, do they need to implement diskid creation too to prevent the same issue? Shouldn't geom be updated to say, this ident is an alias, everything you do w/ this, it's exactly the same as the other one? This would also have the advantage of possibly removing one layer in the call chain when dealing w/ IO. (or does GEOM has a pass-through flag that says, I don't do anything, just skip me?) -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."