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
@@ -418,12 +418,15 @@ 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@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@freebsd:~ # mount
/dev/gpt/rootfs on / (ufs, local, soft-updates)
devfs on /dev (devfs)
/dev/gpt/efiesp on /boot/efi (msdosfs, local)
root@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@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@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@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
