FreeBSD 9 BETA3 - glabel Bug?

Leander

Leander

Hi fellows,

I had drives named as following:
Code: 
glabel status
                                      Name  Status  Components
[...]
                           gpt/MirrorPart2     N/A  mirror/TestMirrorp2
                           gpt/MirrorPart1     N/A  mirror/TestMirrorp1
[...]

Then I changed names by the help of gpart But only gpart seems to hav gotten the update about new gpt labels while gpt didn"t seem to:

Code: 
gpart modify -i 1 -l "MirrorPart1-Murks" -t freebsd-ufs /dev/mirror/TestMirror

and checked first via gpart:
Code: 
gpart list

Geom name: mirror/TestMirror
modified: false
state: OK
fwheads: 255
fwsectors: 63
last: 15728605
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: mirror/TestMirrorp1
   Mediasize: 5368709120 (5.0G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 17408
   Mode: r0w0e0
   rawuuid: 62b747a3-edbf-11e0-a01b-000fa30711f1
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: MirrorPart1-Murks
   length: 5368709120
   offset: 17408
   type: freebsd-ufs
   index: 1
   end: 10485793
   start: 34
2. Name: mirror/TestMirrorp2
   Mediasize: 2684319744 (2.5G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 1073759232
   Mode: r0w0e0
   rawuuid: 6bd88370-edbf-11e0-a01b-000fa30711f1
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: MirrorPart3
   length: 2684319744
   offset: 5368726528
   type: freebsd-ufs
   index: 2
   end: 15728605
   start: 10485794
Consumers:
1. Name: mirror/TestMirror
   Mediasize: 8053063168 (7.5G)
   Sectorsize: 512
   Mode: r0w0e0
as one can see, it did successfully update my change. But then I checked via glabel:
Code: 
glabel status
                                      Name  Status  Components
[...]
                           gpt/MirrorPart2     N/A  mirror/TestMirrorp2
                           gpt/MirrorPart1     N/A  mirror/TestMirrorp1
[...]
... and somehow it seems like glabel doesn't update / recognize the change I've made ... ?!

Could someone reproduce that? Or is it only me having trouble?
 
gpart(8) puts the backup GPT partition table at the end of the disk. gmirror(8), glabel(8), gstripe(8), and other GEOM-based programs want to put their data in the last block of the provider. When the provider is a disk, there's a conflict for that last block.

One way to solve that is to put the other types inside GPT partitions. That works because only GPT has to be at the end of the disk. The others use the last block of the area they are given and return a size one block smaller. It takes more setup, and there can be other problems. Multiple gmirror partitions that need to resync can thrash the heads, for example.

Or GPT can be avoided by using MBR or an unpartitioned disk.
 
Hi wblock@,

gpart(8) puts the backup GPT partition table at the end of the disk. gmirror(8), glabel(8), gstripe(8), and other GEOM-based programs want to put their data in the last block of the provider. When the provider is a disk, there's a conflict for that last block.
Click to expand...

I'm not too sure about that conflict. I've read acouple of times (FreeBSD Mailinglist) that it is apparently not causing conflicts. I even did tests on this and figured out that it is coexisting and working nicely together - it worked out fine with 8.0 RELEASE and 8.2 RELEASE. Haven't tested RELEASES lower than those.

The issue only appears when I rename a partition label. glabel simply doesn't get the update. This is not only happening in combination with gmirror / gconcat etc. but also with regular drive/partition Labels. I more and more get the feeling glabel stucks arround somewhere or doesn't get the update by GEOM framework ... since there had been couple of changes lately?!
 
I would be interested in a pointer to the "not causing conflicts" thread. There was one a few days ago which documented the problems between GPT and the various conflicting programs glabel, gmirror, gstripe, pretty much anything that wants to use that last block for metadata installed on a full disk.

GPT partition labels from gpart(8) and labels from glabel(8) are two different things. If you can boot with gptboot and it doesn't warn about a corrupted backup GPT table, then that conflict is not present on the disk. Possibly because the GPT backup table has overwritten the last block on the disk.
 
I would be interested in a pointer to the "not causing conflicts" thread.
Click to expand...
I would have loved to show you as well - but unfortunately couldn't find it anymore ;(
That guy even gave a nice and plausible/understandable description.


GPT partition labels from gpart(8) and labels from glabel(8) are two different things.
Click to expand...

Code: 
man glabel
[...]
     Support for partition metadata is implemented for:

           ·   GPT labels (directory /dev/gpt/).
           ·   GPT UUIDs (directory /dev/gptid/).

     Generic labels are created in the directory /dev/label/.
[...]

It got implemented and it shows gpt labels as well as UFS labels - those two apps are not supposed to fight with each other ;)

To clarify the situation: I'm using gpart to create a partition. After creation of partition I use gpart again to modify its label. I only use glabel to check whether it took the changes and updated correctly - but glabel simply doesn't take the change - nether will there be the updated label under /dev/gpt/ ... there will still be the old name even though gpart shows new name by gpart list already. Feel free to reproduce:

Phase 1 - create partition:
Code: 
FreeBSD [~]# gpart destroy ada2
ada2 destroyed

FreeBSD [~]# gpart create -s GPT ada2
ada2 created

FreeBSD [~]# gpart add -l "Storage" -t freebsd-ufs ada2
ada2p1 added

FreeBSD [~]# gpart list
Geom name: ada2
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 390719821
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada2p1
   Mediasize: 200048531456 (186G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 17408
   Mode: r0w0e0
   rawuuid: 9e34e5b5-f747-11e0-b222-000fa30711f1
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: Storage
   length: 200048531456
   offset: 17408
   type: freebsd-ufs
   index: 1
   end: 390719821
   start: 34
Consumers:
1. Name: ada2
   Mediasize: 200048565760 (186G)
   Sectorsize: 512
   Mode: r0w0e0
Phase 2 - modify partition:
Code: 
FreeBSD [~]# gpart modify -i 1 -l "New-Name"  ada2
ada2p1 modified

FreeBSD [~]# gpart list
Geom name: ada2
modified: false
state: OK
fwheads: 16
fwsectors: 63
last: 390719821
first: 34
entries: 128
scheme: GPT
Providers:
1. Name: ada2p1
   Mediasize: 200048531456 (186G)
   Sectorsize: 512
   Stripesize: 0
   Stripeoffset: 17408
   Mode: r0w0e0
   rawuuid: 9e34e5b5-f747-11e0-b222-000fa30711f1
   rawtype: 516e7cb6-6ecf-11d6-8ff8-00022d09712b
   label: New-Name
   length: 200048531456
   offset: 17408
   type: freebsd-ufs
   index: 1
   end: 390719821
   start: 34
Consumers:
1. Name: ada2
   Mediasize: 200048565760 (186G)
   Sectorsize: 512
   Mode: r0w0e0
As you can see it updated the changes.


BUT glabel didn't get informed about the changes:
Code: 
FreeBSD [~]# glabel status
                                      Name  Status  Components
gptid/2fed8e3d-f4f9-11e0-beaf-000fa30711f1     N/A  ada0p1
                                gpt/RootFS     N/A  ada0p2
[...]
                               gpt/Storage     N/A  ada2p1
gptid/9e34e5b5-f747-11e0-b222-000fa30711f1     N/A  ada2p1
[...]
As you can see it still has outdated label-information "Storage" instead of "New-Name"

And since glabel doesn't know of the new label, it also didn't recreate the device:
Code: 
PDC [~]# ls -lach /dev/gpt/
total 1
dr-xr-xr-x   2 root  wheel         512B 15 Okt 13:26 .
dr-xr-xr-x  11 root  wheel         512B 15 Okt 15:26 ..
[...]
crw-r-----   1 root  operator    0, 114 15 Okt 15:26 RootFS
crw-r-----   1 root  operator    0, 173 15 Okt 18:06 Storage
[...]

BUT the funny thing is that glabel gets the changes ONLY AFTER I rebooted the machine.
glabel after reboot:
Code: 
PDC [~]# glabel status
                                      Name  Status  Components
[...]
                                gpt/RootFS     N/A  ada0p2
                              gpt/New-Name     N/A  ada2p1
[...]

So it really looks like a glabel issue to me ... OR ... GEOM Framework doesn't deliver as supposed to glabel ...

BTW: While I was writing I just kind of remembered the description about the last Block issue:

assumed I would partition ada0 to ada0p1 ada0p2 and then use [cmd=]gmirror label -v -b round-robin data ada0[/cmd] would obviously destroy the 2 partitions I just created and rewrite the block with gmirror infos.

WHILE [cmd=]gmirror label -v -b round-robin data ada0p1 ada0p2[/cmd] would not make sense but work since it would not write gmirror info at the end of the ada0 (where current gpt 2 part infos are stored) BUT it writes in the last block of each partition which differ from each other. So point is that they're not incompatible with each other.

Hope that my explanation is understandable ;)

Best regards
 
Leander said:
I would have loved to show you as well - but unfortunately couldn't find it anymore ;(
That guy even gave a nice and plausible/understandable description.

Code: 
man glabel
[...]
     Support for partition metadata is implemented for:

           ·   GPT labels (directory /dev/gpt/).
           ·   GPT UUIDs (directory /dev/gptid/).

     Generic labels are created in the directory /dev/label/.
[...]

It got implemented and it shows gpt labels as well as UFS labels - those two apps are not supposed to fight with each other ;)
Click to expand...

