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

[Minchan Kim]

Hello,

Sorry for the late response.

On Tue, Jun 10, 2014 at 12:38:50AM +0600, Alexander E. Patrakov wrote:
> [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 <kay at 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.

If I parse your problem correctly, you meant that changing disksize is
failed while someone opens /dev/zram0?

I tried test which opens "/dev/zram0" with O_RDWR and sleep forever
and then echo $((512<<20)) > /sys/block/zram0/disksize is successful.
IOW, it's okay with me.

Could you describe your problem more clearly and can attach
what dmesg say?

FYI, for using zram, user should set disksize firstly(But it's okay
with opening /dev/zram0) and once you set disksize and want to change
disksize again, you should reset it via "echo 1 > /sys/block/zram0/reset".

Thanks.

> 
> -- 
> Alexander E. Patrakov