On Mon, Mar 13, 2017 at 4:06 AM, Lyu Jesse <jesse.js.lyu@xxxxxxxxx> wrote: > FYI. > > 2017-03-13 16:01 GMT+08:00 Lyu Jesse <jesse.js.lyu@xxxxxxxxx>: >> >> Hi guys, >> >> I tested the RBD exclusive lock and found that the exclusive lock could be >> acquired by the lasted new client using the nbd+librbd way. >> >> my question is that: >> 1. is there any difference between rbd lock add/remove CMDs and librbd >> exclusive lock The rbd CLI lock add/remove commands are advisory locks. Unless you have additional tooling around the use of them, nothing would prevent multiple clients from sending concurrent IO to the image. >> 2.using the nbd+librbd，is the newest client has the highest priority to >> grab the exclusive lock The clients will cooperatively exchange the exclusive lock if required if write IOs are issued. There is an optional "--exclusive" flag that will disable this coordinated lock exchange and will result in one client owning the lock until it quits. >> 3. In my test case by using the nbd+librbd，after losing the exclusive lock >> ,the old client can still write to the rbd I suspect you are seeing the coordinated lock exchange. Any reason why you have the image double-mapped? >> we are using the nbd+librbd and mount the rbd image as ext4 filesystem. >> >> >> Best Regards, >> Jesse Lyu > > > > _______________________________________________ > Ceph-community mailing list > Ceph-community@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-community-ceph.com > -- Jason -- 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
