mds: force client flush snap data before truncating objects #11994
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Snapshot data get lost if following sequence of events happen - client writes data to a file - make a snapshot - truncate the file - mds truncate file objects using the newest snap context - client flushes snap data using the old snap context OSD first handles MDS's truncate request, it updates object's snap context. When handling client's write request, OSD finds that object's snap context is newer than request's snap context. So it uses the newer one and treats the data as if they were written after the snapshot. The fix is avoid touching file objects while clients may have unflushed snap data. Before truncating file objects, MDS checks if clients may have unflushed snap data. If client have, MDS set filelock to a special unstable state, the state revokes Fb capability. MDS starts truncating file objects after the Fb capability get revoked. Fixes: http://tracker.ceph.com/issues/17193 Signed-off-by: Yan, Zheng <zyan@redhat.com>
|
/subscribe |
|
jenkins test this please (eio, now ignored in master) |
|
jenkins test this please (tox bug, now fixed in master) |
|
My test branch had a failure in a snapshot test: |
|
unrelated bug http://tracker.ceph.com/issues/17990 |
| if (in->filelock.is_stable()) { | ||
| in->auth_pin(&in->filelock); | ||
| } else { | ||
| assert(in->filelock.get_state() == LOCK_XLOCKSNAP); |
There was a problem hiding this comment.
Don't we still need to auth_pin() the file here?
There was a problem hiding this comment.
LOCK_XLOCKSNAP is unstable state, it was already auth pinned
gregsfortytwo
approved these changes
Nov 23, 2016
| if (in->filelock.is_stable()) { | ||
| in->auth_pin(&in->filelock); | ||
| } else { | ||
| assert(in->filelock.get_state() == LOCK_XLOCKSNAP); |
|
Should build a test for this too @ukernel — we don't have much white box testing around recovery or snapshots. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Snapshot data get lost if following sequence of events happen
OSD first handles MDS's truncate request, it updates object's snap
context. When handling client's write request, OSD finds that
object's snap context is newer than request's snap context. So
it uses the newer one and treats the data as if they were
written after the snapshot.
The fix is avoid touching file objects while clients may have
unflushed snap data. Before truncating file objects, MDS checks
if clients may have unflushed snap data. If client have, MDS
set filelock to a special unstable state, the state revokes Fb
capability. MDS starts truncating file objects after the Fb
capability get revoked.
Fixes: http://tracker.ceph.com/issues/17193
Signed-off-by: Yan, Zheng zyan@redhat.com