Date: Fri, 14 Apr 2023 08:41:39 +0200 From: Polytropon <freebsd@edvax.de> To: "Dan Mahoney (Ports)" <freebsd@gushi.org> Cc: "questions@freebsd.org" <questions@FreeBSD.org> Subject: Re: filesystem labels? Message-ID: <20230414084139.8b2d91dc.freebsd@edvax.de> In-Reply-To: <82C015E0-71B9-4189-AA84-71219CA14E73@gushi.org> References: <A150BA2A-0669-4079-9978-44805FD4E851@gushi.org> <20230413111708.62d8c8d3.freebsd@edvax.de> <82C015E0-71B9-4189-AA84-71219CA14E73@gushi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230414084139.8b2d91dc.freebsd>