[systemd-devel] [PATCH] udev: Adding zram to inappropriate block device
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Wed Feb 5 18:58:59 PST 2014
On Thu, Feb 06, 2014 at 03:27:07AM +0100, Greg KH wrote:
> On Thu, Feb 06, 2014 at 01:31:37AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
> > 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?]
>
> We can always change this now, quick, before 3.14 is out.
>
> What would a control device help with here?
Right now you have to decide before loading the module how many
devices you want. And also when trying to use a device (any device),
you have to look for one. The same issues as with loop.
> > 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.
>
> Module paramaters are under control of the admin, but they are a mess,
> I agree.
Zbyszek
More information about the systemd-devel
mailing list