zram: device management utility needed

zram: device management utility needed

[Sami Kerola]

Hello,

Not so long ago Timofey has reached both util-linux[1] and kernel[2]
contributors with intention to make zram device management too.  I think
the proposal is good, and there should be distribution independent tool
like that.  Also such command fits fairly well to a scope of util-linux
package.  But a tool is only as good as kernel support of it is.  This
mail is a bit about both.

Existing proposal for zramctl[3], wrote by Timofey, does what I would
call great starting point.  It can resize zram device, select algorithm,
and set number of threads.  Unfortunately it cannot create or remove zram
devices.

The zram devices are not created by any sort of equipment appearing in a
bus so an method of creating new or removing existing devices will be
needed.  When the zram module is loaded it should create
/dev/zram-control device, that responds to ioctl() calls[4].  The calls
could be similar with /dev/loop-control[5], that allow adding or removing
specified device, and discover adding a free device.

This proposal would not affect the current initialization of the zram
devices[6].  It would be an addition to manage zram devices after kernel
module is loaded, of course each device separately and individually.  At
the moment adding a device requires removing the existing devices[7],
which can mean data loss, and at least unnecessary hassle when performing
a device addition task.

But before getting too exited and asking for ioctl() allocation, or
thinking too much about code, does an overall plan like this make sense? 
Is there an alternative that would be better than /dev/zram-control +
ioctl()'s?  Any other comments, better proposal, and so on?

Finally, Hats off to Timofey, you got the ball rolling getting the zram
devices being dynamic someday in future.

[1] http://www.spinics.net/lists/util-linux-ng/index.html#09781
[2] https://lkml.org/lkml/2014/7/17/272
[3] http://www.spinics.net/lists/util-linux-ng/msg09900.html
[4] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/ioctl-number.txt?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8
[5] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8#n1757
[6] such as: modprobe zram num_devices=4
[7] requires 'rmmod zram' which is not possible if any zram device is busy

-- 
Sami Kerola
http://www.iki.fi/kerolasa/

Re: zram: device management utility needed

[Sergey Senozhatsky]

Cc Jerome

Hello,

my quick thoughts on the topic. first, I'm not against, and we might have
something like this one day, but...

On (07/30/14 00:14), Sami Kerola wrote:
> Hello,
> 
> Not so long ago Timofey has reached both util-linux[1] and kernel[2]
> contributors with intention to make zram device management too.  I think
> the proposal is good, and there should be distribution independent tool
> like that.  Also such command fits fairly well to a scope of util-linux
> package.  But a tool is only as good as kernel support of it is.  This
> mail is a bit about both.
> 
> Existing proposal for zramctl[3], wrote by Timofey, does what I would
> call great starting point.  It can resize zram device, select algorithm,
> and set number of threads.  Unfortunately it cannot create or remove zram
> devices.
> 
> The zram devices are not created by any sort of equipment appearing in a
> bus so an method of creating new or removing existing devices will be
> needed.  When the zram module is loaded it should create
> /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> could be similar with /dev/loop-control[5], that allow adding or removing
> specified device, and discover adding a free device.
> 
> This proposal would not affect the current initialization of the zram
> devices[6].  It would be an addition to manage zram devices after kernel
> module is loaded, of course each device separately and individually.  At
> the moment adding a device requires removing the existing devices[7],
> which can mean data loss, and at least unnecessary hassle when performing
> a device addition task.

well, run-time data loss, assuming that fs has failed to read a page,
because e.g. zram has mistakenly discarded it, I believe, is out of this
topic. any other type of data loss is out of zram design. whenever user
decides to umount/reboot/etc., it's his/her sole responsibility to keep
the data, zram is not meant to help here.

uninitialised or reset (when unneeded) device *must* be almost free:
there are no zspool, fs, compression backend, etc. which means that
one can pre-allocated as many devices as he needs and init/reset devices
whenever required.

so the problem seems to be "we can do A, but it doesn't look very
convenient", rather than "we can't do A".

	-ss

