(un)loadable module support for zcache
Dan Magenheimer
dan.magenheimer at oracle.com
Thu Mar 8 17:07:22 UTC 2012
> From: Andor Daam [mailto:andor.daam at googlemail.com]
> Subject: Re: (un)loadable module support for zcache
>
> 2012/3/8 Dan Magenheimer <dan.magenheimer at oracle.com>
> >
> > > From: Florian Schmaus [mailto:fschmaus at gmail.com]
> > > 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
More information about the devel
mailing list