AHCI driver and static device names

Thu Dec 15 02:05:30 UTC 2011

On 12/14/2011 03:18 PM, Rob wrote:
> On 12/3/11 11:04 AM, CyberLeo Kitsana wrote:
>> To answer your question, though: You cannot combine GPT with glabel (or
>> any other geom class that writes data to the first or last 34 sectors of
>> a disk, like gmirror) due to layout conflicts. MBR and BSD schemes can
>> be used, since they occupy only the first sectors of the device, and
>> their monikers will be appended to the label. Thus, labeling a
>> single-slice MBR disk (/dev/ada0) with 'test' would produce /dev/ada0,
>> /dev/ada0s1, /dev/label/test, and /dev/label/tests1; nesting a BSD table
>> within s1 would add /dev/ada0s1a and /dev/label/tests1a as well.
> 
> Do gpt labels work the same as glabel, ie provide a static device name
> that can be acted upon with /etc/fstab, zfs, gmirror, etc?

Yes. It's actually handled by the same geom class.

>>> The other option seems to be to use tunefs or a partitioning tool to
>>> label each partition, which is even more ugly imo.
>>
>> Ugly how? Labels appear a lot more semantically elegant than the opaque
>> 'ada4s1a' moniker.
> 
> Ugly in that the driver has created a situation where we need
> workarounds to perform the tasks we need.  *nix systems have always
> relied upon static device nodes, and using dynamic names without
> updating the relating tools/methods is ugly.  The workarounds also could
> fail if someone forgets to perform them (specifically labels), since
> it's not necessary on just about any other *nix system.  It's perfectly
> within reason to assume people will forget to apply a label when
> replacing a disk.

Anything fails if you forget to do it. Administrative failure should not
be confused with technical failure.

Static device nodes are appropriate when the topology is fixed and can
be reasonably anticipated. With variable topologies, such as USB, iSCSI,
multipath, and PCI hotswap, the disk controllers may not even exist at
boot, or may be reordered based on probe order, or the order in which
the remote units respond; and that's before the kernel even gets around
to setting up the devices attached to those controllers. You cannot
reasonably expect the system to statically allocate device nodes for
every possible configuration that may exist for all technologies that
might be added to a machine, so why offer the expectation when the
system cannot possibly hope to fulfill it for even a fraction of the
common cases?

> Case in point.  I have a system with 15 drives in it.  I decided I
> wanted to install on the 2nd device instead of the 1st, but I
> partitioned all the other 14 drives.  I completed installation and when
> to boot the system and it failed.  Stupid me, the GPT boot loader found
> disk1 with a partitioning scheme but no fs.  So, I popped out disk 1 and
> when to boot again.  Hey, now it starts to boot only to fail to find the
> root fs because it's looking on ada1 and the fs is on ada0.  That is a
> mess.

Sounds like a bug in the BIOS or boot loader. The boot loader should be
able to ask the BIOS for the device from which it read the boot code,
and use that instead of just naively using the the first available
device in the system; the only instances where I've seen this fail have
been on machines that should've been put down years ago. Which isn't to
say it doesn't still happen.

> This is not necessarily common, but also not uncommon.  More likely is
> the case where you add a drive to the system and the above scenario
> plays out because the device names get re-ordered.  I'm not sure the
> problem the dynamic device nodes intends to solve, but it's certainly
> caused all sorts of pain and the need for the 2 (that I know of)
> workarounds.

How about when you add a PATA drive to a machine, but the cable is
blocking the last available bay; so you have to move an existing drive
to a different position on the cable to make room for the one you're
installing? Static device numbering won't save you now.

Or how about those silly BIOSes that assume that you must really want to
boot to the new disk you just attached to the machine, so helpfully
rearrange your boot order for you so now you're booting to a strange
disk with who knows what on it?

Honestly, there's so much that can go wrong. That's what sysadmins are for.

> I dislike the idea of having to use labels to get static functionality
> (increases the likelihood of something going wrong for a disk replace
> operation if I forget to label), but I'll give gpt labels a try.

I find that labels solve more problems than they introduce, when applied
properly. The semantic meaning given to the devices often mean I can
discover what's on a particular disk in my pile'o'drives just by
plugging it in and looking at the kernel log; no mounting necessary.
Likewise, when juggling disks or controllers around, I don't have to
worry about remembering to update the fstab, since the labels follow the
data.

This is a lot better than my Linux machine, where I have to do some
rather interesting hacks in the initrd just to make sure the root mirror
is assembled regardless of where its disks might have attached this boot.

If you're worried that you'll forget steps during a disk replacement, I
have found that detailing a runbook beforehand helps a lot. I have
several I keep on a wiki so that I can remember all the steps needed to
set up a new installation, replace a disk, or perform other maintenance
tasks that are too intermittent for my poor memory to suffice.

-- 
Fuzzy love,
-CyberLeo
Technical Administrator
CyberLeo.Net Webhosting
http://www.CyberLeo.Net
<CyberLeo at CyberLeo.Net>

Furry Peace! - http://wwww.fur.com/peace/