7:42 a.m.
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(a)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(a)lists.nfs-ganesha.org
> To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
>
_______________________________________________
Devel mailing list -- devel(a)lists.nfs-ganesha.org
To unsubscribe send an email to devel-leave(a)lists.nfs-ganesha.org
--
Jeff Layton <jlayton(a)poochiereds.net>