Discussion:
swapon vs GEOM labels
(too old to reply)
Stephane Rochoy
2024-10-21 09:21:47 UTC
Permalink
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?

Regards,
--
Stéphane Rochoy
O: Stormshield


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Warner Losh
2024-10-21 09:52:58 UTC
Permalink
On Mon, Oct 21, 2024 at 3:40 AM Stephane Rochoy <
Post by Stephane Rochoy
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
# sysctl vm.nswapdev
vm.nswapdev: 0
# swapctl -l
# 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
Stephane Rochoy
2024-10-22 06:40:36 UTC
Permalink
On Mon, Oct 21, 2024 at 3:40 AM Stephane Rochoy
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
# sysctl vm.nswapdev
vm.nswapdev: 0
# swapctl -l
# 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.
Well, I have to admit I'm a bit disappointed by the fact labels
don't completely mimic devices.

What I'm trying to achieve is to provide some sort of hardware
abstraction. I wrote a command that is responsible for probing
hardware and expose the fact that, e.g., an USB memstick is
available, a read/write SD card is inserted, etc…

My first attempt was to use symlinks in /dev/. The problem with
this approach is that GEOM don't seems to dereference them. For
example, if I have /dev/sdcard → /dev/da0, I cannot do things like
`geom
disk list sdcard`. IOW, the GEOM API is defeated by symlinks.

That's why I'm playing with labels.

If symlinks and labels are not well suited for that, do you know
of some alternative I could look at?

Regards,
--
Stéphane Rochoy
O: Stormshield


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...