On Mon, Nov 25, 2013 at 03:03:46PM +0800, Robin Dong wrote: > The present implementation of http/swift is not perfect, it can't create > too much containers or objects. So we want to store all objects in one > hyper volume vdi and use new structure 'obj-inode' to identify its offset > and length in this vdi, just like some local file system. To achieve this, > we need distributed locks to ensure that only one thread can create a new > 'obj-inode' (or delete) in this vdi at a same time. > > This patch set is a try to implement the distributed lock. > > If we add code in sheep/cluster/zookeeper.c and use the framework of > cluster to implement this distributed lock, then we have to add > implementation for corosyncălocal and shepherd. That's too complicated. So > what we need is adding lock.c in sheep/http/ and only use it in http > interface. >
I have no inclination on which way is better over the other. For a quick thought I think, put lock concept entirely in tht http layer has following pros: - http might be the only user of lock, so no need to put it in a lower cluster layer. cons: - can't be used by others (though we can extend it when in need) - it would be very easy to map distributed lock to a local file lock, so testing the lock user code might be facilitated with alternative implemenation. E.g, if lock itself goes wrong, we can verify it by running different driver. That said, I think there is a problem for how we specify the zookeeper for lock mechanism, if we choose to implement it in http entirely, I'd suggest we shouldn't mix the options between http and cluster driver. So based on the stackable principle, '-r swift,lock=zookeeper:ip:port' is more desireable. Since if users don't need features like 'concurrently create objects inside a bucket from different client' he can choose not to set 'lock' option for http service. Thanks, Yuan -- sheepdog mailing list [email protected] http://lists.wpkg.org/mailman/listinfo/sheepdog
