race with container recreate
Bug #1292784 reported by
clayg
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Object Storage (swift) |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
So I always hated the way that the status field worked on our db's - but when looking at it I thought I spotted a race, and now I'm pretty sure it's there. Can someone check out this test case (redbo, put on your concurrency hat).
Basically if you PUT on a container if the file on disk already exists it will update the put_timestamp, if not it goes into initialize which *may* raise AlreadyExists - but in the second case we don't update put_timestamp.
Replication was fixing it eventually...
description: | updated |
Changed in swift: | |
milestone: | none → 1.13.1-rc1 |
status: | Fix Committed → Fix Released |
Changed in swift: | |
milestone: | 1.13.1-rc1 → 1.13.1 |
To post a comment you must log in.
I mean, we could try updating the put_timestamp after catching AlreadyExists, but that doesn't guarantee the container exists after a PUT. If the deleter has a later X-Timestamp but gets to disk first, then even if we do update put_timestamp, the DB will still be considered deleted.