GPT labels and gjournal

Bengt Ahlgren bengta at
Mon Jun 20 19:30:28 UTC 2011

nickolasbug at writes:

> Hello stable.
> I've tried to make two journaled partitions on new GPT disk.
> Partitions have GPT labels storage and backup:
> gpart show -l ada1
> =>        34  2930277101  ada1  GPT  (1.4T)
>           34     8388608     1  (null)  (4.0G)
>      8388642  2415919104     2  storage  (1.1T)
>   2424307746     8388608     3  (null)  (4.0G)
>   2432696354   497580781     4  backup  (237G)
> gjournal label /dev/gpt/storage /dev/gptid/3570dff6-9a73-11e0-ad0e-001e8c0ecc19
> gjournal label /dev/gpt/backup /dev/gptid/58db2577-9a73-11e0-ad0e-001e8c0ecc19
> newfs -J /dev/gpt/storage.journal
> newfs -J /dev/gpt/backup.journal
> Where 3570dff6-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p1 and
> 58db2577-9a73-11e0-ad0e-001e8c0ecc19 is GPT UUID of ada1p3 partition.
> This partitions have been added to fstab:
> /dev/gpt/storage.journal /mnt/storage ufs  async,rw  0 0
> /dev/gpt/backup.journal  /mnt/backup  ufs  async,rw  0 0
> After reboot system doesn't wanna see gpt-labeled partitions
> /dev/gpt/storage.journal and /dev/gpt/backup.journal (so, mount fails)
> but has /dev/ada1p2.journal and /dev/ada1p4.journal instead.
> How can I mount this partitions using GPT labels?

Interesting!  (amarat at already suggested an alternative that I
believe works, but I thought I'd share my experience with this issue.)
I ran into a similar problem with gmirror yesterday, but first my
attempt at explaining why the above is happening.

A geom(4) class "tastes" providers (e.g. ada1p2) in a certain order.
When gjournal is tasting, it finds ada1p2 before gpt/storage, and
creates ada1p2.journal.  ada1p2 is then used, and gpt/storage is
automatically removed.

(Or alternatively, gjournal tastes before glabel, and there are no
gpt/... labels when gjournal tastes providers; same result, though.)

So to have the above work, glabel has to taste before gjournal, and
gjournal has to taste the label device (gpt/xxx) before the real device

An alternative solution would be if gjournal creates a label itself,
instead of adding ".journal" to the device name, for example
/dev/journal/foo in the same way as gmirror creates /dev/mirror/foo.
Then the journal device becomes independent of the device holding the
data component, making it possible to mount /dev/journal/foo.

Now back to gmirror.  When I tried:

gmirror label m1 /dev/gptid/xxx /dev/gptid/yyy

it still showed up as using the actual devices.  When I tried to
hardcode the provider names:

gmirror label -h m1 /dev/gptid/xxx /dev/gptid/yyy

it said it labelled both /dev/gptid/... but the mirror failed to appear.
But this does not matter for gmirror, since a device-independent mirror
name is created in /dev/mirror regardless of the names of the

The tasting order seems to be very important.  Would it be possible to
fix the above by changing so that labels are tasted before the "real"
devices?  Or does that create different problems?  gjournal would
perhaps find both gpt/xxx and ada1p2, resulting in a mess?

I think the idea with labels is great, but whether it works or not seems
pretty random to me as a user.

(People with more geom knowledge than me, please correct all errors in
the above :-) Perhaps labels are not tasted at all, like "real"
providers are???)


More information about the freebsd-stable mailing list