Feature #2531: rbd: fencing broken clients - rbd - Ceph

Actions

Copy link

Feature #2531

closed

rbd: fencing broken clients

Added by Sage Weil almost 12 years ago. Updated about 11 years ago.

Status:

Resolved

Priority:

High

Assignee:

Target version:

% Done:

Source:

Tags:

CY2012

Backport:

Reviewed:

Affected Versions:

Pull request ID:

Actions

Copy link

Updated by Sage Weil almost 12 years ago

Translation missing: en.field_position deleted (1)
Translation missing: en.field_position set to 11

Actions

Copy link

Updated by Greg Farnum almost 12 years ago

Assignee set to Greg Farnum

I talked to Sam about the combination of blacklisting, bad client writes, and changing primaries that we discussed and he actually thinks the old write will come back if there have been no updates. He's not certain, but thinks that if the logs don't themselves diverge then the newest update will win.

To fix this, we can do a no-op write to the current primaries...

Actions

Copy link

Updated by Greg Farnum almost 12 years ago

As I see it, we have two options that we need to choose between.
1) We can add fencing to librbd and let anybody do it.
2) We can make fencing part of the rbd tool.

Either way, the implementation is going to be yucky. We need to (in probably not this order) break their locks, take our own, and blacklist the entity in the OSDMap. Then we need to do a null write to every OSD which hosts objects for that RBD image (in order to force a map update which includes the blacklist).
This obviously has the potential to break a great many things since blacklisting happens at the address level right now — a KVM host is probably going to have a lot of images mounted and this is a very expensive operation that only handles one of them. I think we want to rethink this feature — since it will need to be admin-coordinated anyway we're probably better off making it somebody else's responsibility to handle blacklisting before breaking the locks.

Actions

Copy link