Re: [Question] dm-cache table

[Akira Hayakawa <ruby.wktk@gmail.com>]

First of all, this is the current Writeboost's table line design:
writeboost <type> <backing dev> <cache dev>
           #optional args [optional args]
	   #tunable args [tunable args] 

There's a constraint.
Joe's device-mapper-test-suite uses table line output to clone a device to test.
This means getting rid of the tunables from the line will make it incapable of
testing _tuned_ device.

As Alasdair said,
there are userland tools that compares the representations of output and what to be input
to avoid unnecessary reload. My first thought is to remove these worthless
optimization.
Other option is to define .table_eq :: String -> Bool method in target and
allow users to use it for that checking where the default behavior is left
as string comparison.

Alasdair's suggestion that the output design is always unique so that
the user can make their input as in matching form and string comparison works.
However, this option will discard the benefit of leaving those arguments
optional because it always need to input full set of arguments.
But, this looks the most sane because the user land tool anyway creates
the full set of arguments (They don't use the default value set
by the target). The optional property of some part of the table line
is only beneficial for those who directly uses dmsetup command.

The drawback of requiring full set of arguments is that
it's hard to add arguments anymore after released for backward-compatibility
but we can deal with this problem by remembering what arguments are
originally input (and the ordering) and includes those in output.

> I guess the status should show what's running, and the table line
> should show what was originally loaded.
My idea can go along with your idea by not including the tunables in
table line output if what was originally loaded included none.

> 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.
This is not about the table design.
Remembering tunables in cache metadata and applying them at resuming
under .ctr sounds nice but userland takes responsible for this setup things
is my opinion.


Akira