[Gluster-devel] libgfapi changes to add lk_owner and lease ID

Kaleb KEITHLEY kkeithle at redhat.com
Thu Dec 3 20:21:31 UTC 2015


On 12/03/2015 03:10 PM, Ira Cooper wrote:
> Poornima Gurusiddaiah <pgurusid at redhat.com> writes:
> 
>> Hi, 
>>
>> Brief Background: 
>> ============ 
>> For the below two features, we need ligfapi to take 2 other parameters from the applications for most number of fops. 
>> http://review.gluster.org/#/c/12014/ 
>> http://review.gluster.org/#/c/11980/ 
>>
>> For leases to work as explained in the above doc, every file data read/write fop needs to be associated with a lease ID. This is specially required for Samba and NFS-Ganesha as they inturn serve other clients who request for leases. For Gluster to identify the end client (which is not Samba/NFS Ganesha) we need lease ID to be filled by Samba/NFS Ganesha. 
>>
>> For mandatory locks feature to work as explained, every file data read/write fop needs to be associated with a lk_owner. In linux Kernel VFS takes care of filling the lk_ownere for the file system. In libgfapi case, the applications calling into libgfapi should be providing lk_owner with every fop. This is again required mainly for Samba and NFS Ganesha, as they serve multiple clients. 
>>
>> Possible solutions: 
>> ============= 
>> 1. Modify all the required APIs to take 2 other parameter, lease ID and lk_owner. But that would mean backward compatibility issues and is a programming overhead for applications not interested in Leases and mandatory lock feature. 
>> 2. Add an API called glfs_set_fop_attrs (lease ID, lk_owner) which works similar to glfs_set_uid(uid). The API sets a thread local storage (pthread_key) with the values provided, the further fops on that thread will pick the lease ID and lk_owner from the thread local storage (pthread_key). There are few minor details that needs to be worked out: 
>> - In case of async API will end up using lease ID and lk_owner from wrong thread. 
>> - unset lease ID and lk_owner after every fop to ensure there is no stale lease ID or lk_owner set? 
>> - For fd based fops we can store the lease ID and lk_owner in glfd, so that the application writed need not set it for every fop. But for handle based fops lease ID and lk_owner needs to be set explicitly every-time. 
>>
>> Solution 2 is more preferable except for that it adds overhead of calling another API, for the libgfapi users who intends to use these features. 
>> A prototype of solution 2 can be found at http://review.gluster.org/#/c/12876/ 
>>

why not use storage in the client_t instead of thread local?

--

Kaleb



More information about the Gluster-devel mailing list