svn commit: r244585 - in head: . sys/geom/label

[Pawel Jakub Dawidek]

On Fri, Jan 04, 2013 at 12:24:03PM -0500, Nathan Whitehorn wrote:
> On 01/04/13 12:18, John Baldwin wrote:
> > On Saturday, December 22, 2012 08:43:12 AM Jaakko Heinonen wrote:
> >> Author: jh
> >> Date: Sat Dec 22 13:43:12 2012
> >> New Revision: 244585
> >> URL: http://svnweb.freebsd.org/changeset/base/244585
> >>
> >> Log:
> >>   Mangle label names containing spaces, non-printable characters '%' or
> >>   '"'.  Mangling is only done for label names read from file system
> >>   metadata. Encoding resembles URL encoding. For example, the space
> >>   character becomes %20.
> >>
> >>   Help by:	kib
> >>   Discussed with:	imp, kib, pjd
> > Ouch, mangling spaces seems unfortunate.  I guess fixing the devctl protocol 
> > is too hard, and/or we can't just encode it at the protocol layer but leave 
> > the actual device names untouched?  OS X preserves spaces in volume names and 
> > those can be quite common on ISO images, so mangling them really does seem to 
> > be a shame if we can avoid it.
> >
> 
> On a related note, it would be *really* helpful if gpart labels were
> actually managed by gpart. This kind of thing makes predicting the path
> of a newly-labeled GPT partition extremely hard and, combined with race
> conditions and synchronization issues in glabel updating in response to
> changes in gpart, is why the installer doesn't use labels in fstab.

I fully agree that gpart should manage GEOM providers based on labels on
its own, especially that it doesn't update label by writing to
underlying provider, so GEOM tasting cannot tell glabel about changes.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
FreeBSD committer                         http://www.FreeBSD.org
Am I Evil? Yes, I Am!                     http://tupytaj.pl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130105/9d086b8e/attachment.sig>