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