Right. I'm talking about
# glabel label name da0
versus
# gpart create da0
# gpart add -t freebsd-ufs -l name da0

Do those in that order and the glabel "generic label" is gone, overwritten by the GPT backup table at the end of the disk.

To clarify the situation: I'm using gpart to create a partition. After creation of partition I use gpart again to modify its label. I only use glabel to check whether it took the changes and updated correctly - but glabel simply doesn't take the change - nether will there be the updated label under /dev/gpt/ ... there will still be the old name even though gpart shows new name by gpart list already.
Click to expand...

Sounds like the device isn't retasted after the change. Try forcing it:
# true > /dev/ada2

So it really looks like a glabel issue to me ... OR ... GEOM Framework doesn't deliver as supposed to glabel ...
Click to expand...

Devices are retasted on write, even a zero-byte write like above.

BTW: While I was writing I just kind of remembered the description about the last Block issue:

assumed I would partition ada0 to ada0p1 ada0p2 and then use [cmd=]gmirror label -v -b round-robin data ada0[/cmd] would obviously destroy the 2 partitions I just created and rewrite the block with gmirror infos.
Click to expand...

It would destroy the last block of the backup GPT, which leaves it in a nearly-working state. If it's a boot disk, gptboot complains about the corrupted backup table, but still boots.

