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 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 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-- From nobody Wed Sep 29 20:15:42 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 9DBB917E2A43 for ; Wed, 29 Sep 2021 20:15:45 +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 4HKSL949z3z4pW5; Wed, 29 Sep 2021 20:15:45 +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 DB6752CE60; Wed, 29 Sep 2021 20:15:44 +0000 (UTC) (envelope-from avg@freebsd.org) From: Andriy Gapon To: Xin LI Cc: Warner Losh , "freebsd-geom@FreeBSD.org" , "Conrad E. Meyer" References: <263983af-166b-f1c3-9e9a-c988727c1754@FreeBSD.org> Subject: Re: geom labels as aliases Message-ID: <183ab48b-bb57-5ce7-c5be-84f663f9b3de@FreeBSD.org> Date: Wed, 29 Sep 2021 23:15:42 +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 20:28, Xin LI wrote: > For context, the discussion was at > https://lists.freebsd.org/pipermail/freebsd-current/2020-June/thread.html#76210 . My takeaway[*], perhaps incorrect, from reading that is that the problem is with this check in g_label_taste(): /* Skip providers that are already open for writing. */ if (pp->acw > 0) return (NULL); On the one hand this looks reasonable, on the other hand if a disk is open for writing it does not mean that its can change (it cannot). If a partition is open for writing it does not mean that its label can change (it cannot unless its container is open for writing as well). It does not necessarily mean that a filesystem label will change (although it can). We probably need a better mechanism to communicate label changes than the access bits alone. As a quick solution, perhaps we could add a flag that allows a label class to declare that it can safely test a provider even when it's open for writing? [*] I made my conclusion based on this snippet: > ZFS gets an exclusive hold of 'ada1p2' despite the pool is carefully created > to use /dev/diskid/p2 instead of ada1p2. ... > However, this will prevent GEOM from properly creating > /dev/diskid/. -- Andriy Gapon From nobody Wed Sep 29 20:46:55 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 7112317E4686 for ; Wed, 29 Sep 2021 20:46:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HKT272dF0z4rXw for ; Wed, 29 Sep 2021 20:46:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 375731F18F for ; Wed, 29 Sep 2021 20:46:55 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 18TKktZ9005179 for ; Wed, 29 Sep 2021 20:46:55 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 18TKktn1005178 for geom@FreeBSD.org; Wed, 29 Sep 2021 20:46:55 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: geom@FreeBSD.org Subject: [Bug 258787] geli leaks memory Date: Wed, 29 Sep 2021 20:46:55 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: geom@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258787 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|bugs@FreeBSD.org |geom@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Thu Sep 30 20:17:59 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 641A017DA842 for ; Thu, 30 Sep 2021 20:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HL4LH2LFGz4nQT for ; Thu, 30 Sep 2021 20:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id 2D98612061 for ; Thu, 30 Sep 2021 20:17:59 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 18UKHxBH053032 for ; Thu, 30 Sep 2021 20:17:59 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 18UKHxHu053031 for geom@FreeBSD.org; Thu, 30 Sep 2021 20:17:59 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: geom@FreeBSD.org Subject: [Bug 258787] geli leaks memory Date: Thu, 30 Sep 2021 20:17:59 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: glebius@FreeBSD.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: glebius@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated 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 X-ThisMailContainsUnwantedMimeParts: N https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258787 Gleb Smirnoff changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|geom@FreeBSD.org |glebius@FreeBSD.org Status|New |In Progress --=20 You are receiving this mail because: You are the assignee for the bug.= From nobody Sun Oct 3 21:00:13 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 0B65217C4930 for ; Sun, 3 Oct 2021 21:00:14 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (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 "mxrelay.nyi.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HMx7d6Pdzz4WBg for ; Sun, 3 Oct 2021 21:00:13 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (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 did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id B7B144F35 for ; Sun, 3 Oct 2021 21:00:13 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 193L0DoF040644 for ; Sun, 3 Oct 2021 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 193L0DkP040643 for geom@FreeBSD.org; Sun, 3 Oct 2021 21:00:13 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <202110032100.193L0DkP040643@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: geom@FreeBSD.org Subject: Problem reports for geom@FreeBSD.org that need special attention Date: Sun, 3 Oct 2021 21:00:13 +0000 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: multipart/alternative; boundary="16332948135.0bbecB7A5.40234" Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: Y --16332948135.0bbecB7A5.40234 Date: Sun, 3 Oct 2021 21:00:13 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- In Progress | 218679 | [geli] add a verify command Open | 237269 | panic in glabel (g_label_destroy) stop after resi Open | 238814 | geom: topology lock being dropped in dumpconf of Open | 242747 | geli: AMD Epyc+GELI not using Hardware AES 4 problems total for which you should take action. --16332948135.0bbecB7A5.40234--