[sheepdog] [PATCH] sheep: let outstanding IO req doesn't block confchg event

Liu Yuan namei.unix at gmail.com
Mon May 28 09:25:02 CEST 2012


On 05/28/2012 03:11 PM, Christoph Hellwig wrote:

>> -	if (is_vdi_obj(oid))
>> -		flags &= ~O_DIRECT;
>> +	if (iocb->epoch < sys_epoch()) {
>> +		dprintf("%"PRIu32" sys %"PRIu32"\n", iocb->epoch, sys_epoch());
>> +		return SD_RES_OLD_NODE_VER;
>> +	} else {
> 
> Can you explain why we need the epoch check here in the changelog?
> Also any reason it's down in farm instead of in store.c?
> 
> No need for the else here - after the return nothing else will be
> executed.
> 


Umm, I have the explanation in my last version, forgot to get it back.

Kazutaka has a good example:

=============================
If there are 1 node, A, and the number of copies is 1, how does
Farm handle the following case?

 - the user add the second node B, and there is in-flight I/Os on
   node A
 - the node A increments the epoch from 1 to 2, and the node B recovers
   objects from epoch 1 on node A
 - after node B receives objects to epoch 2, the in-flight I/Os on
   node A updates objects in epoch 1 on node A.
 - node A sends responses to clients as success, but the updated data
   will be lost??
==============================

I can't produce this case with script, in fly IO will always be executed
before recovering requests to the same object, so

>> +	if (iocb->epoch < sys_epoch()) {
>> +		dprintf("%"PRIu32" sys %"PRIu32"\n", iocb->epoch, sys_epoch());
>> +		return SD_RES_OLD_NODE_VER;

can be thought as a safe guard for the case Kazutaka described.

I am reserved for this guard though.

Thanks,
Yuan



More information about the sheepdog mailing list