Can't use gpt labels re-importing pool

Jeremy Chadwick freebsd at jdc.parodius.com
Thu Nov 26 13:48:48 UTC 2009


On Thu, Nov 26, 2009 at 12:56:50PM +0100, Ivan Voras wrote:
> Jeremy Chadwick wrote:
> 
> >Why are people bothering with GPT labels (or in some cases, glabels)
> >when AHCI (whether it be ataahci.ko or ahci.ko) is in use?  Under what
> >circumstance would the device name change dynamically in this situation?
> >
> >I've never witnessed this happening with AHCI, at least on Intel
> >systems, and I've hot-swapped hard disks many times over.
> 
> It isn't specific to AHCI, but this is where most people encountered
> it first. The issue in question is "how to make ZFS survive drive
> renaming" for any cause - driver change, controller change, drive
> shuffling, etc.
> 
> In general, ZFS will taste individual drives on "zpool import" so
> will try to do the right thing, but it might pick up different
> labels for different drives, etc. Using glabel tricks simply makes
> the naming a bit more consistent.

What I'm having trouble understanding is where the "more consistent"
concept comes from.  I guess it ultimately depends on one's system
configuration.

For example: Tom Evans' situation greatly benefits from use of labels,
since his configuration consists of 1) multiple SATA controllers, and 2)
moving drives around between different controllers.

This isn't going to happen in most production server environments, where
the there is a static number of disks and (usually) a single controller.
This is the "situation" I was referring to; "environment" or
"configuration" would have been a more accurate choice of word.

On 4-disk Supermicro systems (Intel ICHx + AHCI based, with hot-swap
drive bays, with FreeBSD 7.x/8.x and ataahci), depending on what ICHx
ports the drives are plugged into, your drive bays/disks are going to be
static/consistent.  SATA port #0 = ad4, SATA port #1 = ad6, and so on.
These won't change unless you do something like, say, disable a SATA
port or disable AHCI mode in the BIOS.

Regardless, I'm almost certain I've made the mistake on a 4-disk system
of doing (physical) system cleaning, which involves dusting out all of
the bays and so on -- and ended up inserting a drive/carrier/disk into a
bay which it wasn't part of prior to the shutdown.  "zpool import" took
care of things for me.

If someone wants me to validate my own memory (the more I work Grave
shift the more I find my memory failing me...), I'd be more than happy
to spend a weekend messing around moving disks + reporting back what the
behaviour is on RELENG_8.  I have a "spare" 5-disk (6 ports) system
which can be used for this purpose (Supermicro X7SBA + 5 disks).  I
spend most of my time messing around with disks at my night job as is...
:-)

-- 
| Jeremy Chadwick                                   jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |


More information about the freebsd-stable mailing list