Re: filesystem labels?

On Thu, 13 Apr 2023 21:42:27 -0700, Dan Mahoney (Ports) wrote:
> 
> 
> > On Apr 13, 2023, at 2:17 AM, Polytropon <freebsd@edvax.de> wrote:
> > 
> > On Wed, 12 Apr 2023 08:58:22 -0700, Dan Mahoney (Ports) wrote:
> >> I find that the handbook mentions glabel labels, but several
> >> other places say don’t use them.
> > 
> > For example?
> > 
> > THis is a honest question, because in my experience glabels
> > are a common solution for disk labelling.
> 
> Warren Block (see the wonkitty link below?  Same person.) said
> in this old post to avoid it if you can:
> 
> https://forums.freebsd.org/threads/odd-dax-device-mapping-in-freebsd-9-1-rc1.34676/
> 
> It’s also specific not only to an OS type, but also a fliesystem
> type, whereas if you’re using GPT disks.

Sorry, yes, stupid before input. ;-)

GPT labels (!) are today's typical solution, because they
are "already included" with GPT partitioning, and that
partitioning scheme is the one to use today, especially
in combination with EFI. Using MBR partitioning or no
partitioning at all should only be done if you have a
good reason _not_ to use GPT.

As I mentioned, all other labelling mechanisms (glabel,
disklabel, UFS label, UFSID) are of course supported,
so if you want to use them, it will surely work. The
tool glabel can be seen as being part of the suite of
glabel, gmirror, gstripe, gconcat, gvinum, gjournal
and "the other GEOM stuff".



> Right now, the problem I’ve found is that even though I just
> added a new device, and labeled it, it doesn’t show up in
> /dev/gpt/anything — and even /dev/gpt doesn’t exist, despite
> having previous GPT disks in the system, at boot.  The new
> drive doesn’t show in /dev/gpt even after a reboot.

As /dev is dynamically generated, it will appear as soon
as the disk logical drivers require it. The support has
to be in the kernel, but it's the default anyway. Sometimes
it seems to be required to "taste" a drive:

	# true > /dev/da1

This looks dangerous, but is supposed to be the correct
way, especially when using USB memory sticks or SD cards.
This causes the system to generate all neccessary files
in /dev.



> There are mentions of a number of sysctls that one *can* set,
> but not a great list of what they do.
> 
> root@collect-us:/home/dmahoney # sysctl -a | grep geom.label
> kern.features.geom_label: 1
> kern.geom.label.disk_ident.enable: 0
> kern.geom.label.gptid.enable: 1
> kern.geom.label.gpt.enable: 1
> kern.geom.label.ufs.enable: 1
> kern.geom.label.ufsid.enable: 1
> kern.geom.label.reiserfs.enable: 1
> kern.geom.label.ntfs.enable: 1
> kern.geom.label.msdosfs.enable: 1
> kern.geom.label.iso9660.enable: 1
> kern.geom.label.flashmap.enable: 1
> kern.geom.label.ext2fs.enable: 1
> kern.geom.label.debug: 0
> 
> What manpage would document any of the above?

You can read a short description using

	# sysctl -d kern.geom.label

Also see "man 8 glabel". A full (?) list of label-related
tunables can be found here:

	https://gist.githubusercontent.com/visualblind/8856820034ecaa2b4aa8b1600baa90ed/raw/846edd44a57576b3355aae543fed882d30b84949/sysctl-tunables

I don't know where to find that information on an
installed system though...



> >> Or should I just keep on using /dev/daX in fstab?
> > 
> > Nothing wrong with that in a static environment, i. e.,
> > one where you can safely predict which devices wiill be
> > detected in which order to conclude what their device
> > filenames will be. Otherwise, go with GPT labels.
> 
> In this particular setup, I had a virtual machine with three
> disks, one of which was slated to be removed.  VMWare presents
> things to the SCSI bus, in the order they’re added ot the system:
> 
> Virtual Disk 1: /dev/da0
> Virtual Disk 2:/dev/da1
> Virtual Disk 3:/dev/da2

Yes, that is the correct way and to be expected.



> What happens when I shut down, remove that second device,
> and reboot?  Disk 3 gets renumberd to disk 2, and gets seen
> as da1.
> 
> That’s my use case.  Using /dev/daX in here is always suceptible
> to that problem.

Correct, and that is where labels are the best solution.
As you probably have partitioned your virtual disk devices
with GPT (because, why would you use MBR?), use GPT labels,
which will be listed in /dev/gpt. Use those in /etc/fstab
instead of the logical device names, so for example instead
of /dev/ada0p2, use /dev/gpt/sysroot; /dev/ada0p2 becomes
/dev/gpt/swapspace (or whatever name you assigned).

NB: Dealing with gpart partition creation and destruction
sometimes requires you to set

	# sysctl kern.geom.debugflags=16

in order to override some security mechanisms which could
interfere with what you're intending. But don't ask me where
this has been properly documented... ;-)



> But…when the device entries don’t show up, either immediately,
> and on reboot, and the manpages don’t tell me how to rescan
> the thing, then I turn to -questions :)

At least after a system reboot the labels should be
visible to the system (or after "re-tasting", see above).
Verify that you have successfully (!) written the labels
by using

	# gpart list

and check the partition(s) for "label:" entries. Each
provider should have received one. For example:

	# gpart list | grep -e "Name" -e "label"
	1. Name: ada0p1
	   label: biosboot
	2. Name: ada0p2
	   label: sysroot
	3. Name: ada0p3
	   label: swapspace

This all of course depends on how you've created your
partitions.


-- 
Polytropon
Magdeburg, Germany
Happy FreeBSD user since 4.0
Andra moi ennepe, Mousa, ...