> 
> But before getting too exited and asking for ioctl() allocation, or
> thinking too much about code, does an overall plan like this make sense? 
> Is there an alternative that would be better than /dev/zram-control +
> ioctl()'s?  Any other comments, better proposal, and so on?
> 
> Finally, Hats off to Timofey, you got the ball rolling getting the zram
> devices being dynamic someday in future.
> 
> [1] http://www.spinics.net/lists/util-linux-ng/index.html#09781
> [2] https://lkml.org/lkml/2014/7/17/272
> [3] http://www.spinics.net/lists/util-linux-ng/msg09900.html
> [4] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/ioctl-number.txt?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8
> [5] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8#n1757
> [6] such as: modprobe zram num_devices=4
> [7] requires 'rmmod zram' which is not possible if any zram device is busy
> 
> -- 
> Sami Kerola
> http://www.iki.fi/kerolasa/
> 

Re: zram: device management utility needed

[Minchan Kim]

On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> Hello,
> 
> Not so long ago Timofey has reached both util-linux[1] and kernel[2]
> contributors with intention to make zram device management too.  I think
> the proposal is good, and there should be distribution independent tool
> like that.  Also such command fits fairly well to a scope of util-linux
> package.  But a tool is only as good as kernel support of it is.  This
> mail is a bit about both.
> 
> Existing proposal for zramctl[3], wrote by Timofey, does what I would
> call great starting point.  It can resize zram device, select algorithm,
> and set number of threads.  Unfortunately it cannot create or remove zram
> devices.
> 
> The zram devices are not created by any sort of equipment appearing in a
> bus so an method of creating new or removing existing devices will be
> needed.  When the zram module is loaded it should create
> /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> could be similar with /dev/loop-control[5], that allow adding or removing
> specified device, and discover adding a free device.

Normally, dynamic management is good to have, I think but I didn't hear
strong requirement for that until now.
Why don't you change num_device param at module loading time?
I'd like to hear real scenario from whom are about to using that faeture
right now and what's the problem with num_device param.


> 
> This proposal would not affect the current initialization of the zram
> devices[6].  It would be an addition to manage zram devices after kernel
> module is loaded, of course each device separately and individually.  At
> the moment adding a device requires removing the existing devices[7],
> which can mean data loss, and at least unnecessary hassle when performing
> a device addition task.

If there is any holder of device, we shouldn't destroy the device.
It's doable.

> 
> But before getting too exited and asking for ioctl() allocation, or
> thinking too much about code, does an overall plan like this make sense? 
> Is there an alternative that would be better than /dev/zram-control +
> ioctl()'s?  Any other comments, better proposal, and so on?
> 
> Finally, Hats off to Timofey, you got the ball rolling getting the zram
> devices being dynamic someday in future.

I vote such standard tool to control each zram device's property but need
more thinking about dynamic device adding/removal.

> 
> [1] http://www.spinics.net/lists/util-linux-ng/index.html#09781
> [2] https://lkml.org/lkml/2014/7/17/272
> [3] http://www.spinics.net/lists/util-linux-ng/msg09900.html
> [4] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/ioctl/ioctl-number.txt?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8
> [5] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/block/loop.c?id=31dab719fa50cf56d56d3dc25980fecd336f6ca8#n1757
> [6] such as: modprobe zram num_devices=4
> [7] requires 'rmmod zram' which is not possible if any zram device is busy
> 
> -- 
> Sami Kerola
> http://www.iki.fi/kerolasa/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

-- 
Kind regards,
Minchan Kim

Re: zram: device management utility needed

[Karel Zak]

On Tue, Aug 05, 2014 at 11:00:24AM +0900, Minchan Kim wrote:
> On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> > The zram devices are not created by any sort of equipment appearing in a
> > bus so an method of creating new or removing existing devices will be
> > needed.  When the zram module is loaded it should create
> > /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> > could be similar with /dev/loop-control[5], that allow adding or removing
> > specified device, and discover adding a free device.
> 
> Normally, dynamic management is good to have, I think but I didn't hear
> strong requirement for that until now.

I guess that number of zram devices will be always relatively small
compare to /dev/loopN devices. It is not unusual that people use
systems with more than 256 loop devs, so /dev/loop-control makes a lot
of sense to keep the device management effective and simple.

> Why don't you change num_device param at module loading time?

If you have really many loopN devices than create all the nodes at
boot time means extra overhead (allocate nodes in kernel, events to
udev, create /dev files etc.).  The ioctl LOOP_CTL_* API also provides
LOOP_CTL_GET_FREE that returns unused device, so you don't have to
scan all the /dev/loopN devices to detect a free device.

> I'd like to hear real scenario from whom are about to using that faeture
> right now and what's the problem with num_device param.

