[lvm-devel] [PATCH 02/13] Replicator: add libdm support

[Petr Rockai]

Hi,

Alasdair G Kergon <agk at redhat.com> writes:
> On Mon, Oct 05, 2009 at 04:00:29PM +0200, Zdenek Kabelac wrote:
>>  int dm_tree_suspend_children(struct dm_tree_node *dnode,
>> -				   const char *uuid_prefix,
>> -				   size_t uuid_prefix_len);
>> +			     const char *uuid_prefix,
>> +			     size_t uuid_prefix_len,
>> +			     int priority);
>   
> We can't change the published interface like that.
>
> If there really is no alternative to this parameter then you need to introduce
> a new function instead.
I have discussed this in person with Zdeněk, and it seems that the main reason
for this is to allow more atomic suspension of complete replicator.

The normal semantics of DM tree operations is that suspension of a node is done
after all its children are suspended. For replicator, it would be beneficial to
suspend the parent first (to stop the IO stream from the client side) and only
afterwards start suspending the inferior nodes.

In practice, this constitutes only a very slight increase in risk of tripping a
"synchronicity" threshold -- by the amount of data that arrives to the
replicator head in the time frame between a leg is suspended and the replicator
as a whole is suspended -- if this extra data exceeds the amount of free space
in the replicator log, this could trip an extra resync that would be
costly. But it should be stressed, that in these situations, this was already
quite likely to happen, and the outlined problem only increases the chance of
this happening by a small margin.

In other words, I think it is not worth worrying about just yet. At the point
when a dmeventd-style leg dropping is implemented for replicator, this may
become a more pressing problem, but I think the solution should be deferred
until the work on that aspect has begun -- at that time, we ought to have a
clearer picture of the problem area, so it may turn out that a better solution
exists that would not require similar incompatible (and arguably risky) changes
to the libdm core.

Yours,
   Petr.