Topic
1 reply Latest Post - ‏2013-05-05T06:07:15Z by dlmcnabb
ufa
ufa
76 Posts
ACCEPTED ANSWER

Pinned topic token management in remotely-mounting environments

‏2013-05-03T10:19:37Z |

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?

 

ufa

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

    Re: token management in remotely-mounting environments

    ‏2013-05-05T06:07:15Z  in response to ufa

    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.