Bug #36541
rename does not old ref to replacement onode at old name
0%
Description
- rename from foo to bar
- foo onode is moved to bar in onode_map
- keys removed at position foo as part of txc
- new onode for foo is installed at foo in map
...
- cache trims foo
...
- new txn B does get_onode on foo, reads old foo (now bar) onode into foo ***
- txn A commits
-> onode cache has foo with stale bar content
in the test failure's case, that badness is that txn B deletes foo's blobs.. which are still referenced by (renamed) bar.
/a/sage-2018-10-19_22:30:51-rados-wip-sage-testing-2018-10-19-1326-distro-basic-smithi/3162317
#44:4f73ae0d:test-rados-api-smithi148-39393-29::big2.copy:head# renamed from #-46:4f73ae0d:::temp_44.2_0_4158_1:head#
Related issues
History
#1 Updated by Sage Weil over 5 years ago
Fix is to note_modified_object() in rename on the new replacement foo onode at the old name, so that it doesn't go away until the kvdb is updated, and a get_onode that happens before then doesn't read stale kv data.
#2 Updated by Sage Weil over 5 years ago
- Backport set to mimic,luminous
#3 Updated by jianpeng ma over 5 years ago
But for get_onode can't do onode::flush. So for the later read(stat/getattr)still get the foo infos. Or i missed something in OSD to protect this happen?
#4 Updated by Sage Weil over 5 years ago
- Status changed from Fix Under Review to Pending Backport
#5 Updated by Patrick Donnelly over 5 years ago
- Copied to Backport #36638: luminous: rename does not old ref to replacement onode at old name added
#6 Updated by Patrick Donnelly over 5 years ago
- Copied to Backport #36639: mimic: rename does not old ref to replacement onode at old name added
#7 Updated by Patrick Donnelly about 5 years ago
- Status changed from Pending Backport to Resolved
#8 Updated by Nathan Cutler about 5 years ago
- Pull request ID set to 24686