[maintainers of zram CC:ed, in order to alert them of this
incompatibility with a setup published by Gentoo and possibly picked up
by others]
[Pacho Ramos CC:ed as a person who asked about zram here before and who
can remove the non-working instruction listed at
http://wiki.gentoo.org/wiki/Zram#Using_existing_tools ]
I wrote:
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?
$ cat /etc/modules-load.d/zram.conf
zram
$ cat /etc/modprobe.d/zram.conf
options zram num_devices=4
$ cat /etc/udev/rules.d/01-zram.rules
KERNEL=="zram[0-9]", SUBSYSTEM=="block", DRIVER=="", ACTION=="add", ATTR{disksize}=="0",
ATTR{disksize}="1536M", RUN+="/sbin/mkswap $env{DEVNAME}"
$ grep zram /etc/fstab
/dev/zram0 none swap pri=10,discard 0 0
/dev/zram1 none swap pri=10,discard 0 0
/dev/zram2 none swap pri=10,discard 0 0
/dev/zram3 none swap pri=10,discard 0 0
09.06.2014 23:44, Kai Krakow wrote:
I didn't mean to persuade you but zram looks a little bit broken to me with
respect to configuration. So if zswap would be an option for you, it might
be the way to go instead of trying to work around quirks that cannot be
fixed easily. Of course, it is only an option if you also use a physical
swap device.
I don't use a physical swap device.
But anyway, the issue is now fully diagnosed, see below. It is indeed
zram-specific, and migrating to an alternative solution (such as
physical swap) would not hide any bug in systemd.
The systemd commit that introduces the regression to the above setup is:
commit 3ebdb81ef088afd3b4c72b516beb5610f8c93a0d
Author: Kay Sievers <k...@vrfy.org>
Date: Sun Apr 13 19:54:27 2014 -0700
udev: serialize/synchronize block device event handling with file locks
As an effect of this commit, systemd-udevd holds an open file descriptor
to the block device while processing rules for it. Thus, it writes to
the "disksize" sysfs attribute, while also having the fd to /dev/zram0
open. I could not trace by reading kernel sources why this fails to
change the disk size, but this failure somehow feels logical. I should
just stop setting the "disksize" attribute from an udev rule.
--
Alexander E. Patrakov
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
