DAOS-19284 vos: check conflict among distributed transactions - #18814
DAOS-19284 vos: check conflict among distributed transactions#18814Nasf-Fan wants to merge 1 commit into
Conversation
|
Ticket title is 'daos_test/dfs.py:DaosCoreTestDfs.test_daos_dfs_parallel - Failed concurrent rmdir' |
46db500 to
e148494
Compare
|
Test stage Unit Test completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-18814/2/testReport/ |
|
Test stage Unit Test with memcheck completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-18814/2/testReport/ |
|
Test stage Unit Test bdev completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-18814/2/testReport/ |
|
Test stage Functional Cluster Box Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-18814/2/execution/node/1538/log |
e148494 to
5a81751
Compare
For a distributed transaction, its epoch is generated by the first accessed server. So two distributed transactions may use the same epoch (if their first accessed servers are different) to operate the same set of object(s) by race. In theory, two read distributed transactions do not conflict with each other, but read maybe just part of the transaction, and there maybe update/punch in the same distributed transaction subsequently. Since we can keep only one (sponsor) timestamp for one TS entry, then have to request another one to restart. That may cause some fake conflict, but correctness is more important and such race is rare. Signed-off-by: Fan Yong <fan.yong@hpe.com>
5a81751 to
98d46b9
Compare
|
Test stage Functional Cluster Box Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-18814/3/execution/node/1519/log |
| return 0; | ||
|
|
||
| /* It is very rare, so warning message will not be much trouble. */ | ||
| D_WARN("Refuse high read-TS update with the same epoch " DF_X64 " from multiple " |
There was a problem hiding this comment.
[Nit] There seems to be no reason to warn users, because we can't tell if they have set up or done anything risky or wrong. I'd write D_DEBUG, but D_INFO might be tolerable too.
3 participants
For a distributed transaction, its epoch is generated by the first accessed server. So two distributed transactions may use the same epoch (if their first accessed servers are different) to operate the same set of object(s) by race. In theory, two read distributed transactions do not conflict with each other, but read maybe just part of the transaction, and there maybe update/punch in the same distributed transaction subsequently. Since we can keep only one (sponsor) timestamp for one TS entry, then have to request another one to restart. That may cause some fake conflict, but correctness is more important and such race is rare.
Steps for the author:
After all prior steps are complete: