[dm-devel] [Question] dm-cache table

[Joe Thornber]

On Wed, Nov 27, 2013 at 10:54:04AM +0900, Akira Hayakawa wrote:
> Joe,
> 
> > On Mon, Nov 25, 2013 at 07:54:39PM +0900, Akira Hayakawa wrote:
> >> If it accepted migrate_threshold in .ctr and the parameter
> >> changed later. The actual value and what is seen in table
> >> become inconsistent right? Is this intentionally designed?
> > 
> > No, this is a bug.
> 
> So, the table design should be fully consistent with the actual values?

I guess the status should show what's running, and the table line
should show what was originally loaded.  The problem we have here is
that original table can go out of date and mislead any volume managers
that are relying on it; I really would like to keep the following
sequence a logical noop for all targets:

  - load table
  - run for a bit
  - read table via STATUS ioctl call
  - load table just read
  - switch to newly loaded table

Putting those tunables on the target line and then having messages to
change them obviously breaks this (though not in a data loss way).

The other option would be to store the tunables in the metadata, and
have them only changed via messages (not on the target line).  The
draw back with this approach is it puts extra work on the userland
volume management software; either they end up duplicating these
settings in their own metadata, or have to be able to query them from
the metadata (remember the volume may not be active).  I suggest you
go with this approach for now.

- Joe