geom labels as aliases

From: Andriy Gapon <avg_at_FreeBSD.org>
Date: Wed, 29 Sep 2021 11:37:48 +0300
For an introduction, I never liked consequences of GEOM labels being implemented 
as geoms.  And I specifically do not mean explicitly created labels via glabel 
create / label.  I mean GEOM labels based on partition and filesystem labels, 
disk IDs, etc,  And I don't like things such as opening a device via one label 
spoiling other labels.

So, I've been reading through some recent-ish changes by Warner for GEOM aliases 
and I've got this (maybe not so) bright idea, what if those labels were 
implemented as aliases.  Would that work?  Would that require a lot of work?

I did a quick hack as a proof of concept.
The change is quite small.

diff --git a/sys/geom/label/g_label.c b/sys/geom/label/g_label.c
index 1df7e799b014..72b97d314de4 100644
--- a/sys/geom/label/g_label.c
+++ b/sys/geom/label/g_label.c
_at__at_ -418,12 +418,15 _at__at_ g_label_taste(struct g_class *mp, struct g_provider *pp, 
int flags __unused)
  		if (label[0] == '\0')
  			continue;
  		if (g_labels[i] != &g_label_generic) {
-			mediasize = pp->mediasize;
+			if (g_label_is_name_ok(label)) {
+				g_provider_add_alias(pp, "%s%s",
+				    g_labels[i]->ld_dirprefix, label);
+			}
  		} else {
  			mediasize = pp->mediasize - pp->sectorsize;
+			g_label_create(NULL, mp, pp, label,
+			    g_labels[i]->ld_dirprefix, mediasize);
  		}
-		g_label_create(NULL, mp, pp, label,
-		    g_labels[i]->ld_dirprefix, mediasize);
  	}
  	g_access(cp, -1, 0, 0);
  end:

This seems to work in a basic smoke test of just booting up with the change.

root_at_freebsd:~ # cat /etc/fstab
# Custom /etc/fstab for FreeBSD VM images
/dev/gpt/rootfs   /       ufs     rw      1       1
/dev/gpt/swapfs  none    swap    sw      0       0
/dev/gpt/efiesp /boot/efi       msdosfs     rw      2       2
root_at_freebsd:~ # mount
/dev/gpt/rootfs on / (ufs, local, soft-updates)
devfs on /dev (devfs)
/dev/gpt/efiesp on /boot/efi (msdosfs, local)

root_at_freebsd:~ # gpart show
=>       3  20971509  ada0  GPT  (10G)
          3       127     1  freebsd-boot  (64K)
        130     66584     2  efi  (33M)
      66714   2097152     3  freebsd-swap  (1.0G)
    2163866  18807646     4  freebsd-ufs  (9.0G)

=>     63  2097089  ada1  MBR  (1.0G)
        63        1        - free -  (512B)
        64  2097088     1  freebsd  (1.0G)
root_at_freebsd:~ # gpart show -l
=>       3  20971509  ada0  GPT  (10G)
          3       127     1  bootfs  (64K)
        130     66584     2  efiesp  (33M)
      66714   2097152     3  swapfs  (1.0G)
    2163866  18807646     4  rootfs  (9.0G)

=>     63  2097089  ada1  MBR  (1.0G)
        63        1        - free -  (512B)
        64  2097088     1  (null)  (1.0G)

root_at_freebsd:~ # find /dev -type l -ls | column -t
...
91   0  lrwxr-xr-x  1  root  wheel  7   Sep  29  08:00  /dev/diskid/DISK-QM00013 
                         ->  ../ada0
95   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/diskid/DISK-QM00013p1                       ->  ../ada0p1
100  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/diskid/DISK-QM00013p2                       ->  ../ada0p2
104  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/diskid/DISK-QM00013p3                       ->  ../ada0p3
110  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/diskid/DISK-QM00013p4                       ->  ../ada0p4
112  0  lrwxr-xr-x  1  root  wheel  7   Sep  29  08:00  /dev/diskid/DISK-QM00015 
                         ->  ../ada1
114  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/diskid/DISK-QM00015s1                       ->  ../ada1s1
93   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/gptid/2313a319-9911-11eb-bf4c-002590ec5bf2  ->  ../ada0p1
98   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/gptid/2313a323-9911-11eb-bf4c-002590ec5bf2  ->  ../ada0p2
102  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/gptid/2313a328-9911-11eb-bf4c-002590ec5bf2  ->  ../ada0p3
108  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/gptid/2313a32d-9911-11eb-bf4c-002590ec5bf2  ->  ../ada0p4
94   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/gpt/bootfs 
                          ->  ../ada0p1
99   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/gpt/efiesp 
                          ->  ../ada0p2
103  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/gpt/swapfs 
                          ->  ../ada0p3
109  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/gpt/rootfs 
                          ->  ../ada0p4
97   0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/msdosfs/EFISYS 
                          ->  ../ada0p2
106  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00  /dev/ufs/rootfs 
                          ->  ../ada0p4
107  0  lrwxr-xr-x  1  root  wheel  9   Sep  29  08:00 
/dev/ufsid/6070152a39c33388                      ->  ../ada0p4

root_at_freebsd:~ # diskinfo -v /dev/diskid/DISK-QM00015
/dev/diskid/DISK-QM00015
         512             # sectorsize
         1073741824      # mediasize in bytes (1.0G)
         2097152         # mediasize in sectors
         0               # stripesize
         0               # stripeoffset
         2080            # Cylinders according to firmware.
         16              # Heads according to firmware.
         63              # Sectors according to firmware.
         QEMU HARDDISK   # Disk descr.
         QM00015         # Disk ident.
         ahcich1         # Attachment
         Yes             # TRIM/UNMAP support
         Unknown         # Rotation rate in RPM
         Not_Zoned       # Zone Mode

Of course, the change can break existing scripts / tools that count on labels 
having their own geoms.

Also, it can be argued that it would be better to create such symbolic links in 
userland.  It should be easy to port the label tasting code to userland and hook 
it to devd events.  That should cover all use cases except for the root filesystem.

Finally, I haven't tested glabel create / label yet, so the change may need some 
more work in that area.

What is your opinion?
Is this something worth pursuing?

Thank you!
-- 
Andriy Gapon
Received on Wed Sep 29 2021 - 08:37:48 UTC

Original text of this message