From owner-freebsd-geom@FreeBSD.ORG Wed Mar 28 12:48:48 2007 Return-Path: X-Original-To: freebsd-geom@freebsd.org Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BAAE516A400; Wed, 28 Mar 2007 12:48:48 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (arm132.internetdsl.tpnet.pl [83.17.198.132]) by mx1.freebsd.org (Postfix) with ESMTP id E788013C46C; Wed, 28 Mar 2007 12:48:47 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id DE8BE487FA; Wed, 28 Mar 2007 14:48:44 +0200 (CEST) Received: from localhost (pjd.wheel.pl [10.0.1.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id F080145684; Wed, 28 Mar 2007 14:48:34 +0200 (CEST) Date: Wed, 28 Mar 2007 14:48:32 +0200 From: Pawel Jakub Dawidek To: Eric Anderson Message-ID: <20070328124832.GB35749@garage.freebsd.pl> References: <460A6075.7000302@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <460A6075.7000302@freebsd.org> X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 7.0-CURRENT i386 User-Agent: mutt-ng/devel-r804 (FreeBSD) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-5.9 required=3.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Geom_label and multiple devices 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: Wed, 28 Mar 2007 12:48:48 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Mar 28, 2007 at 07:32:53AM -0500, Eric Anderson wrote: > On 03/28/07 05:39, Ivan Voras wrote: > >I've just thought of something - the situation where geom_label detects = multiple "same" labels is actually very similar to that of geom_multipath. = Obviously this doesn't=20 > >apply 100% to UFS and other filesystems' labels (except if there's a way= to identify different file systems by their superblock, for example timest= amp of creation?), but=20 > >in case of "manual" labels, if the unique ID matches and the label strin= g matches, it's probably the same device. > >Currently, geom_label discards "additional" devices with the same label,= and I remember there was a discussion about if that should be changed (tho= ugh I don't remember the=20 > >conclusions). It would be useful if geom_label would work the same as ge= om_multipath in this case (i.e. failover to "next" device, add new devices = with same label+id to=20 > >the pool), or even if geom_multipath were merged in geom_label. > >Comments? >=20 >=20 > I think that the duplicate label case is not really the same as multipath= =2E I see your point, but the duplicate label issue is more of a cause fr= om mistake rather than=20 > intention. Yeah. When I see duplicated labels, I don't want to show them both with some random names that nobody expect. And think here about automatic processing, not that administrator can take a look and find new name. I can do two things: 1. Present one of those labels. 2. Stop the system (panic?), because it's just administrator fault (misconfiguration). I'd prefer 2, but it's too cruel. Administrators make mistakes and we have some garbage to clean still (eg. 'c' partition). That's why I decided to go with 1. > Maybe it would be a good idea to allow a priority value in the geom_label= meta data so that an admin could prioritize his labels. For instance, on = my laptop, I have=20 > labeled my root partition /dev/label/root. If I have a compact flash plu= gged in that I'm working on for a small embedded device, I also need it nam= ed /dev/label/root, even=20 > though I'm already using that label. I want to be able to reboot my lapt= op with the compact flash inserted still, without it possibly booting off t= he flash instead. To=20 > protect against that, I could prioritize my internal hd's 'root' labeled = device to a priority of '1', which means 'nothing is higher priority than t= his device'. A '0'=20 > would mean no priority given, and any number greater than 0 is less prior= ity. That way admins could mark their labels and allow certain devices to = be forced more important=20 > than others. Comments? I like this idea, but it can only be used for glabel's native labels. You can't use the same method for filesystem volume names, and those are more often used than glabel's native labels. Don't read me wrong, I still like your idea and would be glad to commit something like this. Care to provide a patch?:) --=20 Pawel Jakub Dawidek http://www.wheel.pl pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFGCmQgForvXbEpPzQRAj9mAJ9ZGU8dDyoL0pqO5sZ0T3KCwoBcsgCcCglG uGhLjdWC154HgMb6pbkMQek= =a2mv -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy--