Date: Thu, 21 Apr 2011 10:01:52 -0500 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: Switch from legacy ata(4) to CAM-based ATA Message-ID: <4DB046E0.1080502@freebsd.org> In-Reply-To: <DACA5DEF-C004-4818-B658-21045582E480@lists.zabbadoz.net> References: <4DAEAE1B.70207@FreeBSD.org> <20110420203754.GM85668@acme.spoerlein.net> <4DAF46F8.9040004@FreeBSD.org> <BCE89DC7-116D-48E1-BD86-DF986062B0CC@samsco.org> <DACA5DEF-C004-4818-B658-21045582E480@lists.zabbadoz.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 04/21/11 02:51, Bjoern A. Zeeb wrote: > On Apr 20, 2011, at 10:18 PM, Scott Long wrote: > >> On Apr 20, 2011, at 2:50 PM, Alexander Motin wrote: >>> Ulrich Spörlein wrote: [...] > > b) FYI: labels and stacked geoms do not work well together as you can > never detach providers cleanly then, which basically means you are at > risk of data loss with every reboot. I was told multiple times that > this is not fixable. If it is labels seem to be a great why to go. > For now I have to compile them out/disable them unfortunately so they > are not an option, and they'll be less so if the new installer also > offers gmirror, geli, ... installs. > > Give me a solution that works out of the box and I'll happily agree > that we switch. [slightly off-topic] This is related to why bsdinstall doesn't put labels in /etc/fstab, although it does support setting them in the partition table for GPT, APM, and PC98 partitions: the mechanism seems to be sort of ad-hoc and unreliable. Only some of these labels (GPT) result in entries in /dev, and even then only on some platforms (GPT labels on big-endian systems don't work). The entries for GPT are added by glabel instead of gpart, which has to retaste and parse the GPT itself. This means it is difficult to guess the name of the labeled partition, or even whether it exists, and this is for gpart labels, which are probably the cleanest possible case. It would very much help if (a) gpart handled populating /dev/part-scheme/label itself, (b) did it generically for all partition schemes supporting labels, and (c) could tell you the path to the label entry in the config XML, which is right now somewhat difficult to obtain. It's also not clear to me what happens if you insert two volumes with identical labels (e.g. "root") in the same machine -- at least ad[a]X are guaranteed non-conflicting. This is a serious potential issue with using labels in the installer's auto-defaults partitioning option. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4DB046E0.1080502>