[Gluster-devel] Upcalls Infrastructure

[Soumya Koduri]

On 12/13/2014 01:16 AM, Shyam wrote:
> I am wondering how to transfer the state maintained by glusterfsd, as
> proposed, when a file is rebalanced?
>
> Currently I/we are (still) thinking on how to get locks across 2
> subvolumes of DHT migrated, when a file is moved during rebalance, on
> the same lines, when a file is migrated we would need to migrate _this_
> state as well.
>
Completely agree. This translator state is analogous to the lock 
translator state. In addition to the above, when there is a plan to 
support self-healing for the locks states, this file state should also 
be considered.

> Maybe we cancel all events/notification requests when a file is
> migrated, could be an off the cuff answer I can think of.
>
I am currently not much sure of how migration is done. Atleast from the 
code looks like (gfapi users') fops are blocked during migration. So 
there cannot be more requests processed/events generated at that time. 
So aren't we already safe to migrate this lock state? Am I missing 
something?

> Just wanted to state the problem, so that as we figure out how locks are
> migrated, we may need additions in this framework to migrate the state
> (or at least a bulk get/set for notification requests).
>
Right. I shall add this in the feature page.
Thanks for bringing this up.

-Soumya

> Shyam
>
> On 12/12/2014 02:17 AM, Soumya Koduri wrote:
>> Hi,
>>
>> This framework has been designed to maintain state in the glusterfsd
>> process, for each the files being accessed (including the clients info
>> accessing those files) and send notifications to the respective
>> glusterfs clients incase of any change in that state.
>>
>> Few of the use-cases (currently identified) of this infrastructure are:
>>
>> * Inode Update/Invalidation
>>      - clients caching inode entries or attributes of a file (eg.,
>> md-cache) can make use of this support to update or invalidate those
>> entries based on the notifications sent by server of the attributes
>> changed on the corresponding files in the back-end.
>>
>> * Recall Delegations/lease-locks
>>      - For lease-locks to be supported, the server should be able to
>> maintain those locks states and recall them successfully by sending
>> notifications to the clients incase of any conflicting access requested
>> by another client.
>>
>> * Maintain Share Reservations/Locks states.
>>      - Along with lease-lock states (mentioned above), we could extend
>> this framework to support Open Share-reservations/Locks
>>
>> In addition to the above, this framework could be extended to add,
>> maintain any other file states and send callback events when required.
>>
>> Feature page -
>> http://www.gluster.org/community/documentation/index.php/Features/Upcall-infrastructure
>>
>>
>>
>> PoC on this feature is done. One of the initial consumers of this
>> support is NFS-ganesha (a user-mode file server for NFSv3,4.0,4.1,pNFS
>> developed by an active open-source community -
>> https://github.com/nfs-ganesha/nfs-ganesha/wiki)
>>
>> Note: This support will be turned off by default and enabled only if
>> required by using a tunable option (currently using Gluster CLI option
>> to enable NFS-Ganesha, being developed as part of a different
>> feature that will get its Feature Page announced soon)
>>
>> Comments and feedback are welcome.
>>
>> Thanks,
>> Soumya
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at gluster.org
>> http://supercolony.gluster.org/mailman/listinfo/gluster-devel