performance bug

DA:

If the parent cache block had only the XOR_ACC_PROCESSED bit set in the RAID flags this dictates that the cache entry hastimed outand that there

are no longer any children temp blocks on the chain. Please see the MScache.cpp code starting at around line 4934 (WAIT_XOR state timeout processing).

There could have been an error before this also such that the rebuild did not occur correctly.

The current parent chain timeout for pure reconstruction pickup by the client is 500ms starting from the time we start the reconstruction via validateRaidRecovery or

StartDataRebuild.

Is the client coming back later than that?

Please follow the parent cache block through the log for this IO before the read request is issued by the client. What happened to the parent? Are we potentially timing

Out too early? (There is a balance between keeping temp chain cache blocks active and allowing other rebuilds to occur since cache resources are limited on ISIS7000)

The bottomline is you cannot change the return value of checkRaidRecovery because in this case the actual data is supposedly no longer on the parent cache chain.

setupRaidRecovery can call back the actual data again？

0816:

The first important question is:

Did the client have trouble talking to SE9 between 82.407 and 84.638 above?

0818：

1. In packet drop case, the client have difficulty talking with server, but now I only care with offline case.

2. In no reboot case, the client continually talk with server. but server reject with unknown reason.

3. In reboot case,