[dm-devel] dm-cache policy mq: promotion very picky?

[Joe Thornber]

On Tue, May 14, 2013 at 11:16:55AM -0700, Darrick J. Wong wrote:
> On Tue, May 14, 2013 at 02:44:53PM +0100, Joe Thornber wrote:
> > On Mon, May 13, 2013 at 11:23:04PM +0200, Pierre Beck wrote:
> > > Maybe I'm misunderstanding how the heuristics work - what makes mq
> > > pick a block for promotion?
> > 
> > Hi Pierre,
> > 
> > The mq policy is indeed very picky.  The first thing I'd suggest is
> > you pick up my latest patches if you haven't already:
> > 
> > http://device-mapper.org/patches/3.10/
> 
> Hm, it looks like all but two of the dmcache patches are in.  The two patches
> to mq aren't (yet) there.

y, unfortunately there's a fixme in there that frightened Alasdair,
and I don't have any free capacity to spend on dm-cache atm.

> > If you start with a discarded device (eg, you've run mkfs).  Then the
> > cache should fill up v. quickly with my latest patches.  Perhaps it
> > would be worth verifying this before you start investigating the
> > effects of sequential io?
> 
> I'm also curious about what happens if, say, you have a discard-enabled
> zerofree that can "discard" just the unallocated blocks.  That probably only
> helps if you can discard pieces big enough to fit one of dmcache's discard
> regions, right?

Yep.  But your fs will be trying to reduce fragmentation of free
space, so hopefully the pieces will be big enough.

- Joe