[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