[systemd-devel] systemd-213: regression with zram

[Kay Sievers]

On Mon, Jun 9, 2014 at 4:31 PM, Alexander E. Patrakov
<patrakov at gmail.com> wrote:
> 09.06.2014 20:11, Kay Sievers wrote:
>>
>> On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
>> <patrakov at gmail.com> wrote:
>>>
>>> 09.06.2014 19:26, Kai Krakow wrote:
>>>>
>>>>
>>>> Alexander E. Patrakov <patrakov at gmail.com> schrieb:
>>>>
>>>>> I have upgraded systemd from 212 to 213 on two my Gentoo boxes, and see
>>>>> the same regression here: zram swap space does not get activated. It
>>>>> looks like systemd tries to activate swap before the RUN+=mkswap part
>>>>> of
>>>>> the udev rule finishes.
>>>>>
>>>>> Here are the relevant lines from my configuration files. Are they
>>>>> indeed
>>>>> supposed to work, or were working only by pure luck?
>>>>
>>>>
>>>>
>>>> I switched to zswap because of this. This also looks more appropriate
>>>> for
>>>> my
>>>> workload. Maybe that's an option? At least if you do have a physical
>>>> swap
>>>> device (and in that cased I'd prefer zswap over zram).
>>>
>>>
>>> Please don't persuade me to hide or tolerate bugs. Even if zswap is more
>>> appropriate, I would like to get a comment on my zram issue from systemd
>>> maintainers.
>>
>>
>> I don't know of anybody working on systemd, using this
>> horrible-to-configure facility.
>>
>> I have no idea how stuff should work, but it *might* need some
>> ENV{SYSTEMD_READY}="0" fiddling.
>
>
> Let's decompose the question then. Maybe you know how at least one of the
> steps should work.
>
> 1. Is it correct that swap units created from /etc/fstab have dependencies
> on the devices mentioned in the first column? What kind of dependencies?
>
> 2. At what point in time (just after getting the uevent, after setting sysfs
> attributes, after running the RUN programs) is the dependency on the device
> node considered "satisfied"?

Just guessing around after looking at the rules you pasted, the devices
seem to be created unconditionally, and only later, after manual
configuration of the same devices be useful to the system. There is no
way for systemd to find that out, so systemd's dependencies on
configuration + devices + original uevents will unlikely work as
expected.

>> Module parameters to configure devices, sysfs attributes to
>> re-configure pre-created "dead devices", ...; given the fact, that it
>> is relatively recent technology, such terribly outdated and
>> have-always-been-broken concepts should never have been merged into
>> the kernel.
>
> A valid observation, but still - the semantics need to be documented (even
> if the document says "undefined") in systemd.device(5) or elsewhere WRT
> dependencies and ordering.

It looks like the same model as device-mapper, MD, loop; systemd has
no native idea about them and when to bring up devices. Original
device events are suppressed with SYSTEMD_READY=0, and new events
later re-triggered when the devices are usable for systemd to pick
them up.

Kay