• 1 reply
  • Latest Post - ‏2013-05-05T06:07:15Z by dlmcnabb
157 Posts

Pinned topic token management in remotely-mounting environments

‏2013-05-03T10:19:37Z | file gpfs manager token

Hello all, another question:

One of the GPFS features is that, after the intial grant of a file token to a requesting daemon by a token manager, competing daemons would be referred by the token manager to the daemons holding the token currently, thus the token manager has not to resolve this.

However, nowadays the requirement is gone that client daemons of separate clusters must be able to contact each other even in the case they remotely mount the same file system from a third cluster.

That means, these daemons cannot resolve token conflicts. How is that handled? Does it mean the token manager routes the client messages?



Updated on 2013-05-03T10:20:09Z at 2013-05-03T10:20:09Z by ufa
  • dlmcnabb
    1012 Posts

    Re: token management in remotely-mounting environments


    Normally, if a node nees a token that some other node holds, the token manager sends the list to the client, who then sends revoke messages to all those nodes and then sends the resulting relinquishes back to the token manager. This distributes the work of doing the revokes.

    But when the token manager notices that the revoking node and the revokee nodes are in different remote clusters (that cannot communicate directly) it sends the revoke messages directly to the remote revokees, and then if there are still revokees that the first revoker node can handle itself, it falls back to the first case. If there are no revokees left, then the token is granted to the initial requestor.