From nobody Wed Sep 29 08:37:48 2021 X-Original-To: geom@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C632417EFA62 for ; Wed, 29 Sep 2021 08:37:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HK8rv5KNQz4lFm; Wed, 29 Sep 2021 08:37:51 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.88] (unknown [195.64.148.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 0C616277DD; Wed, 29 Sep 2021 08:37:50 +0000 (UTC) (envelope-from avg@FreeBSD.org) To: geom@freebsd.org From: Andriy Gapon Subject: geom labels as aliases Message-ID: <263983af-166b-f1c3-9e9a-c988727c1754@FreeBSD.org> Date: Wed, 29 Sep 2021 11:37:48 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: GEOM-specific discussions and implementations List-Archive: https://lists.freebsd.org/archives/freebsd-geom List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-geom@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N 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