2012/3/8 Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> > > > 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 We already thought of removing the matching pointer, whenever a filesystem is unmounted. As the comment to __cleancache_invalidate_fs in cleancache.c states that this function is called by any cleancache-enabled filesystem at time of unmount, we assumed that this function was actually always called upon unmount. Is it not certain that this function is always called? Andor _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
