I'm actually not that familiar with cephfs filelocking code, but I believe the "owner" value that we pass down to the client is only significant to that particular MDS client session. When the server reboots and reclaims the lock, that value will change, but that's ok, as that new value will also be unique and only significant within the context of the new CephFS MDS client session. On Wed, 2019-05-08 at 08:46 -0400, Daniel Gryniewicz wrote:
Since FSAL_CEPH is just using the pointer to the state_owner_t as a 64-bit integer, it cannot be duplicated. That pointer is unique. You can use the NFS4 or NLM owner if you want (it's stored in the state_owner_t). Those are unique, because they're based on the client ID, which is guaranteed unique to a client.
In the case of FSAL_CEPH, the pointer will have changed across reboot. I'm not sure how it's handling it. Jeff would know more.
Daniel
On 5/8/19 3:29 AM, fanzi2009@hotmail.com wrote:
Hi, I'm implementing a file system FSAL which is similar to CEPH FSAL. I checked ceph_fsal_lock_op2() and other FSAL lock_op2 implementation. The owner parameter is a pointer, but it converts it to 64bit integer and sends to CEPH. Ceph will judge if it's a conflict according to this value. My question is : 1. it's possible that different clients have the same value even though the possibility is very low. 2. When this sever reboot and reclaim the lock, this value should change.
Thanks, Marvin _______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
_______________________________________________ Devel mailing list -- devel@lists.nfs-ganesha.org To unsubscribe send an email to devel-leave@lists.nfs-ganesha.org
-- Jeff Layton <jlayton@poochiereds.net>