From owner-svn-src-all@FreeBSD.ORG Wed Apr 27 03:22:16 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 578E11065702; Wed, 27 Apr 2011 03:22:16 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id E23B18FC17; Wed, 27 Apr 2011 03:22:15 +0000 (UTC) Received: from [10.0.0.63] (63.imp.bsdimp.com [10.0.0.63]) (authenticated bits=0) by harmony.bsdimp.com (8.14.4/8.14.3) with ESMTP id p3R3H4j1041320 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Tue, 26 Apr 2011 21:17:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <4DB786C3.3010607@freebsd.org> Date: Tue, 26 Apr 2011 21:17:04 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> To: Nathan Whitehorn X-Mailer: Apple Mail (2.1084) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (harmony.bsdimp.com [10.0.0.6]); Tue, 26 Apr 2011 21:17:06 -0600 (MDT) Cc: src-committers@FreeBSD.org, Andrey Chernov , Daniel O'Connor , Alexander Motin , 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 03:22:16 -0000 On Apr 26, 2011, at 9:00 PM, Nathan Whitehorn wrote: > On 04/26/11 18:48, Daniel O'Connor wrote: >>=20 >> On 26/04/2011, at 1:31, Warner Losh wrote: >>>> This is why I prefer IDs since they are nominally unique (UFS >>>> ones, GPTs damn well better be :) >>>>=20 >>>> Although I concede it is rather annoying to work out which is >>>> which, or type them out manually.. >>>=20 >>> For things like ZFS, UUIDs aren't so bad because it hides them. >>=20 >> Yes, I use GPT with ZFS, it's good :) >>=20 >>> For things like /etc/fstab, I prefer the named approach. This >>> allows me to survive a newfs on a partition if I have to without >>> having to hack my /etc/fstab. I have a large /tmp partition at >>> times, and it gets newfs'd if there's a bad problem... >>=20 >> Yeah, but.. IMHO if the installer supports it then it is dramatically >> less painful.. >>=20 >> I haven't looked to see how hard it is to add, hopefully I will get >> some time to look RSN and it shouldn't be too difficult. >=20 > It's not difficult to add -- the issue is that the mechanism is = unreliable. It doesn't work for all partition types supporting labels, = it's hard to figure out what the name of the label provider is in a = generic way, and the label providers have a nasty habit of disappearing = periodically when you use the underlying provider for anything. Also, = retastes don't always work. For example, if I change the label of a GPT = partition, the label provider does not reflect the change until a disk = reattach (e.g. a reboot). I know that for ufs, it works well, except for the root partition which = requires 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. The new names, and slightly non-deterministic probe order make it more = important 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 issues. > If it's a feature that we enable by default, and that the installer = relies upon, it has to work better than that. Thanks for the report. Who are you working with to resolve these = issues? Some of them surprise me, but you speak of them as if they are = widely known... Without owners, these issues will languish. Warner=