From nobody Mon Oct 21 09:52:58 2024 X-Original-To: freebsd-hackers@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 4XX9br0fbqz5Ymyt for ; Mon, 21 Oct 2024 09:53:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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 "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4XX9bq3sTHz4sgP for ; Mon, 21 Oct 2024 09:53:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pg1-x530.google.com with SMTP id 41be03b00d2f7-7d4fa972cbeso3324873a12.2 for ; Mon, 21 Oct 2024 02:53:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20230601.gappssmtp.com; s=20230601; t=1729504390; x=1730109190; darn=freebsd.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ovMVeBMdf3NjOVNR45jdBtFC4NUKwI4ZIeiiZTAMeYg=; b=XWaKPEdCZ9hEVN8bCZU1J73lvkSYAlhlZPzEm7rfdR0mZ/XhEu4eRhOXtpcbwRVckR Dsl5iazKHFWAMlcyg3A0uQnWegYk8me6utkOIJLZBPh3wXEZoyEC44FsfNW/46O/LMAW YR+ogBjqLHmSJ6W8joj/aV5eGbbeHvSNoi1E0FL/ZonAVOt/4NNCm0x4TdV7yHJ0ubYt +ttKXGJIexAfF/0mlcY+xC4RjYQV4iQTyrAYtpkxf22dqIkFxQWhQttXlViEKEmGBqb9 1X/oyoCUqIz20KMo2GDpewwtRWkT1eAoufL8mTpVscMVA5GVnxCJlyIBU9VocQVp43hv /qyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729504390; x=1730109190; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=ovMVeBMdf3NjOVNR45jdBtFC4NUKwI4ZIeiiZTAMeYg=; b=MRw6g4olMHk5+e9eYVWy0YpJboo9mEKmsR51vzNvEgppKgnzGYNsdqam8JNJFa6rYE rYy0QP78j7wE1XXtkieRfppahdehnArU5qLFRrbYXIcW5iKmaPuHhCa3ziDpZsCxRFgQ bUBRX5xj2pc0ye7LA6AoeAjiw+mJMMjekIYtfrHeOIH+rTrjiENA7JfTiAkQvGh29zm+ H9piNqrj13bTqUFaDs+UxKDh2wpqjMU+tdkG7tAfd1oy9ncvJAOSl1U0TmH1PZM2Gsel ZJLM3ozU7ArVgrCWacy1ZaCqo2CfMtlmMVZIA7HXuW3WGlFf101bDDRm4QhtN9Vp1U0Q fSlQ== X-Gm-Message-State: AOJu0YxcF9/sxu+s798FV4E2F7ZV56GcFQkdb8zY3+UTCH7nSRr1h/aC YzKKI4nflc7tR65VEoDHJ7632WGiW2e2Z4+P8S50StULViq6oMJYkx9IOEfKGPVuzxyZxbRnjrk LUu9a9bqGaUeZkrYev20hRoV3Z/OV+mKQcYMmfQ== X-Google-Smtp-Source: AGHT+IFi4W/csG1q3AR8+r98o20s8vO7UpH0kbJ8k+zSBj+9H0lct8XoKb+BCqBv+axhDXHm386B3rp5GTOTcySyIDs= X-Received: by 2002:a05:6a21:710a:b0:1d8:d880:2069 with SMTP id adf61e73a8af0-1d92c4ad296mr14046437637.3.1729504390136; Mon, 21 Oct 2024 02:53:10 -0700 (PDT) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org MIME-Version: 1.0 References: <86ttd5rdze.fsf@cthulhu.stephaner.labo.int> In-Reply-To: <86ttd5rdze.fsf@cthulhu.stephaner.labo.int> From: Warner Losh Date: Mon, 21 Oct 2024 03:52:58 -0600 Message-ID: Subject: Re: swapon vs GEOM labels To: Stephane Rochoy Cc: freebsd-hackers@freebsd.org Content-Type: multipart/alternative; boundary="000000000000cfe45d0624f99e61" X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4XX9bq3sTHz4sgP X-Spamd-Bar: ---- --000000000000cfe45d0624f99e61 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 21, 2024 at 3:40=E2=80=AFAM Stephane Rochoy < stephane.rochoy@stormshield.eu> wrote: > Hi Hackers, > > I'm playing with glabel(8) and swapon(8) but found a behavior that > is somewhat puzzling. > > I boot main (b88df1e893c4) with an USB memstick plugged. The > memstick is da0 and hold a freebsd-swap partition, da0p1. This > partition was given the `swap` label using `glabel label` (i.e., > an automatic label, stored somewhere into da0p1, AFAIK). > > # glabel status > Name Status Components > label/swap N/A da0p1 > > Then I give the whole device the `usbmemstick` label using `glabel > create` (i.e., a manual label, not stored anywhere). > > # glabel create usbmemstick da0 > # glabel status > Name Status Components > label/swap N/A da0p1 > label/usbmemstick N/A da0 > > What puzzle me is what happen when I enable swap: > > # sysctl vm.nswapdev > vm.nswapdev: 0 > # swapctl -l > Device: 1024-blocks Used: > # dumpon -l > /dev/null > # swapon /dev/label/usbmemstickp1 > # glabel status > Name Status Components > label/usbmemstick N/A da0 > # swapoff /dev/label/usbmemstickp1 > # glabel status > Name Status Components > label/usbmemstick N/A da0 > label/swap N/A label/usbmemstickp1 > > While swap is enabled, the `swap` label is no longer available. It > comes back when swap is disabled. > > Note that I also tried to enable swap using the automatic label > (i.e., `swap`). In such a case this is the `usbmemstick` label > that vanish. And the label is even not restored on `swapoff`. > > Is it the expected behavior? Am I doing something wrong? > This both makes sense to me, and seems wrong to me. When things are nested like this, it kinda makes sense that label/usbmemstickp1 shows up. geom doesn't enumerate everything and this seems to be a bit of an artifact. I'd expect both label/usbmemstickp1 and label/swap to be there. geom does odd things with devices that are open to keep others from opening them, and this may just be an artifact of this kinda weird behavior. Warner --000000000000cfe45d0624f99e61 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Oct 21, 2024 at 3:40=E2=80=AF= AM Stephane Rochoy <st= ephane.rochoy@stormshield.eu> wrote:
Hi Hackers,

