Method and computer system for sharing objects

• US 10,657,105 B2
• Filed: 10/30/2014
• Issued: 05/19/2020
• Est. Priority Date: 10/30/2014
• Status: Active Grant

• Current Assignee: Hitachi, Ltd.
• Original Assignee: Hitachi, Ltd.
• Inventors: Le, Hieuhanh, Takata, Masanori, Nakatani, Yoji, Arai, Hitoshi, Kamei, Hitoshi, Tsuchiya, Akiyoshi, Sutoh, Atsushi
• Primary Examiner(s): Kindred, Alford W
• Assistant Examiner(s): Lin, Allen S
• Application Number:
  US15/507,684
• Publication Number:
  US 20170286447A1
• Time in Patent Office: 2,028 Days
• Field of Search: 707610
• CPC Class Codes: G06F 16/122 using management policies backup systems G06F11/1446; file migration policies for HSM systems G06F16/185
• CPC Class Codes: G06F 16/1774 Locking methods, e.g. locking methods for file systems allowing shared and concurrent access to files
• CPC Class Codes: G06F 16/182 Distributed file systems

Abstract

A computer system for sharing objects comprises multiple front-end nodes and a back-end node for providing a namespace shared by the front-end nodes. A first front-end node that is any one of the front-end nodes manages local-lock counts for each of objects managed by the first front-end node. The local-lock count is the number of locks taken by operations to the objects including the directory and sub-objects thereof. Every time receiving a request for processing a target object from a client, the front-end node requests the back-end node to lock a parent directory of the target object if the parent directory has not been locked by the back-end node. The front-end node sends a response of the received request to the client regardless of whether or not the parent directory has been unlocked by the back-end node. If the local-lock count of the parent directory is zero, the first front-end node requests the back-end node to unlock the parent directory.

Claims

1. A computer system for sharing objects including at least directories, the computer system comprising:

multiple front-end nodes that are coupled to clients; and

a back-end node being configured to provide a namespace shared by the multiple front-end nodes,

a first front-end node that is any one of the multiple front-end nodes, being configured to manage local-lock counts for each of directories managed by the first front-end node, the local-lock count being the number of locks taken by operations to the objects including the directory and sub-objects thereof,

the first front-end node being configured to, every time an update request is received for processing a target object from a client that is coupled to the first front-end node, request the back-end node to lock a parent directory of the target object and increment the local-lock count for the parent directory when the parent directory has not been locked by the back-end node,

the first front-end node being configured to send a response of the received update request to the client regardless of whether or not the parent directory has been unlocked by the back-end node, and

the first front-end node being configured to, when the local-lock count of the parent directory is zero, request the back-end node to unlock the parent directory,

wherein the first front-end node is configured to migrate not only the processed target object but also the parent directory thereof to the back-end node, and the first front-end node is configured not to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has not become zero, and the first front-end node is configured to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has become zero,

wherein the first front-end node is configured to, when completing migration of the processed target object to the back-end node, decrement the local-lock counts of the processed target object and the parent directory thereof, and

wherein the first front-end node is configured to, when at least one of the local-lock counts of the processed target object and the parent directory has become zero, request the back-end node to unlock the at least one of the processed target object and the parent directory whose local-lock count has become zero.

2. The computer system according to claim 1, wherein

the first front-end node is configured to, when requesting the back-end node to lock a directory, increment the local-lock count of the directory, and

the first front-end node is configured to, when processing the target object, increment the local-lock count of the parent directory of the target object.

3. The computer system according to claim 1, wherein

the first front-end node is configured to manage the local-lock counts using management information stored in the first front-end node, the management information includes a link name, global-lock status and the local-lock count for each of directories managed by the first front-end node,

the link name is the name of the link to the directory managed by the back-end node from the first front-end node,

the global-lock status is the status indicating whether or not the corresponded directory has been locked by the back-end node, and the first front-end node is configured to determine whether or not the parent directory has been locked by the back-end node, based on the management information.

4. The computer system according to claim 1, wherein

the received update request for processing the target object is a creation request for creating the target directory, and

the first front-end node is configured to increment the local-lock count of a directory newly created in response to the creation request, as well as the local-lock count of the parent directory of the directory newly created.

5. The computer system according to claim 1, wherein the received update request for processing the target object is a deletion request for deleting the target object.

6. The computer system according to claim 1, wherein the received update request for processing the target object is a rename request for renaming the target object.

7. The computer system according to claim 1, wherein

the received update request for processing the target object is a move request for moving the target object, and

the first front-end node is configured to increment the local-lock counts of a source directory and a destination directory,

the source directory is the parent directory of the target object before the move thereof, and

the destination directory is the parent directory of the target directory after the move thereof.

8. The computer system according to claim 1, wherein the first front-end node is configured to

create locking information indicating all objects which are targets locked, and

send the back-end node a locking request to lock the all objects, the locking request being associated with the locking information.

9. The computer system according to claim 1, wherein the first front-end node is configured to

create unlocking information indicating all objects which are targets unlocked, and

send the back-end node an unlocking request to unlock the all objects, the unlocking request being associated with the unlocking information.

10. A computer for sharing objects with another computer that is coupled to a storage apparatus for providing a shared namespace to store the objects, the objects including at least directories, the computer comprising:

an interface that is coupled to the storage apparatus and a client;

a memory being configured to store management information including local-lock counts for each of directories, the local-lock count being the number of locks taken by operations to the objects including the directory and sub-objects thereof; and

a processor that is coupled to the interface and the memory,

the processor being configured to, every time an update request is received for processing a target object from the client, request the storage apparatus to lock a parent directory of the target object and increment the local-lock count for the parent directory when the parent directory has not been locked by the storage apparatus,

the processor being configured to send a response of the received update request to the client regardless of whether or not the parent directory has been unlocked by the storage apparatus, and

the processor being configured to, when the local-lock count of the parent directory is zero, request the storage apparatus to unlock the parent directory,

wherein the processor is configured to migrate not only the processed target object but also the parent directory thereof to the back-end node, and the first front-end node is configured not to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has not become zero, and the processor is configured to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has become zero,

wherein, the processor is configured to, when completing migration of the processed target object to the back-end node, decrement the local-lock counts of the processed target object and the parent directory thereof, and

wherein the processor is configured to, when at least one of the local-lock counts of the processed target object and the parent directory has become zero, request the back-end node to unlock the at least one of the processed target object and the parent directory whose local-lock count has become zero.

11. A method for sharing, by multiple front-end nodes that are coupled to clients, objects including at least directories managed in a namespace provided to the multiple front-end nodes by a back-end node, the method comprising:

managing, by a first front-end node that is any one of the multiple front-end nodes, local-lock counts for each of directories managed by the first front-end node, the local-lock count being the number of locks taken by operations to the objects including the directory and sub-objects thereof,

every time an update request is received for processing a target object from a client that is coupled to the first front-end node, requesting, by the first front-end node, the back-end node to lock a parent directory of the target object and increment the local-lock count for the parent directory when the parent directory has not been locked by the back-end node,

sending, by the first front-end node, a response of the received update request to the client regardless of whether or not the parent directory has been unlocked by the back-end node, and

requesting, by the first front-end node, the back-end node to unlock the parent directory, when the local-lock count of the parent directory is zero,

wherein the first front-end node is configured to migrate not only the processed target object but also the parent directory thereof to the back-end node, and the first front-end node is configured not to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has not become zero, and the first front-end node is configured to migrate the parent directory of the processed target object to the back-end node when the local-lock count of the parent directory of the processed target object has become zero,

wherein the first front-end node is configured to, when completing migration of the processed target object to the back-end node, decrement the local-lock counts of the processed target object and the parent directory thereof, and

wherein the first front-end node is configured to, when at least one of the local-lock counts of the processed target object and the parent directory has become zero, request the back-end node to unlock the at least one of the processed target object and the parent directory whose local-lock count has become zero.