On 03/05/12 17:57, Dan Magenheimer wrote:
I think the answer here is for cleancache (and frontswap) to
support "lazy pool creation". If a backend has not yet
registered when an init_fs/init call is made, cleancache
(or frontswap) must record the attempt and generate a valid
"fake poolid" to return. Any calls to put/get/flush with
a fake poolid is ignored as the zcache module is not
yet loaded. Later, when zcache is insmod'ed, it will attempt
to register and cleancache must then call the init_fs/init
routines (to "lazily" create the pools), obtain a "real poolid"
from zcache for each pool and "map" the fake poolid to the real
poolid on EVERY get/put/flush and on pool destroy (umount/swapoff).
We were thinking about how to make cleancache and frontswap able to cope
with the mounting of filesystems and running of swapon when there is no
backend registered without adding an indirection caused by a fake pool
id map.
We figured a way to deal with this in cleancache would be to store the
struct super_block pointers in an array for every call to init_fs and
the uuids and struct super_blocks pointers in different arrays for every
call to init_shared_fs. When a filesystem unmounts before a backend is
registered, its entries in the respective arrays are removed.
While no backend is registered, the put_page() and invalidate_page() are
ignored and get_page() fails. As soon as a backend registers the init_fs
and init_shared_fs functions are called for the struct super_block
pointers (and uuids) stored in the according arrays.
For frontswap we are aiming for a similar approach by remembering the
types for every call to init and failing put_page() and ignoring
get_page() and invalidate_page().
Again, when a backend registers init is called for every type stored.
This should allow backends to register with cleancache and frontswap
even after the mounting of filesystems and/or swapon is run. Therefore
it should allow zcache to be insmodded. This would be a first step to
allow rmmodding of zcache aswell.
Is this approach feasible?
Stefan, Florian, and Andor
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
