Patent Publication Number: US-9886217-B2

Title: Storage system using a distributed partial hierarchical mapping

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2013-257477, filed on Dec. 12, 2013, the entire contents of which are incorporated herein by reference. 
     FIELD 
     The embodiment discussed herein is related to a storage device and a storage system. 
     BACKGROUND 
     In conventional stand-alone storage devices, device models have respective performance limits. When the load of operations increases, or the capacity limit of a single device is reached, a user has had to upgrade his or her device to an upper-level model, or to distribute services to be provided among a plurality of individual devices. 
     However, upgrading or distributing of services among a plurality of devices impairs the user&#39;s convenience. Recently, with an increasing amount of capacity demanded for storage devices as a backdrop, a scale-out type storage system has been desired. 
     In scale-out storage area network (SAN) devices, blocks are units of access. In such a SAN device, it is easy to process the user&#39;s requests by using a plurality of storage devices. Therefore, scale-out type storage has gained relatively widespread use. 
     In contrast, in scale-out network attached storage (NAS) devices, a consistent namespace has to be maintained by a plurality of storage devices. Therefore, in such a NAS device, the user&#39;s requests are not processed in parallel by simply using a plurality of storage devices. In scale-out NAS devices, a file system with a single namespace has to be provided to the user. There are a plurality of implementation schemes in scale-out NAS devices in accordance with differences in the meta data management scheme of the file system. 
       FIG. 13  and  FIG. 14  are diagrams for explaining conventional implementation schemes in a scale-out NAS device.  FIG. 13  is a diagram for explaining implementation employing internal mounts of a plurality of volumes by using junctions. In  FIG. 13 , each of nodes  81  to  84  is a storage device, and includes independent redundant array of inexpensive disks (RAID) and a file system. The plurality of nodes  81  to  84  connected over a network constitute one storage system. 
     A to E denote storage areas called volumes, and the user&#39;s file is created in a volume. The node  81  includes the volumes A and D, the node  82  includes the volume C, the node  83  includes the volume E, and the node  84  includes the volume B. 
     In the storage system, each volume is mounted at a junction point. This enables the storage system to be seen as a single namespace from the user. The junction point as used here is a point at which, when volumes are connected in a hierarchy as illustrated in  FIG. 13 , a volume at a lower level is connected to a volume at an upper level. For example, the volume B has junction points at which the volume D and the volume E are connected below the volume B. 
       FIG. 14  is a diagram for explaining implementation using a single namespace container. In  FIG. 14 , nodes  91  to  94  are storage devices, which are connected over a network and constitute one storage system. 
     D 1  to D 5  denote storage areas called file containers, and the user&#39;s file is created in a file container. The node  91  includes the file containers D 1  and D 4 , the node  92  includes the file container D 3 , the node  93  includes the file container D 5 , and the node  94  includes the file container D 2 . 
     The node  94  also includes a namespace container NS. The namespace container NS stores the names of files in association with file containers containing the files, and manages file names of the entire storage system. For example, the namespace container NS stores the fact that the file 1  is included in the container D 1 , the file 2  is included in the file container D 4 , and the file 3  is included in the file container D 3 . 
     Besides the two implementation schemes, there is a implementation scheme in which a storage system including a plurality of storage devices provides a single namespace and a single file container to stripe data across a plurality of storage devices. 
     Additionally, there is an example of related arts in which a plurality of file systems provided by separate NAS systems are integrated into a single “global” namespace, and the integrated namespace is provided to NAS clients. 
     There is another example of related arts in which restrictions are totally imposed on storage resources of a plurality of file systems in a network storage system where the plurality of file systems are virtualized as one file system to enable access to that file system. 
     Related techniques are disclosed in, for example, Japanese Laid-open Patent Publication No. 2008-159027 and Japanese Laid-open Patent Publication No. 2006-92322. 
     The implementation scheme employing internal mounts of a plurality of volumes by using junctions has an advantage in that the overhead involved in scaling out is small, because architecture before scale-out, almost exactly as it is, may be utilized, and a file is possessed and managed by a specific node in units of volumes. However, this implementation scheme has a problem in that files may be assigned to nodes only at a coarse granularity, that is, in units of volumes. 
     The implementation scheme using a single namespace container NS has an advantage in that files may be assigned to nodes in units of files, but a problem in that there is an overhead of making an inquiry to a namespace container NS about the storage node of a file. 
     SUMMARY 
     According to an aspect of the present invention, provided is a storage device of constituent storage devices included in a storage system. The storage device includes a first storage unit, a second storage unit, a third storage unit, and a processor. The first storage unit is configured to store therein a part of a data group stored in the storage system. The second storage unit is configured to store therein partial hierarchical information which is a part of information on a hierarchical structure of the data group. The third storage unit is configured to store therein owner information including a data identifier in association with a device identifier. The data identifier identifies a specific data included in the data group. The specific data is related to the partial hierarchical information. The device identifier identifies a specific device of the constituent storage devices. The specific device stores therein the specific data. The processor is configured to share management of the data group with other devices of the constituent storage devices on basis of the partial hierarchical information and the owner information. 
     The objects and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims. 
     It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed. 
    
    
     
       BRIEF DESCRIPTION OF DRAWINGS 
         FIG. 1  is a diagram for explaining information owned by nodes according to an embodiment; 
         FIG. 2  is a diagram illustrating a configuration of a storage system according to the embodiment; 
         FIG. 3  depicts an example of an i-node table; 
         FIG. 4  depicts an example of a node management table; 
         FIG. 5  is a diagram illustrating a functional configuration of a management unit; 
         FIG. 6  is a diagram for explaining cache of directory information; 
         FIG. 7  is a diagram for explaining movement of a file between nodes; 
         FIG. 8  is a flowchart illustrating the flow of a file creation process; 
         FIG. 9  is a flowchart illustrating the flow of a file reading process; 
         FIG. 10  is a flowchart illustrating the flow of a file update process; 
         FIG. 11  is a flowchart illustrating the flow of a file update process accompanied by movement of a file; 
         FIG. 12  is a diagram for explaining co-owning of a file by a plurality of nodes; 
         FIG. 13  is a diagram for explaining implementation employing internal mounts of a plurality of volumes by using junctions; and 
         FIG. 14  is a diagram for explaining implementation using a single namespace container. 
     
    
    
     DESCRIPTION OF EMBODIMENT 
     Hereinafter, an embodiment of a storage device and a storage system will be described in detail with reference to the accompanying drawings. It is to be noted that this embodiment is not intended to limit the disclosed techniques. 
     Embodiment 
     First, information owned by a node according to the embodiment will be described.  FIG. 1  is a diagram for explaining information owned by nodes according to the embodiment. As illustrated in  FIG. 1 , a storage system  1  includes a plurality of nodes  10  connected over a protocol network  2  one another. 
     A node  10  is a storage device including a storage area in which files are stored. The protocol network  2  is a network for connecting the storage system  1  and a client  20  which is a terminal device used by a user to use the storage system  1 . Note that although three nodes  10  (node#1, node#2, and node#3), and one client  20  are included here, the storage system  1  may include any numbers of nodes  10  and clients  20 . 
     The entire storage system  1  provides one file system and a namespace. A namespace tree  21  is a tree indicating a configuration of directories and files included in a file system. In the namespace tree  21  illustrated in the drawings, circles indicate directories and files, and links indicate the parent-child relationship between directories or between a directory and a file. 
     Each node  10  stores information on a namespace branch  21   a , which is part of the namespace tree  21 , and shares and stores information on the namespace tree  21  in such a manner that when namespace branches  21   a  included in all the nodes  10  are gathered together, the namespace tree  21  is obtained. 
     In association with a directory or file in the namespace branch  21   a , each node  10  stores a number identifying the node  10  that stores information on the directory or file. For example, in association with a root directory  21   b , the node#1 stores “1”, “2”, and “3” as numbers of the nodes  10  that store information on the root directory  21   b . In association with a directory  21   c  which is a child of the root directory  21   b , the node#1 stores “1” and “2” as numbers of the nodes  10  that store information on the directory  21   c . In association with a file  21   d , which is a child of the directory  21   c , the node#1 stores “1” as the number of the node  10  that stores information on the file  21   d.    
     Similarly, the node#2 stores numbers of the nodes  10  that store information on the root directory  21   b , and numbers of the nodes  10  that store information on the directory  21   c  and a directory  21   e , which are children of the root directory  21   b . The node#2 also stores the number of the node  10  that stores information on a file  21   f , which is a child of the directory  21   c.    
     Similarly, the node#3 stores numbers of the nodes  10  that store information on the root directory  21   b , and numbers of the nodes  10  that store information on the directory  21   e , which is a child of the root directory  21   b . The node#3 also stores number of the node  10  that stores information on a file  21   g , which is a child of the directory  21   e.    
     Then, for example, a node  10  (hereinafter referred to as a “reception node  10 ” for simplicity) that has received a file access request from the client  20 , traces information on the namespace branch  21   a  from the root to a location that matches a path of the file access request. If the reception node  10  owns a file specified by the file access request, the reception node  10  executes the file access request. If, however, the reception node  10  does not own that file, the reception node  10  transmits the file access request to the node  10  of another number associated with the final directory that matches the path of the file access request. 
     For example, in  FIG. 1 , when the node#1 receives an access request to access a file  22  in the namespace tree  21 , the node#1 traces information on the namespace branch  21   a  from the root, and identifies the directory  21   c , which matches the path of the access request. Here, it is found that the node#1 does not own information on the file  22 , and it is also found that the node#2 owns information on the directory  21   c . Accordingly, the node#1 sends the access request to the node#2. 
     In this way, the node  10  has information on the namespace branch  21   a , which is part of the namespace tree  21 . In association with a directory or file in the namespace branch  21   a , the node  10  stores a number identifying the node  10  that stores information on the directory or file. If the node  10  does not own a target file of an access request, the node  10  transmits the access request to the node  10  of a number associated with the directory in the namespace branch  21   a . Accordingly, even if the node  10  does not own a target file of an access request, the node  10  does not have to make an inquiry to a namespace container NS about the storage node of the file. This may reduce an overhead entailed in that inquiry. 
     Next, the configuration of the storage system  1  according to the embodiment will be described.  FIG. 2  is a diagram illustrating a configuration of the storage system  1  according to the embodiment. As illustrated in  FIG. 2 , in the storage system  1 , a plurality of nodes  10  are connected with one another over an inter-node network  3  in addition to the protocol network  2 . The inter-node network  3  is used for, for example, communication among the nodes  10  such as transfer of a user request and movement of files between the nodes  10 . 
     Each node  10  includes a protocol interface  11 , an inter-node interface  12 , a central processing unit (CPU)  13 , a memory  14 , a non-volatile memory  15 , and a RAID  16 . 
     The protocol interface  11  is an interface for communication with the client  20  over the protocol network  2 . The inter-node interface  12  is an interface for communication with other nodes  10  over the inter-node network  3 . 
     The CPU  13  is a central processing unit that executes programs stored in the memory  14 . The memory  14  is a random access memory (RAM) that stores programs, intermediate results of computations, data stored in the RAID  16 , and so forth. The non-volatile memory  15  is a flash memory that saves data stored in the memory  14  when a failure occurs in the node  10 . 
     The RAID  16  is a storage device that stores therein data, and includes a data save area  30 . The RAID  16  also stores a management program  40  for managing data stored in the RAID  16 . When loaded into the memory  14  and executed by the CPU  13 , the management program  40  may give the CPU  13  a function as a management unit that manages data stored in the RAID  16 . 
     The data save area  30  stores user data, and stores metadata used for management of user data in an i-node table storage unit  31 , a node management table  32 , and so forth. 
     The i-node table storage unit  31  is a storage unit that stores therein a plurality of i-node tables  31   a . Each i-node table  31   a  stores therein information on direct child directories or files included in one directory. 
       FIG. 3  depicts an example of an i-node table  31   a . As illustrated in  FIG. 3 , the i-node table  31   a  stores, in each entry for a direct child directory or file, a referenced i-node, a file name or directory name, attribute information, and owing nodes. 
     The referenced i-node is information indicating a location (hereinafter referred to as a “storage location”) where the i-node table  31   a  corresponding to the direct child directory is stored. The referenced i-node indicates hierarchical structure information of the namespace tree  21 . 
     The file name or directory name is the name of a file when the direct child is a file, and is the name of a directory when the direct child is a directory. The attribute information is information on whether it is possible to write data, and the like. The owing node indicates the number of the node  10  that owns information on a directory or file, corresponding to the referenced i-node. 
     For example, assuming that “AAA” is a directory name, for the directory whose name is “AAA”, the storage location of the corresponding i-node table is “xxxxx2”, the attribute information is “xxx2”, and the numbers of the nodes  10  that own information on the directory are “2” and “3”. 
     In this way, the i-node table  31   a  stores the numbers of the nodes  10  that own information on a directory or file in association with the directory or file. Accordingly, when a node  10  does not own file information or directory information, the node  10  may identify another node  10  that owns the file information or directory information. This may reduce an overhead of making an inquiry to a namespace container NS about a transfer destination. 
     The node management table  32  is a table that stores therein information on the nodes  10 .  FIG. 4  depicts an example of the node management table  32 . As illustrated in  FIG. 4 , the node management table  32  stores, in each entry for a node  10 , a node number, a total capacity, a free space, a performance index, and a CPU load factor. 
     The node number is a number identifying a node  10 . The total capacity is the maximum capacity of data stored in the node  10 . The free space is the capacity of an area left for storage of data. The performance index is a value representing the performance with which the node  10  processes data. The CPU load factor is a value representing the load condition of the CPU  13 . Note that each node  10  performs polling at regular intervals of, for example, one minute to notify other nodes of the free space and the CPU load factor by which the free space and the CPU load factor are shared among all the nodes  10 . 
     For example, in the node  10  whose number is “1”, the maximum capacity of data stored is “100 TB”, the capacity of an area left for storing data is “50 TB”, the value representing the processing performance is “2”, and the load condition of the CPU  13  is “20%”. 
     Next, the function of the management unit implemented by executing the management program  40  will be described.  FIG. 5  is a diagram illustrating a functional configuration of a management unit. As illustrated in  FIG. 5 , the management unit includes a creation unit  41 , a reading unit  42 , an updating unit  43 , a cache unit  44 , and a moving unit  45 . 
     The creation unit  41  creates a directory or file, based on a request from the client  20 . Note that the client  20  may transmit an access request to access the storage system  1  to an arbitrary node  10 . 
     The creation unit  41  traces the namespace branch  21   a  to a directory at the lowest level, and lists the nodes  10  each of which owns a branch including a directory or file to be created, as target node candidates. If the traced directory is not a parent of the directory or file to be created and the number of target node candidates is larger than a certain number, the creation unit  41  further traces the namespace branch  21   a  in one of the target node candidates to a directory at the lowest level, and lists target node candidates. If, the traced directory is a parent of the directory or file to be created or the number of target node candidates is equal to or less than the certain number, the creation unit  41  selects a target node  10  from among the target node candidates on the basis of the free spaces and the CPU load factors of the target node candidates. 
     Then, the creation unit  41  of the target node  10  creates a directory or file to be created. Note that if the target node  10  does not own directories to be traced until the directory or file to be created is reached, the creation unit  41  also creates the directories. Then, the creation unit  41  of the target node  10  instructs other listed target node candidates to update ownership information. The node  10  that has received the request from the client  20  provides a completion response to the client  20  upon receiving, from all the target node candidates, responses indicating that processing has been completed. 
     When selecting the target node  10  from among target node candidates, the creation unit  41  determines whether there is a target node candidate whose free space is equal to or larger than a certain value. If there is such a target node candidate, the creation unit  41  selects a node  10  with a load less than a certain value, as the target node  10 . If, however, there is no node  10  with a load less than the certain value, the creation unit  41  selects a least loaded node  10 , as the target node  10 . If there is no target node candidate whose free space is equal to or larger than the certain value, the creation unit  41  selects a node  10  whose free space is largest, as the target node  10 . The certain value of the free space is, for example, 30%, and the certain value of the load is, for example, 50%. 
     Based on a request from the client  20 , the reading unit  42  reads information on a directory, or a file, and sends the read information or the file to the client  20 . In particular, the reading unit  42  traces the namespace branch  21   a  to a directory at the lowest level. If an object to be read is owned, the reading unit  42  reads information on the directory, or the file, and transmits it to the client  20 . 
     If, however, the object to be read is not owned, the reading unit  42  instructs a node  10  that owns a branch including the object to be read to check whether information on the object to be read is owned. Note that a plurality of nodes  10  may be given instructions for the checking in some cases. The reading unit  42  of the node  10 , which is given the instruction for the checking, checks whether the object to be read is owned. If the object to be read is owned, the reading unit  42  transmits information on the object to be read to the node  10  that has issued the instruction for the checking, and this node  10  that has issued the instruction for the checking transmits the information to the client  20 . 
     The updating unit  43  updates a file in accordance with a request from the client  20 . In particular, the updating unit  43  traces the namespace branch  21   a  to a directory at the lowest level. If an object to be updated is owned, the updating unit  43  updates a file and gives the client  20  a response indicating that updating has been completed. 
     If, however, the object to be updated is not owned, the updating unit  43  instructs a node  10  that owns a branch including the object to be updated to check whether a file as the object to be updated is owned. Note that a plurality of nodes  10  may be given instructions for the checking in some cases. Then, the updating unit  43  of the node  10 , which is given the instruction for the checking, checks whether then object to be updated is owned. If the object to be updated is owned, the updating unit  43  updates the file and transmits a response indicating completion of updating to the node  10  that has issued the instruction for the checking. Then, the node  10  that has issued the instruction for the checking gives the client  20  a response indicating that updating has been completed. 
     The cache unit  44  caches directory information, which is a part of the namespace tree  21 . A directory may contain information on another node  10  that owns a file that is not owned by the node  10  including the cache unit  44 . If all the nodes  10  even at the lowest levels include caches, penalties increase due to cache updates for write processing. Accordingly, the cache unit  44  takes statistics on the frequencies of read and write processing for every directory hierarchy, and automatically adjusts directory hierarchy levels included in each node  10  so that the performance is optimized. 
     In a completely read only environment, every node  10  will have information on a complete tree structure of a file system. In contrast, in a completely write only environment, every node  10  will have only information on a tree structure of a file system owned by that node  10 . 
       FIG. 6  is a diagram for explaining cache of directory information. In  FIG. 6 , although the information on the file  22  is owned by the node#2, a cache  22   a  is also stored in the node#1. 
     The moving unit  45  performs movement of a file between the nodes  10  based on the namespace branch  21   a  as background processing to keep loads in balance among the nodes  10 .  FIG. 7  is a diagram for explaining movement of a file between the nodes  10 . 
     In  FIG. 7 , in a situation in which the node#2 is highly loaded, or the free space is small, the file  22  owned by the node#2 is moved to the node#1. The nodes  10  that each own a parent directory  22   c  of the file  22  are the node#1 and the node#2. Accordingly, when moving the file  22 , the moving unit  45  selects the node#1, which owns the parent directory  22   c , as the movement destination. Selecting the node#1 that owns the parent directory  22   c  enables the moving unit  45  to move the file  22  with ease as compared with the case where the moving unit  45  selects the node#3 that does not own the parent directory  22   c.    
     Next, the flow of a file creation process will be described.  FIG. 8  is a flowchart illustrating the flow of the file creation process. Note that the flow of the process of creating a directory is obtained by replacing the “file creation request” with a “directory creation request” and the “target file” with a “target directory” in  FIG. 8 . 
     As illustrated in  FIG. 8 , upon receipt of a file creation request from the client  20  (S 1 ), the creation unit  41  traces the namespace branch  21   a  along the path of a target file within the node  10  including the creation unit  41  (S 2 ). Then, the creation unit  41  checks a directory at the lowest level at which the creation unit  41  has arrived (S 3 ), and lists the nodes  10  that each own a branch including the target file, as target node candidates (S 4 ). 
     Then, the creation unit  41  determines whether the directory at the lowest level is a parent directory of the target file (S 5 ). If so, the creation unit  41  refers to the free spaces and the CPU load factors of the target node candidates, and decides upon the target node  10  in which the target file is to be created (S 6 ). 
     Then, the creation unit  41  of the target node  10  creates the target file, and target node candidates except for the target node  10  update ownership information (S 7 ). Upon receiving completion responses from all the target node candidates, the node  10  that has received the file creation request from the client  20  gives a completion response to the client  20  (S 8 ). 
     If, however, the directory at the lowest level is not a parent directory of the target file, the creation unit  41  determines whether the number of target node candidates is equal to or less than a certain number (S 9 ). If the number of target node candidates is equal to or less than the certain number, the creation unit  41  refers to the free spaces and the CPU load factors of the target node candidates, and decides upon the target node  10  in which the target file is to be created (S 10 ). 
     Then, the creation unit  41  traces the namespace branch  21   a  along the path of the target file within the target node  10  (S 11 ). If the target node  10  does not own directories to be traced as far as the target file, the creation unit  41  creates directories to be traced as far as the target file (S 12 ), and proceeds to S 7 . 
     If, however, the number of target node candidates is not equal to or less than the certain number, the creation unit  41  traces the namespace branch  21   a  along the path of the target file in any of the target node candidates (S 13 ). Then, the creation unit  41  checks a directory at the lowest level at which the creation unit  41  has arrived (S 14 ), and lists the nodes  10  that each own a branch including the target file, as target node candidates (S 15 ). Then, the creation unit  41  returns to S 5 . 
     In this way, by tracing the namespace branch  21   a , the creation unit  41  decides upon the node  10  in which the target file is to be created. The node  10  in which the target file is to be created may therefore be efficiently decided upon. 
     Next, the flow of a file reading process will be described.  FIG. 9  is a flowchart illustrating the flow of the file reading process. Note that the flow of the process of reading a directory is obtained by replacing the “file read request” with a “directory read request”, the “target file” with a “target directory”, and the “file data” with “directory information” in  FIG. 9 . 
     As illustrated in  FIG. 9 , upon receipt of a file read request from the client  20  (S 21 ), the reading unit  42  traces the namespace branch  21   a  along the path of a target file within the node  10  including the reading unit  42  (S 22 ). Then, the reading unit  42  determines whether the reading unit  42  has arrived at the target file (S 23 ). If the reading unit  42  has arrived at the target file, the reading unit  42  transmits the target file to the client  20  (S 24 ). 
     If, however, the reading unit  42  has not arrived at the target file, the reading unit  42  picks a target node candidate that owns the target file, based on the last directory information at which the reading unit  42  has arrived (S 25 ). Then, the reading unit  42  sends, to the target node candidate, a file read request in and below the directory at which the reading unit  42  has arrived (S 26 ). 
     Then, the reading unit  42  of the node  10  that has received the file read request traces the namespace branch  21   a  in and below the received directory, and picks the target file (S 27 ). Then, the reading unit  42  of the node  10  that owns the target file sends file data to the node  10  as the request source (S 28 ). 
     Then, the reading unit  42  of the node  10  that has received the file read request from the client  20  receives file data from the node  10  that owns the target file (S 29 ), and transmits the target file to the client  20  (S 30 ). 
     In this way, by tracing the namespace branch  21   a , the reading unit  42  identifies the node  10  that owns the target file. The node  10  that owns the target file may therefore be efficiently identified. 
     Next, the flow of a file update process will be described.  FIG. 10  is a flowchart illustrating the flow of the file update process. As illustrated in  FIG. 10 , upon receipt of a file update request from the client  20  (S 41 ), the updating unit  43  traces the namespace branch  21   a  along the path of a target file within the node  10  including the updating unit  43  (S 42 ). Then, the updating unit  43  determines whether the updating unit  43  has arrived at the target file (S 43 ). If the updating unit  43  has arrived at the target file, the updating unit  43  updates the target file (S 44 ), and gives a completion response to the client  20  (S 45 ). 
     If, however, the updating unit  43  has not arrived at the target file, the updating unit  43  picks a target node candidate that owns the target file, based on the last directory information at which the updating unit  43  has arrived (S 46 ). Then, the updating unit  43  sends, to the target node candidate, a file update request in and below the directory at which the updating unit  43  has arrived (S 47 ). 
     Then, the updating unit  43  of the node  10  that has received the file update request traces the namespace branch  21   a  in and below the received directory, and picks the target file (S 48 ). Then, the updating unit  43  of the node  10  that owns the target file updates the target file (S 49 ), and gives a completion response to the node  10  as the request source (S 50 ). 
     Then, the updating unit  43  of the node  10 , which has received the file update request from the client  20 , receives the completion response from the node  10  that owns the target file, and gives a completion response to the client  20  (S 45 ). 
     In this way, by tracing the namespace branch  21   a , the updating unit  43  identifies the node  10  that owns the target file. The node  10  that owns the target file may therefore be efficiently identified. 
     As described above, in the embodiment, the node  10  has information on the namespace branch  21   a , which is a part of the namespace tree  21 . The node  10  stores, in the namespace branch  21   a , numbers identifying the nodes  10  that store information on a directory or file in association with the directory or file. When the node  10  does not own a target directory or file of an access request, the node  10  transmits an access request to the node  10  of a number associated with the directory in the namespace branch  21   a . Accordingly, when the node  10  does not own a target directory or file of an access request, the node  10  does not have to make an inquiry to a namespace container NS about the storage node of the file. This may reduce an overhead entailed in that inquiry. 
     In the foregoing embodiment, the example in which movement of a file between the nodes  10  based on the namespace branch  21   a  is performed as background processing has been described. However, movement of a file may be performed at the time of file updating. The case where a file is moved at the time of file updating will be described. 
       FIG. 11  is a flowchart illustrating the flow of a file update process accompanied by movement of a file. As illustrated in  FIG. 11 , upon receipt of a file update request from the client  20  (S 61 ), the updating unit  43  traces the namespace branch  21   a  along the path of a target file within the node  10  including the updating unit  43  (S 62 ). 
     Then, the updating unit  43  determines whether the updating unit  43  has arrived at the target file (S 63 ). If the updating unit  43  has arrived at the target file, the updating unit  43  lists the nodes  10  that each have a parent directory of the target file, as target node candidates (S 64 ). Then, the updating unit  43  selects a target node  10  from among the target node candidates on the basis of their free spaces and CPU load factors (S 65 ). Then, the updating unit  43  instructs the target node  10  to create a file and deletes the file within the node  10  including the updating unit  43  (S 66 ). Then, the updating unit  43  gives a completion response to the client  20  (S 67 ). 
     If, however, the updating unit  43  has not arrived at the target file, the updating unit  43  picks a target node candidate that owns the target file, based on the last directory information at which the updating unit  43  has arrived (S 68 ). Then, the updating unit  43  sends, to the target node candidate, a file update request in and below the directory at which the updating unit  43  has arrived (S 69 ). 
     Then, the updating unit  43  of the node  10  that has received the file update request traces the namespace branch  21   a  in and below the received directory, and picks the target file (S 70 ). Then, the updating unit  43  of the node  10  that owns the target file updates the target file (S 71 ), and lists the nodes  10  that each have a parent directory of the target file, as target node candidates (S 72 ). 
     Then, the updating unit  43  of the node  10  that owns the target file selects a target node  10  from among the target node candidates on the basis of the free spaces and the CPU load factors (S 73 ). Then, the updating unit  43  of the node  10  that owns the target file instructs the target node  10  to create a file and deletes the file within the node  10  including the updating unit  43  (S 74 ). Then, the updating unit  43  of the node  10  that owns the target file gives a completion response to the node  10  as the request source (S 75 ). The node  10  as the request source gives a completion response to the client  20  (S 67 ). 
     In this way, when updating a file, the updating unit  43  selects the target node  10  on the basis of the free spaces and the CPU load factors, instructs the target node  10  to create a file, and deletes a file within the node  10  in which this updating unit  43  is included. Thus, it is possible to keep loads in balance among the nodes  10 . 
     Although, in the foregoing embodiment, the case where a specific node  10  possesses a file has been described, providing co-owned node information to a file enables the file to be shared by a plurality of nodes  10 . In accordance with the management program  40 , the node  10  that has received a request from the client  20  may select a plurality of logically close or less loaded nodes  10 , and send a request in a distribution manner to the plurality of nodes  10 . Thus, the performance of sequential access may be improved owing to spanning. Co-owning a file among a plurality of nodes  10  may increase redundancy for a specific file or for each namespace branch  21   a . The node  10  that has received a request from the client  20  may redundantly encode a file to stripe the file across a plurality of nodes  10 . This may improve sequential access performance and secure redundancy. 
       FIG. 12  is a diagram for explaining co-owning of a file among a plurality of nodes  10 .  FIG. 12  illustrates the case where the file  22  is co-owned by the node#1 and the node#2. In the node#1 and the node#2, node numbers “1” and “2” are associated with the file  22 . 
     In the embodiment, the case where hierarchical structure information of the namespace tree  21  and information on the owing nodes  10  are stored using a plurality of i-node tables  31   a  has been described. However, embodiments are not limited to this, and may be similarly applied to the case where the hierarchical structure information of the namespace tree  21  and the information on the owing nodes  10  are separately stored. 
     All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiment of the present invention has been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.