# glabel vs. GPT labels



## Tsuroerusu (Apr 11, 2012)

Later this year I will be rebuilding my ZFS storage server (because of new hardware, and various other things that needs to be done better/correctly on my current installation, plus it is fun to start from scratch at times! :e ).

At the present moment I use glabel to identify the drives in the system. When I did my original install (ZFS on root) last year, the stars must have aligned, because I managed (without knowing or thinking about the issues) to do glabel+GPT-partitioning in a way that actually made it work (glabel first, then GPT partition the labeled device, ie. *gpart add -t freebsd-zfs label/disk01*). Subsequently, I have read about the issues with that, and given that GPT can do labeling on its own, it would be simpler to use GPT labels at least for the root disks (ZFS mirror).

However, for my actual storage pool, I use glabel and whole disks with ZFS at the present moment, and thinking through, in my mind, what my final system would look like, I got into thinking, that I could either use GPT labeling just for the root pool, and glabel for the storage pool, or I could use GPT labels for all the drives in both pools (I have separate pools for the zroot mirror and the storage raidz2 pool).

Therefore, I would like to humbly ask the storage wizards (phoenix?  ) in here, how does glabel weigh against GPT labels, if we look aside the fact that GEOM classes conflict with GPT partitioning if used for whole disks?

Right off the top my of my head, I am thinking that GPT is OS-neutral, whereas glabel is specific to FreeBSD. However, as I said, I would like to know whether there is some advantages to glabel over GPT labels.

(Note, this is not really a ZFS question, but a glabel/GPT question, ZFS being mentioned above is merely incidental.)


----------



## wblock@ (Apr 11, 2012)

One glabel for the whole disk is really not very different from one GPT partition on the whole disk.  If you want maximum compatibility, use GPT with just one partition on the whole disk.


----------



## Tsuroerusu (Apr 11, 2012)

wblock@ said:
			
		

> One glabel for the whole disk is really not very different from one GPT partition on the whole disk.  If you want maximum compatibility, use GPT with just one partition on the whole disk.



That is what I was thinking too, I was just not sure as to whether I might potentially be missing something in my "analysis" about glabel that might weigh in its favour.

So far, it seems to me that GPT, for this purpose, as you outlined, has more going for it, given that it also keeps a backup of its header and so on, and thus for the purpose of labeling allows for a little more flexibility than glabel appears (To me, a moderately advanced user (Not a programmer, by ANY stretch of the imagination) of FreeBSD) to do.


----------



## t1066 (Apr 11, 2012)

Going from glabel to GPT increases boot time quite a bit, maybe 1 minute. The extra time is spending between after the disks are listed and before the /boot/loader.conf is loaded. I can see that the rotating bar moves very slowly during that time. Maybe it relates how I gpart the drives.


```
$ gpart show da0
=>        34  1953525101  da0  GPT  (931G)
          34        2014       - free -  (1M)
        2048  1952448512    1  freebsd-zfs  (931G)
  1952450560     1074575       - free -  (524M)
```


----------



## wblock@ (Apr 11, 2012)

Is using GPT the only change?  That sounds like the controller looking for bootable drives.


----------



## Sebulon (Apr 11, 2012)

Nope, itÂ´s the gptzfsloader, probing 128 partitions all of the time:
http://freebsd.1045724.n5.nabble.com/zfs-parition-probing-causing-long-delay-at- BTX-loader-td4922293.html

A minor tweak and rebuild world changed my boot time from 10 mins down to 2 Pain in the ass if you ask me. Good in theory, but not very practical.

/Sebulon


----------



## wblock@ (Apr 11, 2012)

Wow, that's crazy.  It should only check partitions that are used.


----------



## Sebulon (Apr 11, 2012)

wblock@

Couldn't agree more

Is there a way to voice this concern so that the appropriate developers might reconsider this "feature"?

/Sebulon


----------



## wblock@ (Apr 11, 2012)

A PR, traditionally.  Patches help.  Asking on one of the mailing lists is another option.  Don't know which one, maybe -current or -stable.

Skipping unoccupied partitions ought to speed up booting even when there are are only a few partitions.


----------