I'm playing with glabel(8) and swapon(8) but found a behavior that
is somewhat puzzling.

I boot main (b88df1e893c4) with an USB memstick plugged. The
memstick is da0 and hold a freebsd-swap partition, da0p1. This
partition was given the `swap` label using `glabel label` (i.e.,
an automatic label, stored somewhere into da0p1, AFAIK).

=C2=A0 # glabel status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Name=C2=A0 Status=C2=A0 Components
=C2=A0 label/swap=C2=A0 =C2=A0 =C2=A0N/A=C2=A0 da0p1

Then I give the whole device the `usbmemstick` label using `glabel
create` (i.e., a manual label, not stored anywhere).

=C2=A0 # glabel create usbmemstick da0
=C2=A0 # glabel status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name=C2=A0 Status=C2=A0 Co= mponents
=C2=A0 =C2=A0 =C2=A0 =C2=A0 label/swap=C2=A0 =C2=A0 =C2=A0N/A=C2=A0 da0p1 =C2=A0 label/usbmemstick=C2=A0 =C2=A0 N/A=C2=A0 da0

What puzzle me is what happen when I enable swap:

=C2=A0 # sysctl vm.nswapdev
=C2=A0 vm.nswapdev: 0
=C2=A0 # swapctl -l
=C2=A0 Device:=C2=A0 =C2=A0 =C2=A0 1024-blocks=C2=A0 =C2=A0 =C2=A0Used:
=C2=A0 # dumpon -l
=C2=A0 /dev/null
=C2=A0 # swapon /dev/label/usbmemstickp1
=C2=A0 # glabel status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name=C2=A0 Status=C2=A0 Co= mponents
=C2=A0 label/usbmemstick=C2=A0 =C2=A0 N/A=C2=A0 da0
=C2=A0 # swapoff /dev/label/usbmemstickp1
=C2=A0 # glabel status
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Name=C2=A0 Status=C2=A0 Co= mponents
=C2=A0 label/usbmemstick=C2=A0 =C2=A0 N/A=C2=A0 da0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 label/swap=C2=A0 =C2=A0 =C2=A0N/A=C2=A0 label/u= sbmemstickp1

While swap is enabled, the `swap` label is no longer available. It
comes back when swap is disabled.

Note that I also tried to enable swap using the automatic label
(i.e., `swap`). In such a case this is the `usbmemstick` label
that vanish. And the label is even not restored on `swapoff`.

Is it the expected behavior? Am I doing something wrong?

This both makes sense to me, and seems wrong to me.=C2=A0= When
things are nested like this, it kinda makes sense that labe= l/usbmemstickp1
shows up. geom doesn't enumerate everything a= nd this seems to be a bit
of an artifact. I'd expect both lab= el/usbmemstickp1 and label/swap to be there.
geom does odd things= with devices that are open to keep others from opening
them, and= this may just be an artifact of this kinda weird behavior.

<= /div>
Warner
--000000000000cfe45d0624f99e61--