From owner-svn-src-all@FreeBSD.ORG Wed Apr 27 07:03:43 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 60A36106566C; Wed, 27 Apr 2011 07:03:43 +0000 (UTC) (envelope-from pawel@dawidek.net) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id B6EDD8FC12; Wed, 27 Apr 2011 07:03:42 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 01D1F45CD9; Wed, 27 Apr 2011 09:03:40 +0200 (CEST) Received: from localhost (58.wheelsystems.com [83.12.187.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 166D445C98; Wed, 27 Apr 2011 09:03:35 +0200 (CEST) Date: Wed, 27 Apr 2011 09:03:24 +0200 From: Pawel Jakub Dawidek To: Warner Losh Message-ID: <20110427070324.GB2185@garage.freebsd.pl> References: <201104240923.p3O9N8QG025386@svn.freebsd.org> <20110424161933.GA18775@vniz.net> <18B3AE1E-467E-4B23-81B9-AB1EDEFE1F7A@gsoft.com.au> <34A34338-79E0-435E-9BF1-614D10FC9FC7@gsoft.com.au> <15C958E3-6CF7-48C4-88C9-2E61AC301657@gsoft.com.au> <4DB786C3.3010607@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2oS5YaxWCcQjTEyO" Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 9.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-3.9 required=4.5 tests=ALL_TRUSTED,BAYES_00, RCVD_IN_SORBS_DUL autolearn=ham version=3.0.4 Cc: src-committers@FreeBSD.org, Andrey Chernov , Daniel O'Connor , Alexander Motin , Nathan Whitehorn , svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org Subject: Re: svn commit: r220983 - head X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 07:03:43 -0000 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 26, 2011 at 09:17:04PM -0600, Warner Losh wrote: > > It's not difficult to add -- the issue is that the mechanism is unrelia= ble. It doesn't work for all partition types supporting labels, it's hard t= o figure out what the name of the label provider is in a generic way, and t= he label providers have a nasty habit of disappearing periodically when you= use the underlying provider for anything. Also, retastes don't always work= =2E For example, if I change the label of a GPT partition, the label provid= er does not reflect the change until a disk reattach (e.g. a reboot). >=20 > I know that for ufs, it works well, except for the root partition which r= equires some dancing to retrofit. But if you relabel a partition, it shows= up right away in /dev/ufs/newlbl. Guess not all of them are that reliable. >=20 > The new names, and slightly non-deterministic probe order make it more im= portant that we shake out the bugs from this as best we can. I think that = names/uuid are critical to the future, and we need to fix any remaining iss= ues. Labels are kinda tricky and they differ. For example UFS labels or IDs don't play with tasting well (they were never designed to play well with such mechanism). You can create file system that is smaller than underlying provider (newfs -s). How do we know that label is assigned to the provider we are tasing and not to some other provider? Currently we check that based on recorded file system size and provider size, so we won't create label/id on ad0s1 instead of ad0s1a, but because of this we won't create label/id at all if file system was created with the -s option. GPT labels and IDs should be implemented as part of GPART class and not GLABEL. Currently if you modify GPT label for a partition in ad0 there is no write to, eg. ad0p1, so there is no taste event which allows glabel to detect the change, so the label is not updated in /dev/gpt/. There is a patch on freebsd-geom@ to move GPT labels/IDs to GPART. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAk23v7sACgkQForvXbEpPzT3tACgzVrAoS/NKzQmeGOOBEPe69M4 N8EAn3v8hznAseuiUjPKBweg6HUi56d5 =RIrJ -----END PGP SIGNATURE----- --2oS5YaxWCcQjTEyO--