Page MenuHomeFreeBSD

glabel.8: Warn against using generic labels on a shared device
AcceptedPublic

Authored by markj on May 26 2022, 1:55 PM.
Tags
None
Referenced Files
Unknown Object (File)
Mon, Jan 9, 10:13 PM
Unknown Object (File)
Mon, Jan 9, 10:53 AM
Unknown Object (File)
Dec 15 2022, 7:20 AM
Unknown Object (File)
Dec 15 2022, 12:20 AM
Unknown Object (File)
Dec 8 2022, 4:38 AM
Unknown Object (File)
Dec 8 2022, 3:58 AM
Unknown Object (File)
Dec 5 2022, 1:24 AM

Details

Reviewers
imp
pauamma
Group Reviewers
manpages
Summary

Also suggest against creating a generic label on a device which already
contains a filesystem.

PR: 264166

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45743
Build 42631: arc lint + arc unit

Event Timeline

markj requested review of this revision.May 26 2022, 1:55 PM
pauamma added inline comments.
lib/geom/label/glabel.8
151

"should not" as in, "you can but really shouldn't"?

"You should not use glabel with any device you plan on putting a filesystem on"

might be better advise.

And I think I'll retract the prior 'advise'.

lib/geom/label/glabel.8
159

Do you want to note something about the size changing here? Isn't that the real problem?

In D35326#800921, @imp wrote:

"You should not use glabel with any device you plan on putting a filesystem on"

might be better advise.

Huh? Did you mean "If glabel is used, the filesystem should be put on the glabel device, rather than both label and filesystem put on a the same underlying device."

(Or are you commenting on the quality or usefulness of glabel?)

In D35326#800921, @imp wrote:

"You should not use glabel with any device you plan on putting a filesystem on"

might be better advise.

Huh? Did you mean "If glabel is used, the filesystem should be put on the glabel device, rather than both label and filesystem put on a the same underlying device."

(Or are you commenting on the quality or usefulness of glabel?)

I was being catty.... But your advise is much better. glabel steals a sector or two for it's labeling info, and so you need to use the glabel device. It's also why you can't usually label something after the filesystem is on there: these stolen sector will be fought over potentially.

What's confusing, though, is that things like /dev/ufs or /dev/gpt can be added later because those labels are integrated into either the partitioning or the filesystem superblock. not so with 'glabel label' command...

mdoc(7) syntax looks good to me, so once the other issues pointed out with the manual page have been fixed, I'm happy to accept it.

allanjude added inline comments.
lib/geom/label/glabel.8
147

should only be used when ...

reads much better

151

It might be best to add an additional sentence here explaining why:

.Nm
reserves the last sector of the device to store the label information.
If the device already contains a filesystem, glabel will overwrite the last sector possibly damaging the filesystem, and the filesystem may later overwrite the glabel sector.

markj marked 3 inline comments as done.

Try to address the review feedback

In D35326#800927, @imp wrote:
In D35326#800921, @imp wrote:

"You should not use glabel with any device you plan on putting a filesystem on"

might be better advise.

Huh? Did you mean "If glabel is used, the filesystem should be put on the glabel device, rather than both label and filesystem put on a the same underlying device."

(Or are you commenting on the quality or usefulness of glabel?)

I was being catty.... But your advise is much better. glabel steals a sector or two for it's labeling info, and so you need to use the glabel device. It's also why you can't usually label something after the filesystem is on there: these stolen sector will be fought over potentially.

This problem exists with any GEOM class that steals a sector or two for metadata. I had to fix an identical issue with a script at old $JOB where a gmirror would be created on a partition already containing a filesystem. And most of the time it worked fine.

lib/geom/label/glabel.8
151

"should not" as in, "you can but really shouldn't"?

Right. It'll work, but we'll be in a situation where both the filesystem and geom_label think they "own" the last sector of the provider. Eventually they'll step on each other.

English LGTM. Waiting to hear from SMEs.

Can we move this along or do we still have to discuss something about it?

In D35326#835891, @bcr wrote:

Can we move this along or do we still have to discuss something about it?

I don't think there's anything to discuss currently? If there are no objections I'll commit in a couple of days.

Seems a bit wordy for a man page, but this manual page is chattier than most. The information is correct, however.

This revision is now accepted and ready to land.Sep 30 2022, 2:54 PM

If it's correct (I was waiting for that), English LGTM.