GEOM_LABEL questions

[harisman]

Hi to all,

I recently tried to play with partition labels and I have some issues. I have problem removing partition labels created with tunefs -L command. I read the tunefs(8) and I didn't find anything. I end up trying tunefs -L"" <device> :e with no success. The glabel itself works like a charm and creates/removes labels on /dev/label/<label> but doesn't have any effects on /dev/ufs/<label> created by tunefs -L.

Any ideas? I am using FreeBSD 7.1-RELEASE with custom kernel (GEOM_LABEL is included in the kernel options).

Thanks!

 

[rtwingfield]

This is an old thread, but I have the same problem with FreeBSD v8.2 and the GEOM scenario.

The glabel itself works like a charm and creates/removes labels on /dev/label/<label> but doesn't have any affects on /dev/ufs/<label> created by tunefs -L

How can I destroy (i.e., permanently remove) the /dev/ufs labels?

 

[wblock@]

Why destroy the UFS labels? If they aren't used any more, ignore them, they won't hurt anything.

 

[rtwingfield]

A lot of what I'm currently doing is somewhat academic. I have the luxury of working with a new system and can't hurt anything that I cannot easily recover. That said, I'm (still) struggling with a configuration to boot from a GEOM RAID1 Mirror consisting of two drives, and simply cannot make it work (although at one time . . .it was bootable).

Here's the situation.

/dev/ufs (as a result of an experiment with tunefs) contains the following: (Warren ...in my case "aa" stands for ArchAxis ...not aardvark )

# ls ufs
aatmpfs aausrfs aavarfs

Using GLABEL(8) with the stop directive

# glabel stop -fv /dev/ufs/aatmpfs
Done.

...apparently removes aatmpfs from the GEOM

# ls ufs
aausrfs aavarfs

Also logged in dmesg:

# GEOM_LABEL[1]: Label ufs/aatmpfs removed.

GLABEL(8) states that "stop" turns off the given label by its name, but does not touch on-disk metadata.

After reboot, it's back,

# ls ufs
aatmpfs aausrfs aavarfs

...and I suppose that's OK ...because I assume that "stop" implies "temporarily hide it".

If glabel destroy is executed (noting that GLABEL(8) documents that "destroy" is "Same as stop"), the same apparent results are indicated:

# glabel destroy -fv /dev/ufs/aatmpfs
Done.

# ls ufs
aausrfs aavarfs

...and again, after reboot, it's baaack (like a mother-in-law who comes to visit and never leaves):

# ls /dev/ufs
aatmpfs aausrfs aavarfs

On a functional note, I'm annoyed regarding the GLABEL(8) "stop" vs. "destroy" directive, that "destroy" does not destroy the label (as in forever).

Additionally, executing the "clear" directive (documented as "Clear metadata on the given devices.") ...fails:

# glabel clear -v /dev/ufs/aatmpfs
Can't clear metadata on /dev/ufs/aatmpfs: Invalid argument.
glabel: Not fully done.

Well, I don't know what the invalid argument is ...the syntax is righout out of GLABEL(8).

Ultimately, what I'm trying to accomplish is a "clean slate" where I can be assured that some of these potentially superfluous labels are not in conflict.

 

[wblock@]

# glabel stop -fv /dev/ufs/aatmpfs
Done.

...apparently removes aatmpfs from the GEOM

# ls ufs
aausrfs aavarfs

Also logged in dmesg:

# GEOM_LABEL[1]: Label ufs/aatmpfs removed.

GLABEL(8) states that "stop" turns off the given label by its name, but does not touch on-disk metadata.

After reboot, it's back,

# ls ufs
aatmpfs aausrfs aavarfs

...and I suppose that's OK ...because I assume that "stop" implies "temporarily hide it".

Maybe helpful to think of it as "stop the GEOM module that relays label information from the on-disk label through to devfs".

If glabel destroy is executed (noting that GLABEL(8) documents that "destroy" is "Same as stop"), the same apparent results are indicated:

# glabel destroy -fv /dev/ufs/aatmpfs
Done.

# ls ufs
aausrfs aavarfs

...and again, after reboot, it's baaack (like a mother-in-law who comes to visit and never leaves):

# ls /dev/ufs
aatmpfs aausrfs aavarfs

On a functional note, I'm annoyed regarding the GLABEL(8) "stop" vs. "destroy" directive, that "destroy" does not destroy the label (as in forever).

I *think* that actually changing the label would be up to the underlying filesystem- and device-specific modules, and those are read-only for labels. It's only the code that writes to one of these labeled devices that is allowed to actually change it. For UFS, that would be newfs(8) or tunefs(8). Using "destroy" is probably to remain compatible with other GEOM classes.

Additionally, executing the "clear" directive (documented as "Clear metadata on the given devices.") ...fails:

# glabel clear -v /dev/ufs/aatmpfs
Can't clear metadata on /dev/ufs/aatmpfs: Invalid argument.
glabel: Not fully done.

If it's still mounted, that would make sense. Otherwise, glabel still might not be allowed to write to filesystem labels because they don't belong to it.

Well, I don't know what the invalid argument is ...the syntax is righout out of GLABEL(8).

Ultimately, what I'm trying to accomplish is a "clean slate" where I can be assured that some of these potentially superfluous labels are not in conflict.

Without destroying data, I don't know. If you don't care about the data, dd(1) will do it. The labels have to be either at the start or end of the device.

I've come to prefer gpart(8) labels.

 

[aragon]

There's some confusion about labels here. What you've created is a file system label. Although glabel(8) is responsible for reading those labels, it can not manipulate them in any way. The only labels it can manipulate are "generic" labels (for lack of a better name) that it created in the first place.

Only file system tools can manipulate file system labels, and in the case of UFS, using tunefs(8) to set the label to a null string works for me here on 9.0...