> From: Florian Schmaus [mailto:fschmaus@xxxxxxxxx] > Subject: Re: (un)loadable module support for zcache > > 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? Hi Stefan, Florian, and Andor -- I do see a potential problem with this approach. You would be saving a superblock pointer and then using it later. What if the filesystem was unmounted in the meantime? Or, worse, what if it was unmounted and then the address of the superblock is reused to point to some completely different object? I think if you ensure that cleancache_invalidate_fs() is always called when a cleancache-enabled filesystem is unmounted, then in cleancache_invalidate_fs() you remove the matching superblock pointer from your arrays, then it should work. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