Again, I don't think it's so important for zram as for loop devices.
All depends how people will use zram devices. We will see...

    Karel

-- 
 Karel Zak  <kzak@redhat.com>
 http://karelzak.blogspot.com

Re: zram: device management utility needed

[Minchan Kim]

On Tue, Aug 05, 2014 at 09:07:16AM +0200, Karel Zak wrote:
> On Tue, Aug 05, 2014 at 11:00:24AM +0900, Minchan Kim wrote:
> > On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
> > > The zram devices are not created by any sort of equipment appearing in a
> > > bus so an method of creating new or removing existing devices will be
> > > needed.  When the zram module is loaded it should create
> > > /dev/zram-control device, that responds to ioctl() calls[4].  The calls
> > > could be similar with /dev/loop-control[5], that allow adding or removing
> > > specified device, and discover adding a free device.
> > 
> > Normally, dynamic management is good to have, I think but I didn't hear
> > strong requirement for that until now.
> 
> I guess that number of zram devices will be always relatively small
> compare to /dev/loopN devices. It is not unusual that people use
> systems with more than 256 loop devs, so /dev/loop-control makes a lot
> of sense to keep the device management effective and simple.
> 
> > Why don't you change num_device param at module loading time?
> 
> If you have really many loopN devices than create all the nodes at
> boot time means extra overhead (allocate nodes in kernel, events to
> udev, create /dev files etc.).  The ioctl LOOP_CTL_* API also provides
> LOOP_CTL_GET_FREE that returns unused device, so you don't have to
> scan all the /dev/loopN devices to detect a free device.

Thanks for the info!

> 
> > I'd like to hear real scenario from whom are about to using that faeture
> > right now and what's the problem with num_device param.
> 
> Again, I don't think it's so important for zram as for loop devices.
> All depends how people will use zram devices. We will see...

Yeb and we can do it when we see.

> 
>     Karel
> 
> -- 
>  Karel Zak  <kzak@redhat.com>
>  http://karelzak.blogspot.com

Re: zram: device management utility needed

[Sami Kerola]

On 5 August 2014 09:12, Minchan Kim <minchan@kernel.org> wrote:
> On Tue, Aug 05, 2014 at 09:07:16AM +0200, Karel Zak wrote:
>> On Tue, Aug 05, 2014 at 11:00:24AM +0900, Minchan Kim wrote:
>> > On Wed, Jul 30, 2014 at 12:14:42AM +0100, Sami Kerola wrote:
>> > > The zram devices are not created by any sort of equipment appearing in a
>> > > bus so an method of creating new or removing existing devices will be
>> > > needed.  When the zram module is loaded it should create
>> > > /dev/zram-control device, that responds to ioctl() calls[4].  The calls
>> > > could be similar with /dev/loop-control[5], that allow adding or removing
>> > > specified device, and discover adding a free device.
>> >
>> > Normally, dynamic management is good to have, I think but I didn't hear
>> > strong requirement for that until now.
>>
>> I guess that number of zram devices will be always relatively small
>> compare to /dev/loopN devices. It is not unusual that people use
>> systems with more than 256 loop devs, so /dev/loop-control makes a lot
>> of sense to keep the device management effective and simple.
>>
>> > Why don't you change num_device param at module loading time?
>>
>> If you have really many loopN devices than create all the nodes at
>> boot time means extra overhead (allocate nodes in kernel, events to
>> udev, create /dev files etc.).  The ioctl LOOP_CTL_* API also provides
>> LOOP_CTL_GET_FREE that returns unused device, so you don't have to
>> scan all the /dev/loopN devices to detect a free device.
>
> Thanks for the info!
>
>>
>> > I'd like to hear real scenario from whom are about to using that faeture
>> > right now and what's the problem with num_device param.
>>
>> Again, I don't think it's so important for zram as for loop devices.
>> All depends how people will use zram devices. We will see...
>
> Yeb and we can do it when we see.

Hi all,

Good to hear, and I am glad coding time was not wasted propose the
dynamic zram devices in form of patches.  And as it was said before who
knows how the user kind will end up using these devices, which may mean
in future reconsideration, but for now number of devices will only
follow module load time instruction.

I think the reasonable thing to do is to adjust documentation a little
bit.  Users should load number of devices they  need plus few spares to
avoid getting corner by inability to foresee future device needs.

-- 
Sami Kerola
http://www.iki.fi/kerolasa/