[systemd-devel] [PATCH] udev: Adding zram to inappropriate block device

[Zbigniew Jędrzejewski-Szmek]

Patch applied.

On Mon, Feb 03, 2014 at 10:33:37AM +0000, "Jóhann B. Guðmundsson" wrote:
> On 02/03/2014 09:36 AM, Holger Schurig wrote:
> >>with unit type ending in .zswap
> >No, not another unit type. Instead better amend .swap unit types to
> >also know about ZRAM.
> >
> >However, isn't this a bit early? Shouldn't move ZRAM first move out of staging?
> 
> Ofcourse but when it does move out of staging we could have sorted
> this implementation detail out which basically boils down to where
> to set the partition sizes for the zram partitions (
> tmpfiles.d/zram-conf or /etc/zram.d/zram-conf )
> 
> Do we want a script that basically just set this size based on
> available memory per core in the udev rule.
> 
> factor=25
> num_cpus=$(grep -c processor /proc/cpuinfo)
> memtotal=$(grep MemTotal /proc/meminfo | sed 's/[^0-9]\+//g')
> mem_by_cpu=$(($memtotal/$num_cpus*$factor/100*1024))
> echo $mem_by_cpu

[Side note: I'm reading Documentation/blockdev/zram.txt...
It says "1. modprobe zram num_devices=4". I can't help thinking that
we went over this with /dev/loop-control and others... Since this
is a new interface, why does it repeat the same pitfall of not
having a control device?]

Wouldn't it be simplest to have a parameter in /etc/fstab, like
x.zram-disk-size=XXX, which swapon would write to /sys/block/.../disksize?
This would make everything centralized and "synchronous" from the point
of view of the administrator.

Lennart Poettering wrote:
> Quite frankly, I don't really see what the point is of involving a
> fake block device for this... I am happy to generically support stuff
> that makes sense, but this really and totally doesn't. It's a
> completely broken API.
You can use those devices also for other things... At some level
it makes sense to provide this generic functionality instead of
complicating other subsystems.

Zbyszek