On Mon, Jun 9, 2014 at 4:31 PM, Alexander E. Patrakov
<patra...@gmail.com> wrote:
> 09.06.2014 20:11, Kay Sievers wrote:
>>
>> On Mon, Jun 9, 2014 at 4:02 PM, Alexander E. Patrakov
>> <patra...@gmail.com> wrote:
>>>
>>> 09.06.2014 19:26, Kai Krakow wrote:
>>>>
>>>>
>>>> Alexander E. Patrakov <patra...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
