Bug #1425
closedmds: stuck in prexlock
0%
Description
See mds.a.log on sepia78.
- setattr request starts locking
- auth_pins auth stuff
- rdlocks parent dirs, does not auto_pin (not ours)
- starts xlock on target inode (lock->prexlock gather)
- parent migrates onto our node
- gather completes, request goes through acquire_locks
- see's rdlock on parent, needs to auth_pin, ambiguous auth, drops locks + auth_pins
-> target is in prexlock (an unstable state), with associated auth_pin, but stays there.
The problem is that a transition to prexlock does not reliable result in someone holding it, or kicking it back to a stable state if it fails. All the other lock types are taken from a stable state, so this is not an issue. (Although they may leave them in a non-optimal state since we wouldn't eval() them in this scenario either.)
Maybe a taking_lock pointer in MDRequest that is eval()ed/cleaned up by drop_locks()? (That should capture the request_cancel() callers too...)
Updated by Sage Weil over 12 years ago
- Translation missing: en.field_position set to 41
Updated by Sage Weil over 12 years ago
- Status changed from New to In Progress
- Assignee set to Sage Weil
Updated by Sage Weil over 12 years ago
- Target version changed from v0.35 to v0.36
Updated by Sage Weil over 12 years ago
- Translation missing: en.field_position deleted (
65) - Translation missing: en.field_position set to 15
Updated by Sage Weil over 12 years ago
- Status changed from In Progress to Resolved
Updated by Sage Weil over 12 years ago
- Target version changed from v0.36 to v0.35
Updated by John Spray over 7 years ago
- Project changed from Ceph to CephFS
- Category deleted (
1) - Target version deleted (
v0.35)
Bulk updating project=ceph category=mds bugs so that I can remove the MDS category from the Ceph project to avoid confusion.