From nobody Wed Sep 29 13:36:27 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 F08A517CF663 for ; Wed, 29 Sep 2021 13:36:29 +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 4HKHTT6Xx3z3lDw; Wed, 29 Sep 2021 13:36:29 +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 3774B2A446; Wed, 29 Sep 2021 13:36:29 +0000 (UTC) (envelope-from avg@FreeBSD.org) From: Andriy Gapon To: Warner Losh Cc: "freebsd-geom@FreeBSD.org" References: <263983af-166b-f1c3-9e9a-c988727c1754@FreeBSD.org> Subject: Re: geom labels as aliases Message-ID: Date: Wed, 29 Sep 2021 16:36:27 +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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 29/09/2021 16:20, Warner Losh wrote: > > > On Wed, Sep 29, 2021 at 2:37 AM Andriy Gapon > wrote: > > > 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. [snip] > > 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? > > > Conrad did something similar in 5b9b571cb and wound up reverting it. Too many > unforeseen issues, IIRC. Whoosh, I completely missed that commit. Unfortunately, the revert message it too terse: Revert r361838 Reported by: delphij I wonder if the reported problem was indeed too hard to overcome. However, I already see a number of issues in my simplistic change. First of all, removing obsolete aliases. I am thinking that maybe each "alias label" should still have a geom attached to the corresponding provider but without a (downstream) provider of its own. This way we can still receive events for spoiling, etc without introducing an alternative provider. We then can manipulate aliases in response to the upstream changes. Yeah, I see, a lot more work is needed. -- Andriy Gapon