Re: Switch from legacy ata(4) to CAM-based ATA

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