Hi guys, Thank you for the tremendous answers :D How far are we to see this feature in the stable branch? Part of the 0.48.x or far away from that? Cheers! On Mon, Aug 13, 2012 at 7:49 PM, Yehuda Sadeh <yehuda@xxxxxxxxxxx> wrote: > On Mon, Aug 13, 2012 at 10:22 AM, Josh Durgin <josh.durgin@xxxxxxxxxxx> wrote: >> On 08/13/2012 09:55 AM, Gregory Farnum wrote: >>> >>> We've discussed some of the issues here a little bit before. See >>> http://comments.gmane.org/gmane.comp.file-systems.ceph.devel/7094 if >>> you're interested. >>> >>> Josh, can you discuss the current status of the advisory locking? >>> -Greg >> >> >> Yehuda reworked it into a generic rados class so it can be used outside >> of rbd. It hasn't been re-integrated with rbd yet, and I haven't looked >> at it closely since the generalization. Yehuda could describe it in >> more detail. >> > > The lock objclass provides a generic way to set locks on objects. It > is a cooperative scheme. The following operations are available: > - lock (exclusive or shared) > - unlock -- remove a lock that was set by the same client instance > - break -- remove a lock that was set by a different client instance > > A lock can be set indefinitely, or can be timed out after a specified > period. A lock can be renewed. > > For the use of rbd, a client will have to set an exclusive lock on the > rbd header, with a specified (and relatively short timeout). It > shouldn't do any I/O operations without holding that lock. It'll have > to renew that lock, and failing to do so (meaning the lock was broken > by another client) will require it to stop any I/O operations. The > overriding client should wait for the original client's lock period > timeout before initiating a new new I/O. As I said, this is a > cooperative scheme, it doesn't prevent a buggy/bad client to send > unwanted I/Os to the osds. A client cannot know that its lock was > broken without explicitly checking it, or trying to renew it (when > it's an exclusive lock). We can achieve that using watch/notify, > though I'm not sure it's worth the extra trouble (watch/notify doesn't > solve everything either). > > > Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
