RE: (un)loadable module support for zcache

[Dan Magenheimer <dan.magenheimer@oracle.com>]

> From: Andor Daam [mailto:andor.daam@googlemail.com]
> Subject: Re: (un)loadable module support for zcache
> 
> 2012/3/8 Dan Magenheimer <dan.magenheimer@oracle.com>
> >
> > > From: Florian Schmaus [mailto:fschmaus@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

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>