From nobody Wed Sep 29 17:40:17 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 5B6E817D533F for ; Wed, 29 Sep 2021 17:40:37 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: from mail-qt1-f171.google.com (mail-qt1-f171.google.com [209.85.160.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKNv82k9Tz4bHb; Wed, 29 Sep 2021 17:40:36 +0000 (UTC) (envelope-from cse.cem@gmail.com) Received: by mail-qt1-f171.google.com with SMTP id e16so3090897qts.4; Wed, 29 Sep 2021 10:40:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=EZX4FzcNUrt0nkA8VvhQ37yK2KBQgNqBMu/IbyJaUdg=; b=XjFq0haU2KCQIX219KDLID4tKqhd+C7CYddUlnDYExJGoRF9Tln3/oMzp38bQ9rUZa F++SYOuiEE8ACe/GRXvkGvlztQFl96i/aSMeMW6SNMyn14mxFlpkhfOQ37kh/BJz2QRp Fy8h5fEp6awkxrawB4jfxcSds9B73o6eR5B2kTbkPhcUmcPm2XEnaJwL9TT2plywTNcc EA2My3o+OQw3WwjeP5jmOWDs8XMOz9+9mW8zPVo8umuaiNA+/BlzwLbKVH764mhfoEut QwG/qTcPBE0QJQn57Dz8pSIusLE8zD0MDRo6/5NL23am0pVDLpzw5mkaoQQ9+uBnDHVM 32Bg== X-Gm-Message-State: AOAM530QasfizSB/ETLbKJD+cngy4QGgI8RRj1V1e9bXY3vl0veTh9jV TwJt1XivqOreLKdjnt+FZBRvrgcI77s= X-Google-Smtp-Source: ABdhPJz/7BnEG+950b0rGB6w26scaa7PzB48tOesBDVZqCZEYkrLGFX1i3dknwu6D2gV/zeJKVvB8w== X-Received: by 2002:ac8:111:: with SMTP id e17mr1416629qtg.34.1632937229456; Wed, 29 Sep 2021 10:40:29 -0700 (PDT) Received: from mail-yb1-f179.google.com (mail-yb1-f179.google.com. [209.85.219.179]) by smtp.gmail.com with ESMTPSA id h15sm280966qtq.41.2021.09.29.10.40.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Sep 2021 10:40:28 -0700 (PDT) Received: by mail-yb1-f179.google.com with SMTP id z5so7187027ybj.2; Wed, 29 Sep 2021 10:40:28 -0700 (PDT) X-Received: by 2002:a05:6902:70b:: with SMTP id k11mr1363292ybt.313.1632937228546; Wed, 29 Sep 2021 10:40:28 -0700 (PDT) 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 References: <263983af-166b-f1c3-9e9a-c988727c1754@FreeBSD.org> In-Reply-To: Reply-To: cem@freebsd.org From: Conrad Meyer Date: Wed, 29 Sep 2021 10:40:17 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: geom labels as aliases To: Warner Losh Cc: Andriy Gapon , "freebsd-geom@FreeBSD.org" Content-Type: multipart/alternative; boundary="00000000000072b72805cd25d3ec" X-Rspamd-Queue-Id: 4HKNv82k9Tz4bHb X-Spamd-Bar: ++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of csecem@gmail.com designates 209.85.160.171 as permitted sender) smtp.mailfrom=csecem@gmail.com X-Spamd-Result: default: False [2.05 / 15.00]; HAS_REPLYTO(0.00)[cem@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; REPLYTO_ADDR_EQ_FROM(0.00)[]; URI_COUNT_ODD(1.00)[3]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; FORGED_SENDER(0.30)[cem@freebsd.org,csecem@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[cem@freebsd.org,csecem@gmail.com]; ARC_NA(0.00)[]; TAGGED_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(0.94)[0.944]; NEURAL_HAM_LONG(-0.89)[-0.890]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.219.179:received,209.85.160.171:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.160.171:from]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --00000000000072b72805cd25d3ec Content-Type: text/plain; charset="UTF-8" https://lists.freebsd.org/pipermail/freebsd-current/2020-June/076210.html On Wed, Sep 29, 2021 at 07:20 Warner Losh wrote: > > > On Wed, Sep 29, 2021 at 7:36 AM Andriy Gapon wrote: > >> 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. >> > > Aliases are automatically removed when the providing geom goes away, > which as part of the tasting process automatically happens. > > I too wish the commit log was more complete, or had a pointer > to the exact details. > > Warner > > > --00000000000072b72805cd25d3ec--