search

mfrw / compcache

Automatically exported from code.google.com/p/compcache
0 stars 0 forks source link

rzscontrol no longer works with 2.6.35 staging module #68

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Load module
2. rzscontrol /dev/ramzswap0 -i

What version of the product are you using? On what operating system?
2.6.35 and compache package 0.6.2.

Please provide any additional information below.
[  789.094783] ramzswap: num_devices not specified. Using default: 1
[  789.094795] ramzswap: Creating 1 devices ...
[  794.846677] ramzswap: Invalid ioctl 31236

It says invalid ioctl.

Original issue reported on code.google.com by D.G.Jan...@gmail.com on 4 Aug 2010 at 12:42

GoogleCodeExporter commented 9 years ago 
Issue 67 has been merged into this issue.

Original comment by nitingupta910@gmail.com on 4 Aug 2010 at 2:03

GoogleCodeExporter commented 9 years ago 
I'm aware of this rzscontrol incompatibility and Please do not use compcache 
driver from upstream Linux kernel. It lacks lots of changes which were done 
after that merge.

I will soon be releasing a new version of compcache that does not require 
rzscontrol and has many more improvements. I guess it will take significant 
amount of time to sync all these changes with mainline kernel.

Original comment by nitingupta910@gmail.com on 4 Aug 2010 at 2:09

GoogleCodeExporter commented 9 years ago 
For the new compcache version, you can checkout directly from repository:

    hg clone https://compcache.googlecode.com/hg/ compcache

The README file in the source root contains information on how to use it. Some 
of its features include (see Changelog for details):
 - Devices are now called /dev/zram<id> (<id> = 0, 1, 2 ...) instead of ramzswap since they can now handle any kind of I/O and not limited to use as swap.
 - Replaced ioctls with sysfs interface. So no need for separate tool like rzscontrol.
 - Percpu stats and buffers for improved scalability
 - Lots of other cleanups, minor fixes.

I could not spend much time testing it, so not releasing it as a separate 
tarball. Also, I will be out of this project for next 1 month approx., so 
expect delays for any replies/fixes etc.

Original comment by nitingupta910@gmail.com on 12 Aug 2010 at 6:27

GoogleCodeExporter commented 9 years ago 
Thanks! I'll check it out!

Original comment by D.G.Jan...@gmail.com on 12 Aug 2010 at 6:33

GoogleCodeExporter commented 9 years ago 
Works very nicely! Will you post that to lkml?
Great idea to make it usable for /tmp as well!

Original comment by D.G.Jan...@gmail.com on 12 Aug 2010 at 1:09

GoogleCodeExporter commented 9 years ago 
I posted it to lkml: http://lkml.org/lkml/2010/8/9/226
But it's getting lot of resistance from kernel developers. Lots of things yet 
to be worked out.

Original comment by nitingupta910@gmail.com on 12 Aug 2010 at 2:36

GoogleCodeExporter commented 9 years ago 
I see. But they seem to be lots of minor things and from a very positive stand 
point. I think they generally all like the code. It's just that they are 
(rightly) afraid there will be a lot of adoption and use of zram and they want 
it to be well maintainable later.

Original comment by D.G.Jan...@gmail.com on 12 Aug 2010 at 2:45

GoogleCodeExporter commented 9 years ago 
Yes, most are minor things and that's positive side to it. But unfortunately 
going by all those suggestions will be time consuming and it will be quite some 
time before I can continue work on this project again. The second child 
project, zcache, is also expected to take a long time before mainline merge: 
http://lkml.org/lkml/2010/7/16/161

Original comment by nitingupta910@gmail.com on 12 Aug 2010 at 3:51

GoogleCodeExporter commented 9 years ago 
Yes, on zcache there seems to be more work to be done. But still this is all 
pretty impressive high end kernel work. And the code is good. It could be 
merged right away I guess. But I think both will be used a lot. It's not like 
writing a driver for some device nobody uses, this is more like tmpfs. 
Everybody might end up using these.
I've been wondering if it would be possible to use the fs of tmpfs on top or 
zram - sort of a ztmpfs, because I have a strong feeling a lot of the code of 
ext is unncessary for a ram fs and just slows it down. But if this was easy to 
be done someone probably would have done it a long time ago. I'm amazed I can't 
find any major criticism.

Original comment by D.G.Jan...@gmail.com on 12 Aug 2010 at 4:11

GoogleCodeExporter commented 9 years ago 
I mean not zcache itself, but cleancache.

Original comment by D.G.Jan...@gmail.com on 12 Aug 2010 at 4:35

GoogleCodeExporter commented 9 years ago 
rzscontrol is not required fir zram (to be released sometime). Closing the 
issue.

Original comment by nitingupta910@gmail.com on 29 Aug 2010 at 9:57