No trouble at all. In the forthcoming Jewel release, there are additional optimizations on the write path when object map is used. Specifically, if we know the object doesn't exist, we can skip the initial guarded write (which we know will fail) and directly read the corresponding extent from the parent. We still include the guard on all writes to extents that overlap with the parent to prevent race conditions (if you have multiple writes to the same object in-flight). librbd could track in-flight writes to the same object and stall IO to avoid such race conditions, but at the time it didn't seem worth it to save a few bytes for the write guard (which is essentially a no-op if the child object already exists). -- Jason Dillaman ----- Original Message ----- > From: "Zhongyan Gu" <zhongyan.gu@xxxxxxxxx> > To: "Jason Dillaman" <dillaman@xxxxxxxxxx> > Cc: ceph-users@xxxxxxxxxxxxxx > Sent: Thursday, April 7, 2016 10:33:11 PM > Subject: optimization for write when object map feature enabled > Hi Jason, > Sorry to bother you. A question about object map. > object map tracks which blocks of the image are actually allocated. > I can see one use case is for read optimization. For read, it checks the > object existence first,if the object doesn't exist locally, it sends read > directly to parent. so this avoid a child read operation. > However, I doubt why there is no optimization for write. we still issue guard > write which will issue stat first to check the object existence even if the > object has been copied up. My understanding is if we enable object map > feature, the guard write can also be optimized, no "stat" is needed any > more. Is this right? > Thanks > Cory _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
 |