> From: Andor Daam [mailto:andor.daam@xxxxxxxxxxxxxx] > Subject: Re: (un)loadable module support for zcache > > 2012/3/8 Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> > > > > > From: Florian Schmaus [mailto:fschmaus@xxxxxxxxx] > > > Subject: Re: (un)loadable module support for zcache > > > > > > 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. > > We already thought of removing the matching pointer, whenever a filesystem is > unmounted. Great! > 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. Hi Andor -- Until now, cleancache_invalidate_fs was only called for garbage collection so it didn't really matter. Since, after you work is done, a missed call to cleancache_invalidate_fs has the potential to cause data corruption, it's probably best to be paranoid and verify. > Is it not certain that this function is always called? I *think* it should always be called, but I am not a filesystem expert. It might be worth asking the question on a filesytem mailing list (or on the individual lists for ext3/4, ocfs2, btrfs): "Is it ever possible for a superblock for a mounted filesystem to be free'd without a previous call to unmount the filesystem?" And you might want to check the call points for cleancache_invalidate_fs (in each of the filesystems) to see if there are error conditions which would skip the call to cleancache_invalidate_fs. Alternately, if you generate and keep track of a "fake pool id" and map it (after the backend registers) to a real pool id, I think there's no risk. However, I agree your solution is more elegant so as long as you verify that there is no chance of data corruption, I am OK with your solution. Dan _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel
