Reliably maintaining strict consistency in cluster wide state of opened files in a distributed file system cluster exposing a global namespace

1. A method of maintaining consistency in a distributed file system of a cluster for a plurality of clients that access files via a stateful protocol comprising:

restricting consistency of open states of the files to pairs of nodes, wherein a first node in a first pair of nodes is a first metadata node that comprises a first Btree, the first Btree forms a portion of a global namespace exposed to the clients and organizes metadata for a first subset of files, and

wherein a second node in the first pair of nodes is a first data node that comprises file content of the first subset of files and a first shadow Btree, corresponding to the first Btree;

establishing Transmission Control Protocol (TCP) links between the first metadata node and the first data node;

upon opening one or more files of the first subset of files in response to file system operations requested by the clients,

generating and returning to a respective requesting client a file handle for each open file requested by the respective requesting client; and

generating, along with the file handle, a file manager server session at the first metadata node and a corresponding file manager server session at the first data node to track open states of the files in the first subset of files;

recording each file manager server session in a mapping table, the mapping table thereby identifying each open file, and the first metadata node and the first data node associated with each open file;

storing the file manager server session and state information of open files in respective inodes of the open files;

detecting that one of the first metadata node or the first data node of the first pair of nodes associated with an open file has become unavailable because a TCP link between the first metadata node and the first data node has broken, the one of the first metadata node or the first data node that has become unavailable now being an unavailable node, and another of the first metadata node or the first data node that remains available now being an available node;

consulting the mapping table to identify the available node of the first pair of nodes and the open file;

performing crash recovery protocols on the available node of the first pair of nodes associated with the open file while not performing the crash recovery protocols for the open file on any other node of other pairs of nodes in the cluster;

receiving a first request from a first client to open a first file associated with the first pair of nodes;

creating, in response to the first request, a first file manager server session and a first file handle;

tagging the first file with the first file manager server session;

calculating a first verifier based on the first file manager server session and a server identifier, the server identifier identifying at least one of the first metadata node or the first data node of the first pair of nodes;

assigning the first verifier to the first file handle;

sending the first file handle and the first verifier to the first client, wherein the first client uses the first file handle and the first verifier in requesting subsequent file system operations on the first file;

changing the first verifier assigned to the first file handle to a new value in response to the detecting that one of the first metadata node or the first data node has become unavailable;

receiving from the first client, in conjunction with a subsequent file system operation requested on the first file, the first file handle and the first verifier;

determining that the first verifier received from the client does not match the changed first verifier having the new value; and

based on the determination that the first verifier received from the client does not match the changed first verifier having the new value, returning an error to the first client indicating that the subsequent file system operation requested on the first file cannot be performed because the subsequent file system operation has been requested on a file that is stale.

2. The method of claim 1 further comprising:

allowing metadata associated with the open file to become stale on other pairs of nodes of the cluster that are not the first pair of nodes, thereby restricting strict consistency of the open file to be between the first metadata node and the first data node of the first pair of nodes.

3. The method of claim 1 further comprising:

receiving at the first metadata node a client request to access a file, the file being associated with a second pair of nodes, different from the first pair of nodes; and

redirecting the client request to a node of the second pair of nodes.

4. The method of claim 1 wherein the performing crash recovery protocols comprises:

tearing down TCP connections to the unavailable node.

5. The method of claim 1 wherein the file manager server session at the first metadata node has a one-to-one mapping with the first data node, the file manager server session at the first metadata node thereby uniquely identifying the first data node, and

wherein the corresponding file manager server session at the first data node has a one-to-one mapping with the first metadata node, the corresponding file manager server session at the first data node thereby uniquely identifying the first metadata node.

6. A system for maintaining consistency in a distributed file system of a cluster for a plurality of clients that access files via a stateful protocol, the system comprising: a hardware processor; and hardware memory configured to store one or more sequences of instructions which, when executed by the hardware processor, cause the hardware processor to carry out the steps of:

restricting consistency of open states of the files to pairs of nodes, wherein a first node in a first pair of nodes is a first metadata node that comprises a first Btree, the first Btree forms a portion of a global namespace exposed to the clients and organizes metadata for a first subset of files, and

wherein a second node in the first pair of nodes is a first data node that comprises file content of the first subset of files and a first shadow Btree, corresponding to the first Btree;

establishing Transmission Control Protocol (TCP) links between the first metadata node and the first data node;

upon opening one or more files of the first subset of files in response to file system operations requested by the clients,

generating and returning to a respective requesting client a file handle for each open file requested by the respective requesting client; and

generating, along with the file handle, a file manager server session at the first metadata node and a corresponding file manager server session at the first data node to track open states of the files in the first subset of files;

recording each file manager server session in a mapping table, the mapping table thereby identifying each open file, and the first metadata node and the first data node associated with each open file;

storing the file manager server session and state information of open files in respective inodes of the open files;

detecting that one of the first metadata node or the first data node of the first pair of nodes associated with an open file has become unavailable because a TCP link between the first metadata node and the first data node has broken, the one of the first metadata node or the first data node that has become unavailable now being an unavailable node, and another of the first metadata node or the first data node that remains available now be an available node;

consulting the mapping table to identify the available node of the first pair of nodes and the open file;

performing crash recovery protocols on the available node of the first pair of nodes associated with the open file while not performing the crash recovery protocols for the open file on any other node of other pairs of nodes in the cluster;

receiving a first request from a first client to open a first file associated with the first pair of nodes;

generating a first file handle and a first verifier;

assigning the first verifier to the first file handle;

sending the first file handle and the first verifier to the first client, wherein the first client uses the first file handle and the first verifier in requesting subsequent file system operations on the first file;

destroying a first file manager server session associated with the open first file in response to detecting that one of the first metadata node or the first data node has become unavailable;

based on the destruction, changing the first verifier assigned to the first file handle to a new value;

receiving from the first client, in conjunction with a file system operation requested on the first file, the first file handle and the first verifier;

comparing the first verifier received from the first client with the first verifier now having the new value;

determining from the comparison that the first verifiers do not match; and

returning an error to the first client indicating that the file system operation on the first file cannot be performed because the file system operation has been requested on a file that has become stale.

7. The system of claim 6 wherein the hardware processor further carries out the steps of:

allowing metadata associated with the open file to become stale on other pairs of nodes of the cluster that are not the first pair of nodes, thereby restricting strict consistency of the open file to be between the first metadata node and the first data node of the first pair of nodes.

8. The system of claim 6 wherein the hardware processor further carries out the steps of:

receiving a second request from a second client to open a second file associated with the first pair of nodes;

creating, in response to the second request, a second file manager server session and a second file handle;

tagging the second file with the second file manager server session;

calculating a second verifier based on the second file manager server session and a server identifier, the server identifier identifying at least one of the first metadata node or the first data node of the first pair of nodes;

assigning the second verifier to the second file handle; and

sending the second file handle and the second verifier to the second client, wherein the second client uses the second file handle and the second verifier in requesting subsequent file system operations on the second file.

9. The system of claim 8 wherein the hardware processor further carries out the steps of:

receiving from the second client, in conjunction with a subsequent file system operation requested on the second file, the second file handle and the second verifier;

determining that the second verifier is old; and

based on the determination that the second verifier is old, returning an error to the second client indicating that the subsequent file system operation requested on the second file cannot be performed because the subsequent file system operation has been requested on a file that is stale.

10. The system of claim 6 wherein the hardware processor further carries out the steps of:

receiving at the first metadata node a client request to access a file, the file being associated with a second pair of nodes, different from the first pair of nodes; and

redirecting the client request to a node of the second pair of nodes.

11. The system of claim 6 wherein the hardware processor further carries out the steps of:

tearing down TCP connections to the unavailable node during the crash recovery.

12. A computer program product, comprising a non-transitory computer-readable medium having a computer-readable program code embodied therein, the computer-readable program code adapted to be executed by one or more processors to implement a method for maintaining consistency in a distributed file system of a cluster for a plurality of clients that access files via a stateful protocol, the method comprising:

restricting consistency of open states of the files to pairs of nodes, wherein a first node in a first pair of nodes is a first metadata node that comprises a first Btree, the first Btree forms a portion of a global namespace exposed to the clients and organizes metadata for a first subset of files, and

wherein a second node in the first pair of nodes is a first data node that comprises file content of the first subset of files and a first shadow Btree, corresponding to the first Btree;

establishing Transmission Control Protocol (TCP) links between the first metadata node and the first data node;

upon opening one or more files of the first subset of files in response to file system operations requested by the clients,

generating and returning to a respective requesting client a file handle for each open file requested by the respective requesting client; and

generating, along with the file handle, a file manager server session at the first metadata node and a corresponding file manager server session at the first data node to track open states of the files in the first subset of files;

recording each file manager server session in a mapping table, the mapping table thereby identifying each open file, and the first metadata node and the first data node associated with each open file;

storing the file manager server session and state information of open files in respective inodes of the open files;

detecting that one of the first metadata node or the first data node of the first pair of nodes associated with an open file has become unavailable because a TCP link between the first metadata node and the first data node has broken, the one of the first metadata node or the first data node that has become unavailable now being an unavailable node, and another of the first metadata node or the first data node that remains available now being an available node;

consulting the mapping table to identify the available node of the first pair of nodes, and the open file;

performing crash recovery protocols on the available node of the first pair of nodes associated with the open file while not performing the crash recovery protocols for the open file on any other node of other pairs of nodes in the cluster;

receiving a first request from a first client to open a first file associated with the first pair of nodes;

generating a first file handle and a first verifier;

assigning the first verifier to the first file handle;

sending the first file handle and the first verifier to the first client, wherein the first client uses the first file handle and the first verifier in requesting subsequent file system operations on the first file;

destroying a first file manager server session associated with the open first file in response to detecting that one of the first metadata node or the first data node has become unavailable;

based on the destruction, changing the first verifier assigned to the first file handle to a new value;

receiving from the first client, in conjunction with a file system operation requested on the first file, the first file handle and the first verifier;

comparing the first verifier received from the first client with the first verifier now having the new value;

determining from the comparison that the first verifiers do not match; and

returning an error to the first client indicating that the file system operation on the first file cannot be performed because the file system operation has been requested on a file that has become stale.

13. The computer program product of claim 12 wherein the method further comprises:

allowing metadata associated with the open file to become stale on other pairs of nodes of the cluster that are not the first pair of nodes, thereby restricting strict consistency of the open file to be between the first metadata node and the first data node of the first pair of nodes.

14. The computer program product of claim 12 wherein the method further comprises:

receiving a second request from a second client to open a second file associated with the first pair of nodes;

creating, in response to the second request, a second file manager server session and a second file handle;

tagging the second file with the second file manager server session;

calculating a second verifier based on the second file manager server session and a server identifier, the server identifier identifying at least one of the first metadata node or the first data node of the first pair of nodes;

assigning the second verifier to the second file handle; and

sending the second file handle and the second verifier to the second client, wherein the second client uses the second file handle and the second verifier in requesting subsequent file system operations on the second file.

15. The computer program product of claim 14 wherein the method further comprises:

receiving from the second client, in conjunction with a subsequent file system operation requested on the second file, the second file handle and the second verifier;

determining that the second verifier is old; and

based on the determination that the second verifier is old, returning an error to the second client indicating that the subsequent file system operation requested on the second file cannot be performed because the subsequent file system operation has been requested on a file that is stale.

16. The computer program product of claim 12 wherein the method further comprises:

receiving at the first metadata node a client request to access a file, the file being associated with a second pair of nodes, different from the first pair of nodes; and

redirecting the client request to a node of the second pair of nodes.

17. The computer program product of claim 12 wherein the method further comprises:

tearing down TCP connections to the unavailable node during the crash recovery.