Re: filesystem labels?
- Reply: Polytropon : "Re: filesystem labels?"
- In reply to: Polytropon : "Re: filesystem labels?"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Fri, 14 Apr 2023 04:42:27 UTC
> 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. === >> I managed to apply a gpt label to my new partition that I >> created using only “gpart” >> >> The handbook mentions glabel labels, and tunefs labels, but >> says nothing about GPT labels. > > GPT labels are specific to GPT partitioning scheme (as > opposed to MBR partitioning, either as "dedicated mode" > with bare partitions, or "DOS mode" with partitions > inide slices). Because today you're probably going to > use GPT partitioning, GPT labels can be used without > any problem. Labels applied to MBR-style partitions > can be both glabel or UFSIDs. 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. 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? >> I’ve seen some more complete posts on the forums >> (i.e. https://forums.freebsd.org/threads/how-to-label-partitions.64380/) >> but they still don’t show the full picture of what >> labels are usable where, by what and which. > > Allow me to try to help with this problem: > > GPT partitioning: > devices: /dev/da0p1, /dev/da0p2, ... > tool: gpart > label: GPT label > location: /dev/gpt/ > MBR partitioning: > tools: gpart (traditional: fdisk, disklabel) > dedicated partitioning: > devices: /dev/da0a, /dev/da0b, ... > tool: glabel > label: glabel > location: /dev/label/ > applied to FS (instead of partition): > tools: newfs, tunefs > label: UFS label > location: /dev/ufs/ > -or- > tool: none > label: UFSID > location: /dev/ufsid/ > DOS style ("primary DOS partitions"): > devices: /dev/da0s1a, da0s1b, ... /dev/da1s1a, ... > tools and labels as above > > My very own summary is: When you setup disks, use GPT. > Use MBR only if you have a good reason to. :-) > > Of course you _can_ apply a UFS label or use a UFSID > for a UFS filesystem in a GPT partition, but that's > not really neccessary because you can already label > the partition itself. > > > >> Is there a good primer people know of of what the various >> types are, fully, which are supported in fstab, which work >> with ZFS only, and the like? > > Not that I'm aware of, but please compare: > > https://docs.freebsd.org/en/books/handbook/geom/#geom-glabel > > https://people.freebsd.org/~rodrigc/doc/data/doc/en_US.ISO8859-1/books/handbook/bsdinstall-partitioning.html > > http://wonkity.com/~wblock/docs/html/disksetup.html > > > >> 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 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. 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 :) -Dan