WHILE [cmd=]gmirror label -v -b round-robin data ada0p1 ada0p2[/cmd] would not make sense but work since it would not write gmirror info at the end of the ada0 (where current gpt 2 part infos are stored) BUT it writes in the last block of each partition which differ from each other. So point is that they're not incompatible with each other.
Click to expand...

This is what I was trying to say earlier. If you put the gmirror/gstripe/ganything-but-gpart information inside a GPT partition, things are fine. The other way around, no, because GPT puts the backup tables at the end of the disk instead of the end of some data container.
 
Sounds like the device isn't retasted after the change. Try forcing it:
# true > /dev/ada2
Click to expand...

Thanks, that fixed the problem. Do you have an account to open up a bug/problem report to FreeBSD developers?
 
Leander said:
Thanks, that fixed the problem. Do you have an account to open up a bug/problem report to FreeBSD developers?
Click to expand...

No, anyone can submit a PR.

This will probably not be considered a bug, though. I think that's working as designed, more of a bug in expectations. Come to think of it, that could be considered a bug in documentation.
 
It always worked for me till 9 BETA. I would expect that as a automatism. That's why we love GEOM ... it wouldn't be usefull if updates among each GEOM apps would need additional user interaction ... - my opinion - is not necessarily everyones opinion ;)

BTW: Problem is now officially Reported.


Greetings & Thanks for your help!
Hope this helps to improve ;)
 
You must log in or register to reply here.
Back
Top