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@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://supercolony.gluster.org/mailman/listinfo/gluster-devel
