[systemd-devel] [PATCH RFC] swap: use aliases to group swap units for same device

Kay Sievers kay at vrfy.org
Tue Oct 23 08:48:57 PDT 2012


On Tue, Oct 23, 2012 at 5:34 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> On Fri, 19.10.12 00:56, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:
>
>> A series of .swap units "following" one another are replaced with a
>> single unit with multiple names.
>>
>> The idea is to simplify things for the user: only one swap unit per
>> swap area. It shouldn't matter whether the swap area was activated by
>> systemd or by direct swapon invocation. The kernel name (from
>> /proc/swaps) is preferred, but if swap is configured through a unit
>> file and not active, that name will be used instead.
>>
>> The case where a swap unit refers (What=) to a symlink should behave
>> better than before.
>>
>> Note: this patch is goes on top of some cleanup patches that are
>> pretty boring and thus I'm not posting them, so it might not apply
>> cleanly.
>
> So here's the reason why we use the "following" scheme for htis, rather
> than just alias names. And that's simply because a name in /dev can
> refer to different things during runtime and we cannot model this with
> aliases.
>
> So, basically, if you plug in Disk X first, and Disk Y second, then a
> swap device symlink /dev/foobar might point to /dev/sda5. But if you
> plug them in in a different order, then /dev/foobar will point to
> /dev/sdb5, instead. So initially we have one swap device that is exposed
> as both /dev/sda5 + /dev/foobar, and then later one that is exposed as
> /dev/sdb5 + /dev/foobar. Now, if some component depends on /dev/sda5
> being enabled as swap, and another component that depends on
> /dev/foobar being enabled as swap, and we just alias the same object
> under both names, this will work fine first. But what happens if the
> swap device goes away and comes back as /dev/sdb5, now you have to split
> up the names again, since /dev/sda5 stays with the old device unit, but
> /dev/foobar has to be directed to the new one. And then you'd have to
> figure out which service depended on which unit name, and fix the dep
> tree. This basically means that we'd have to have to tracks deps as for
> names rather than units. But that would drastically complicate things.
>
> Instead we chose to let all .swap and .device units live independently
> under each name, but make them "follow" other units as needed, and
> truncate the "follow" chain when appropriate.
>
> In other words:
>
> - Unit aliases are useful where the same alias is always assigned to the
> same unit, and this never changes, except when "systemctl daemon-reload" is
> executed.
>
> - The "following" scheme is useful where an alias might dynamically be
> assigned to different units during runtime, and this can change at any
> time, without needing "systemctl daemon-reload".

As a background, it kind of mirrors what udev does with symlinks.
Multiple devices can claim the same symlink name at the same time,
while only one of them is created in /dev at a given time.

Which of the devices actually owns the currently created one in /dev
depends on the specified device priority. If no priority is given,
it's *usually* the device with the last active event.

When a device goes away, and with it the symlink that is the currently
created one, the symlink of the device with the next highest priority
gets created instead of the one that disappeared.

For every symlink in /dev, there is a stack of devices maintained,
which can claim the link. Every device change/event re-evaluates which
of the devices in the stack should actually get the created/active
link.

Cheers,
Kay


More information about the systemd-devel mailing list