JP2006185463A - Gateway device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To access to a distributed file system (DFS) using a conventional protocol such as an NFS or CIFS without change on a client side. <P>SOLUTION: A DFS server 2 is provided with a gateway section 25 for receiving the conventional protocol and applies processing corresponding to it to the DFS. The gateway section 25 emulates the directory structure existing in the file system such as the NFS or CIFS. When the DFS is a recordable file system, the update processing is converted into a new generation's creation processing, and reference processing is converted into the access to the newest generation of a file group managed every generation. The gateway section 25 accesses the file via a DFS processing section 26. <P>COPYRIGHT: (C)2006,JPO&NCIPI

Description

  The present invention relates to a gateway apparatus included in a distributed file system (DFS: distributed file system), and in particular, distributed that configures one file system by distributing and storing files on a plurality of servers on a network. The present invention relates to a gateway device included in a file system.

  As a network file system, a file system constructed on an OS such as UNIX (registered trademark) called NFS or CIFS (Common Internet File System) is known. These file systems are centralized file systems in which one file system is configured by one server, and the file entity exists on a specific server. When accessing a file from a client, each client first accesses a server on which the file exists using each protocol. The client then uses the directory structure to identify the file on the server.

  On the other hand, DFS such as OceanStore uses an identifier uniquely assigned by a system called GUID instead of specifying a server or path name when a client accesses a file. In the case of DFS, the existence of a file exists on any of a plurality of DFS servers existing on the network. The file entity need not be owned by only one server, but may exist on another server as a copy. In addition, the file entity does not have to hold the entire file by one DFS server, and the file is divided into several parts, and one divided part (called a fragment) is divided into one DFS server. May exist and other fragments may exist on other DFS servers.

  When a client accessing a file in DFS refers to or writes to the file, the client specifies any file by specifying a GUID and accesses any one server on the network.

As a conventional technique close to the present invention, a system provided with a communication interface in which a storage server is responsible for connection to all types of user data is described in, for example, Patent Document 1 and the like.
JP 2000-339098 A

  Since DFS has characteristics different from those of network file systems such as NFS and CIFS, in order to access a DFS file, it must be accessed using a dedicated DFS protocol. For this reason, conventional clients that use only protocols such as NFS and CIFS cannot access DFS files, and the client side is compatible with DFS, for example, by improving the programs used in the past. There was a need to make changes.

  An object of the present invention is to provide a gateway device included in a distributed file system that allows a DFS file to be accessed using a conventional protocol without making any changes on the client side. It is in.

  According to the present invention, the object is to provide a distributed file system that can be accessed using a protocol for accessing a centralized file system, on a network, with a plurality of DFS servers that store files in a distributed manner. And at least one of the plurality of DFS servers includes a gateway unit that accesses a distributed file by converting a protocol for accessing a centralized file system into an accessible protocol by accessing the distributed file. Achieved.

  Another object of the present invention is to access a centralized file system in a distributed file system server in which distributed files are stored in a distributed file system that can be accessed using a protocol for accessing the centralized file system. It is achieved by comprising a gateway unit that converts the distributed file into an accessible protocol and accesses the distributed file.

  Furthermore, the object is to provide a protocol for accessing a centralized file system in a method for accessing a distributed file system using a protocol for accessing a centralized file system. Is achieved by converting the distributed file into an accessible protocol and accessing the distributed file.

  According to the present invention, it is possible to access a file on the DFS using a conventional protocol such as NFS or CIFS without changing on the client side.

  Embodiments of a gateway device according to the present invention will be described below in detail with reference to the drawings.

  FIG. 1 is a block diagram showing a configuration example of a distributed file system including a gateway device according to an embodiment of the present invention. In FIG. 1, 1 is a network, 2 is a DFS server, 3 is a DFS client, 4 is an NFS client, and 5 is a CIFS client.

  A distributed file system (DFS) according to an embodiment of the present invention shown in FIG. 1 is a network system, a plurality of DFS servers 2 connected to the network 1, and a file system on the network 1 using a protocol for DFS. The NFS client 4 and the CIFS client 5 which are conventional protocol clients for accessing by a conventional protocol for accessing a file system realized by the DFS client 3 for accessing and one file server on the network 1 such as NFS or CIFS. It consists of.

  In the DFS shown in FIG. 1, a DFS client 3 on the network 1 accesses a single DFS server 2 using a dedicated DFS protocol, and references and writes to a file. A file on the DFS is given an identifier called GUID, which is a number that can be uniquely identified in the system, and is used for specifying the file from the DFS client 3 at the time of reference. The GUID for the file is uniquely assigned by the DFS server 2 when the file is written, and is notified to the DFS client 3 as a write response.

  More specifically, when referring to a file, the DFS client specifies a GUID and specifies and accesses one of the DFS servers 2 on the network. When the accessed DFS server 2 does not have a file entity on its own server, the DFS server 2 makes an inquiry to another DFS server 2 in which the file entity exists, collects data, and stores the file entity on its own DFS server. By constructing, it is possible to access the client.

  Further, when writing a file, the DFS client transmits the write data to one DFS server. In response to the write, the client receives a GUID from the server. Access to the written file is performed using the GUID received from this server.

  In the case of DFS, the same file entity may exist on a plurality of DFS servers. In such a situation, when the client performs update writing to change the contents of data once written, it is difficult to guarantee the consistency of file data in each DFS server. For this reason, in some DFS, writing to a file specified by GUID is performed only once, update writing does not exist, and only writing can be performed after writing once. A file system having such characteristics is called a write-once file system.

  In the case of the write-once file system, a change in the file contents for update writing is performed when writing to a new file generation, that is, a new GUID is allocated to the new generation. Become. These series of generations are managed as a file group.

  The DFS according to the embodiment of the present invention shown in FIG. 1 is a write-once file system as described above, and it is not possible to update the contents of a file assigned with a GUID once written. . Instead, the DFS shown in FIG. 1 has a generation in the file, and the processing for update writing to the file corresponds to creating a new generation file. A different GUID is assigned to each generation, but a collection of files of different generations is managed as a file group. A uniquely identifiable file group identifier is also assigned to this file group. A GUID for identifying a file can be obtained by designating a generation number indicating a file group identifier and a generation.

  FIG. 2 is a diagram for explaining an example of a method for obtaining a GUID from a file group identifier and a generation number. As shown in FIG. 2, a GUID having the upper bits in the GUID as the file group identifier 61 and the remaining lower bits as the generation number 62 is used. The example shown in FIG. 2 is one example, and the GUID may be obtained by another method.

  The NFS client 4 and the CIFS client 5, which are conventional protocol clients, access a file using a conventional network file system protocol that is not a DFS protocol. Usually, when these conventional protocol clients access a file, as described above, a directory structure is used to identify the file.

  FIG. 3 is a diagram for explaining the directory structure used by a conventional protocol client. The directory structure will be described with reference to FIG. In FIG. 3, the directory is represented by a square surrounded by a solid line, and the file is represented by a square surrounded by a broken line.

  All directories are defined by a tree structure belonging to the root directory 41 (indicated by “/”). All the files belong to any one (or plural) of the tree-structured directories. Such a tree-structured directory has a form in which a name (file name) can be uniquely assigned to files in one directory. For this reason, when a file is specified, a path name indicating a directory to which the file belongs and a file name of the file need only be specified. For example, the file 45 shown in FIG. 3 can be specified in the form of / dira / dira2 / dira22 / file0001. Therefore, when a client performs access such as reference or update to a file, the file is specified by specifying the path name and file name for the server on which the file exists, and then the reference or update of the file is performed. Will make a request.

  The embodiment of the present invention eliminates the need for changes such as incorporating new software on the client side, and allows conventional protocol clients such as NFS and CIFS to access DFS files. The structure of will be described.

  FIG. 4 is a block diagram showing the configuration of the DFS server, and FIG. 5 is a block diagram showing the configuration of the gateway unit. 4 and 5, 21 is a DFS control unit, 22 is a disk drive, 23 is a main memory, 24 is an OS, 25 is a gateway unit, 26 is a DFS processing unit, 27 is a disk drive processing unit, 28 is a CPU, 29 Is an HDD, 31 is a conventional protocol processing unit, 32 is a DFS access unit, and 33 is a directory management unit.

  As shown in FIG. 4, the DFS server 2 includes a CPU 28 that executes processing of the entire server, a main memory 23, a disk drive 22 that includes a disk for storing files, and an OS that is used in the main memory 23. And an HDD 29 for storing applications and the like. The main memory 23 includes an OS 24 and a DFS control unit 21, and the DFS control unit 21 includes a gateway unit 25, a DFS processing unit 26, and a disk drive processing unit 27.

  The DFS control unit 21 functions as a DFS server by running a program that provides a DFS function on the CPU 28. Then, the DFS control unit 21 performs the processing of the gateway unit 25, the DFS processing unit 26, and the disk drive processing unit 27 via the network 1 (conventional protocol clients such as the NSF client 4 and the CISF client 5 and the DFS client 3). In addition, processing is performed for a request from another DFS server 2.

  The DFS processing unit 26 receives a request according to the DFS protocol, makes a processing request to the disk drive processing unit 27 or another DFS server 2 in accordance with the request, creates a response from the result, and returns it to the request source.

  The gateway unit 25 receives the same request from the NFS client or CIFS client as that for the network file system of the conventional protocol such as NFS or CIFS, and requests other processing units for processing according to the request as necessary. After processing, the result of processing for the request is returned as a response to the NFS client or CIFS client client.

  As described above, the DFS server 2 can access and respond to requests from conventional protocol clients in the same manner as the conventional protocol file server.

  The gateway unit 25 does not have to exist on all the DFS servers 2, and only needs to exist on the DFS server 2 that can be an access point from a client of a conventional protocol. That is, the gateway unit 25 is required only for a DFS server that is accessed from a client of a conventional protocol. For this reason, when accessing from the normal DFS client 3, the gateway unit 25 is not necessary.

  As shown in FIG. 5, the gateway unit 25 includes a conventional protocol processing unit 31, a DFS access unit 32, and a directory management unit 33.

  The conventional protocol processing unit 31 is a processing unit that performs a process of receiving a conventional protocol from an NFS client or a CIFS client and returning a response according to the conventional protocol. The conventional protocol processing unit 31 exists for each protocol to be accepted, determines the contents of the corresponding protocol, and requests processing from other processing units in response to the request.

  The DFS access unit 32 is a processing unit that receives a request from the conventional protocol processing unit 31 and performs a bridge with the DFS processing unit 26 in the DFS control unit 21. That is, the DFS access unit 32 is a processing unit for creating a request for DFS in response to a request from the conventional protocol processing unit 31 and accessing the DFS file via the DFS processing unit 26.

  The directory management unit 33 is a processing unit for managing the correspondence between a file on the directory structure of the file system of the conventional protocol and a GUID that is a file identifier in DFS. A file is specified by a conventional protocol by a path name indicating a directory in which the file exists and a file name unique within the directory. On the other hand, the designation of a file by DFS is performed by an identifier that is unique in the system called GUID. When the DFS has a structure corresponding to a directory in the conventional protocol, it is possible to take correspondence between the file of the conventional file system and the GUID by using the structure. However, some DFSs do not have a structure corresponding to a directory. That is, a DFS that does not have a structure corresponding to this directory can uniquely recognize a file in the entire system only by GUID, and therefore does not require a structure corresponding to a file path.

  A DFS having no directory structure needs a mechanism for associating a GUID with a file specified by a directory structure path in order to enable access using a conventional protocol. The directory management unit 33 that performs this provides a mechanism for associating the file specified by the directory structure path with the GUID.

  The directory management unit 33 performs processing for directory operations and directory information read requests from conventional protocols. For this reason, the directory management unit 33 has directory management information equivalent to the directory management information possessed by the file system of the conventional protocol.

  FIG. 6 is a diagram for explaining the structure of the directory management information 50. Directory management information 50 includes a plurality of entries 51. An entry 51 exists for each directory or file described with reference to FIG.

  Each entry 51 is p_parent 52 which is a pointer to an entry of a parent directory which is a directory to which the directory or file belongs, and p_subdir 53 which is a pointer to one of the directories or files belonging to the directory when the entry 51 is a directory. And p_child 54 that is a pointer pointing to entries in the same directory, and f_name 55 that stores the name of the directory or file. If the entry 51 is a file, a file group identifier for identifying the file on the DFS is stored in the f_id 56. Each entry 51 of the directory management information 50 is created in a structure corresponding to the directory structure by three types of pointers, p_parent 52, p_subdir 53, and p_child 54. Therefore, it is possible to reach the entry 51 of the target file by sequentially tracing the pointer for the directory entry specified in the path. Since the file group identifier is stored in the entry 51, the DFS file group identifier can be obtained from the path name and file specified in the file system of the conventional protocol.

  6 is the root entry shown in FIG. 3, the entries shown in the middle part of FIG. 6 correspond to the directories dira, dirb, file1, etc. shown in FIG. The entry p_subdir 53 in the upper row indicates the entry on the right side of the middle row corresponding to the directory dira, and the p_child 54 in the entry on the right side of the middle row indicates the entry on the right side of the middle row corresponding to the directory dirb. Similarly, the p_subdir 53 in the middle right entry corresponding to the directory dira points to the lower entry corresponding to the directory dira1.

  Therefore, when the path name from the conventional client and the file name of the file are specified as / dira / dira2 / dira22 / file0001, for example, as described with reference to FIG. As a result, it is possible to search for an entry having the file name specified in f_name 55 that stores the name of the directory or file, thereby obtaining the file group identifier f_id 56.

  Registration of a file in the directory management information 50 as described above is performed in the following case. The first is a case where a file is created by a conventional protocol. In this case, since the file is created by specifying the path name and the file name, the conventional protocol processing unit 31 creates an entry in accordance with it and adds the entry at a position corresponding to the path name of the directory management information 50. Good. The second is a case where a file is created by the DFS protocol. In this case, since the directory management information 50 is not created as it is, it cannot be accessed from the conventional protocol. Therefore, when it is desired to access a file created by DFS from the conventional protocol, the DFS processing unit 26 needs to make a registration request to the gateway unit 25 in the directory. This registration request is made from the DFS processing unit 26 to the gateway unit 25 by specifying a path name, a file name, and a file group identifier of a file to be registered.

  The directory management information 50 described above can be shared by communicating between the gateway units existing in each DFS server 2 in the system. Thereby, it becomes possible to access from each access point as the same file system. Alternatively, each gateway unit 25 of each DFS server 2 can have separate directory management information 50, which makes it possible to make each access point appear as a different file system.

  FIG. 7 is a flowchart for explaining a processing operation when a DFS file is accessed and a file is referred to using a conventional protocol, which will be described next.

(1) When referring to a file in a directory using the conventional protocol, the conventional protocol client 4 or 5 specifies a file specifying the path and file name indicating the directory location of the file, and refers to the file. Access to do.

(2) When the conventional protocol processing unit 31 receives a reference request specifying a file as described above, the conventional protocol processing unit 31 makes an inquiry to the directory management unit 33 to obtain a file group identifier. The directory management unit 33 arrives at the entry of the designated file by following the pointers in order for the entries of the directory management information 50 held by the directory management unit 33 in the same way as in tracing the directory one layer at a time in the conventional file system. Then, the file group identifier of the file name designated from the entry is obtained and returned to the conventional protocol processing unit 31 (step 81).

(3) The conventional protocol processing unit 31 inquires of the DFS access unit 32 about the latest generation number of the file group identifier in order to obtain a GUID. The DFS access unit 32 uses the DFS protocol to obtain the latest generation number by a method such as inquiring another DFS server 2 that manages the file group identifier, and returns it to the conventional protocol processing unit 31 (step 82). .

(4) The conventional protocol processing unit 31 obtains a GUID from the file group identifier and the generation number obtained in steps 81 and 82 (step 83).

(5) The conventional protocol processing unit 31 issues a GUID read request to the DFS access unit 32 using the GUID obtained in step 83. Upon receiving this request, the DFS access unit 32 issues a request to the DFS using the DFS protocol to obtain data for the read request (step 84).

(6) The conventional protocol processing unit 31 returns the data read by the DFS access unit 32 in step 84 as a response to the client that made the reference request (step 85).

  FIG. 8 is a flowchart for explaining the processing operation when a DFS file is accessed and the file is updated using the conventional protocol. Next, this will be described.

(1) When updating a file in a directory using the conventional protocol, the conventional protocol client 4 or 5 designates a file by specifying a path indicating the directory location of the file and a file name in the same manner as when referring to the file. Identify and access to update the file.

(2) When the conventional protocol processing unit 31 specifies the file as described above and receives an update request, the conventional protocol processing unit 31 determines whether or not the received request is a second or subsequent request that is performed by dividing the request (this) (It will be described later in detail), that is, it is determined whether or not the data already being updated is updated (step 91).

(3) If it is determined in step 91 that the update is not performed on the data that is already being updated, the conventional protocol processing unit 31 makes an inquiry to the directory management unit 33 to obtain a file group identifier. Therefore, the conventional protocol processing unit 31 queries the directory management unit 33 for the file group identifier as in the case of the reference processing. In the case of update writing, since it is writing to an existing file, an entry exists in the directory management table. Similar to the case of reference, the file group identifier can be obtained by obtaining this entry. In the case of creating a new file, there is no entry for the newly created file. In this case, when a file creation request is made, an entry is created and registered in the directory management information 50, and a file creation request is issued to the DFS processing unit 26 to obtain a file group identifier from the DFS processing unit 26. There is a need to do. Thereafter, similarly to the time of updating, the newly created file is subjected to processing from step 95 to be described later, and data may be written (step 92).

(4) After obtaining the file group identifier, it is necessary to create a new generation in the file group indicated by the file identifier in order to write the updated contents of the file. For this purpose, the conventional protocol processing unit 31 requests the DFS access unit 32 to issue a request for creating a new generation in step 93 (step 93).

(5) The DFS access unit 32 registers a new generation in the DFS processing unit 26 and returns the obtained generation number to the conventional protocol processing unit 31 as a response. The conventional protocol processing unit 31 can obtain the GUID from the response generation number and the file group identifier (step 94).

(6) The conventional protocol is not always performed by a single processing request even in a series of updates to a file. For example, in NFS, the size can be changed by setting, but normally, an update request is performed as a file update process for each fixed size of 8 KB units. When updating exceeding 8 KB, multiple update requests are performed. This is done by dividing it into two. For example, when it is desired to update 24 KB, the update is divided into three 8 KB updates. In order to prevent a new generation number from being created for each update request made in this way, once the file update is started, the fact that the file is being updated is stored until the update is completed. It is necessary to keep. For this reason, the conventional protocol processing unit 31 registers the updated file in a file monitoring table described later (step 95).

(7) If it is determined in step 91 that the update is for data that is already being updated, the conventional protocol processing unit 31 obtains a GUID from a file monitoring table described later (step 96).

(8) The conventional protocol processing unit 31 obtains the GUID from the file monitoring table after registration in the file monitoring table in step 95, or after obtaining the GUID from the file monitoring table in the processing processing in step 96. The DFS access unit 32 is requested to write the update request data. The DFS access unit 32 makes a write request to the DFS processing unit 26 (step 97).

(9) After the writing is completed, the conventional protocol processing unit 31 receives the response from the DFS processing unit 26 via the DFS access unit 32, and returns an update request completion response to the conventional protocol client (step 98).

  FIG. 9 is a diagram for explaining the structure of the file monitoring table. Each entry in the table 70 corresponds to a file being updated. The contents of the entry include information 72 for identifying the file and a generation number 73 indicating the generation of the file being written. As information 72 for identifying a file, p_dentry is used as a pointer to the directory information entry in FIG.

  Whether or not the received request is the second or subsequent request made by dividing the request can be known by examining information registered in the file monitoring table 70. The conventional protocol processing unit 31 If it is the second and subsequent requests, a new generation is not created. Therefore, in the process described with reference to FIG. 8, when the conventional protocol processing unit 31 receives an update request, the conventional protocol processing unit 31 checks the file monitoring table 70 in the process of step 91 to determine whether the update request is for an already updated file. Check whether or not. If it is not being updated, as described above, the process proceeds to step 92, where a new generation is created and data is written. If it has already been updated, a GUID is obtained from the file monitoring table 70 in step 96, and a data write request is issued to the GUID in step 97.

  The gateway unit 25 can process the file update request as described above, but notifies the DFS processing unit 26 of the end of the update to this generation in order to complete the registration of the created new generation. There is a need to. For this purpose, the gateway unit 25 needs to monitor the end of a series of update requests sent from the conventional protocol client using the conventional protocol.

  The trigger indicating the end of the series of update requests differs depending on each protocol. For example, in the case of a protocol such as CIFS that has a state in which a file is being operated such that it is opened when an operation is performed on a file and is closed when the file is terminated, the close request for operation completion is the update request It hits the trigger indicating the end of. On the other hand, NFS does not have an operation for opening or closing a file and does not have a state indicating whether the file is being operated. In the case of such a protocol, it is necessary to determine the end of the operation with another trigger.

  A plurality of cases can be considered as triggers in this case. One is the time interval at which the update request arrives. Conventional protocol clients divide and issue a series of updates to the gateway unit 25, but usually issue the next update request as soon as one divided update request is completed. For this reason, the gateway unit 25 monitors the time interval at which the update request arrives, and can determine that a series of update requests have been completed when the next update request does not arrive for a certain time. Further, as another trigger, a commit request can be considered. For example, in the NFS version 3 and later, a command “commit” is prepared as a method of reflecting the contents of the updated file on the disk. The issue timing of commit is not particularly specified, but is usually issued when a certain meaningful update is completed. For this reason, the gateway unit 25 can consider that a series of update requests have been completed when this commit request arrives. However, since the commit is not always issued at the end of the update, the end of the update may not be recognized if only this commit is used as a trigger, so it is used in combination with the time monitoring described above. There is a need.

  The above-described method for monitoring the trigger and determining the end of the generation of the new generation may end up creating the generation by recognizing the trigger as the trigger before the end of the original series of updates. For example, a method that uses a fixed time as a trigger may determine that the update that is originally performed is ended because the arrival of the next update request is delayed due to the state of the network 1 or the like. However, even in such a case, there is no problem as long as the updated contents of the file are not lost just by adding extra generations. When it is determined that the generation has been interrupted and the generation of the generation is completed, and an update request is received, a new generation may be generated and the generation may be written.

  FIG. 10 is a flowchart for explaining the processing operation in the gateway unit 25 at the end of generation generation. This will be described next.

  In step 101, the gateway unit 25 waits for the trigger for updating completion as described above, and starts processing when the trigger occurs. When an update end trigger is generated, in step 102, the conventional protocol processing unit 31 refers to the file monitoring table 70 and obtains the GUID of the generation being created. In step 103, the DFS access unit 32 issues an update end request to the DFS processing unit 26 for this GUID. After the update end processing in the DFS processing unit 26 is completed, in step 104, the conventional protocol processing unit 31 deletes the entry from the file monitoring table 70, and releases the file being updated.

  As described above, the gateway unit 25 can access the DFS file from the clients 4 and 5 using the conventional protocol.

  Each processing according to the embodiment of the present invention described above can be configured as a processing program, and this processing program is stored in a recording medium such as HD, DAT, FD, MO, DVD-ROM, CD-ROM, and provided. can do.

  The embodiment described above has been described on the assumption that a write-once file system is used as a DFS, but the present invention can also be applied to a non-write-once DFS. In this case, there is no idea of file generation, and the GUID value does not change even if the file is updated. Therefore, the file GUID may be directly included in the f_id 56 of the directory management information 50 instead of the file group identifier. In the flow at the time of referring to the file in FIG. 7, the GUID can be obtained in step 81, and step 82 and step 83 are not necessary. Similarly, in the flow at the time of updating the file shown in FIG. 8, a GUID is obtained in step 92, and step 93 for generating a generation and step 94 for obtaining a GUID become unnecessary.

  Further, in the above-described embodiment of the present invention, the gateway unit 25 is described as being built in the DFS server 2, but the present invention may not include the gateway unit 25 in the DFS server 2. For example, as another mounting position, it may be possible to have a gateway server that performs processing of the gateway unit 25 on the network 1 or to be incorporated in the conventional protocol clients 4 and 5.

  FIG. 11 is a block diagram showing a configuration example of a distributed file system according to another embodiment of the present invention. In FIG. 11, reference numeral 110 denotes a gateway server, and other reference numerals are the same as those in FIG.

  The example illustrated in FIG. 11 is an example in which the gateway unit 25 described above is provided as the gateway server 110 provided on the network 1. In this case, the conventional protocol clients 4 and 5 access the gateway server 110. Then, the gateway server 110 accesses the DFS server 2 using the DFS protocol. The gateway server 110 performs processing equivalent to that of the gateway unit 25.

  The DFS access unit 32 of the gateway unit 25 described above performs processing in cooperation with the DFS processing unit 26. However, in the example shown in FIG. 11, the function of the gateway unit is implemented on a server different from the DFS server 2. For this reason, it is impossible to perform the linked processing described above. Instead, in the system of the example shown in FIG. 11, the DFS access unit 32 provided in the gateway server 110 becomes a DFS client and performs equivalent processing by making a request to the DFS server 2 using the DFS protocol. Is possible.

  Further, as a method of incorporating into the conventional protocol client, for example, it is conceivable to incorporate the function of the gateway unit 25 into the NFS protocol processing unit. In this case, the program using the upper NFS performs processing using the NFS protocol, and the function of the gateway unit 25 converts the NFS protocol into the DFS protocol. On the network 1, the DFS is used using the DFS protocol. The server 2 is accessed.

  According to the above-described embodiment of the present invention, the directory structure existing in the file system of the conventional protocol such as NFS or CIFS is emulated, and the path name and the file name indicating the position of the file on the directory structure are shown. By converting the access method based on the file name into access by GUID which is a file identifier in DFS, it is possible to access a file on DFS using a conventional protocol.

  Further, according to the embodiment of the present invention, when the DFS is a write-once file system, by converting the update process of the conventional protocol into the creation process of the new generation, at the time of reference, from the file group managed for generation It is possible to obtain the latest generation file and access the data of the file.

It is a block diagram which shows the structural example of the distributed file system containing the gateway apparatus by one Embodiment of this invention. It is a figure explaining an example of the method of calculating | requiring GUID from a file group identifier and a generation number. It is a figure explaining the directory structure which a conventional protocol client uses. It is a block diagram which shows the structure of a DFS server. It is a block diagram which shows the structure of a gateway part. It is a figure explaining the structure of the directory management information 50. FIG. It is a flowchart explaining the processing operation | movement when accessing the file of DFS using a conventional protocol and referring a file. It is a flowchart explaining the processing operation when a DFS file is accessed and a file is updated using a conventional protocol. It is a figure explaining the structure of a file monitoring table. It is a flowchart explaining the processing operation in the gateway part 25 at the time of completion | finish of generation creation. It is a block diagram which shows the structural example of the distributed file system by other embodiment of this invention.

Explanation of symbols

1 Network 2 DFS Server 3 DFS Client 4 NFS Client 5 CIFS Client 21 DFS Control Unit 22 Disk Drive 23 Main Memory 24 OS
25 Gateway unit 26 DFS processing unit 27 Disk drive processing unit 28 CPU
29 HDD
31 Conventional Protocol Processing Unit 32 DFS Access Unit 33 Directory Management Unit 110 Gateway Server

Claims (12)

A gateway device connected to a client computer and a file server,
A first means connected to the client computer and receiving a first type file access request based on a first type protocol from the client computer;
A second means connected to the file server and transmitting a second format file access request based on a second format protocol to the file server;
A processing unit connected to the first and second means;
A memory connected to the processing unit,
The file access request of the first format based on the first protocol includes a path name indicating a directory including a file to be accessed, and a file name that is unique within the directory and indicates the file. ,
The file access request of the second format based on the second protocol includes a file ID that is unique within the file server and indicates the file;
The memory stores information on the correspondence between the path name, the file name, and the file ID,
The first means includes the path name corresponding to the first file and the first set of file names, which instructs the client computer to write data to the first file. When receiving a first command according to a protocol of 1 format, the processing unit checks whether the first file already exists in the file server,
When the first file does not yet exist in the file server, the processing unit instructs the file server to generate the first file to which a first file ID is assigned. Sending a second command according to the protocol to the file server;
If the first file already exists in the file server, the processing unit is assigned a second file ID and generates a second file including the updated contents of the first file. Sending a third command to the file server, instructing the file server, according to the protocol of the second format;
The gateway device, wherein the first file ID and the second file ID are different.   2. The gateway apparatus according to claim 1, wherein the first means and the second means are the same.   3. The gateway apparatus according to claim 2, wherein the first type protocol is NFS or CIFS.   The gateway device according to claim 3, wherein the control unit stores a correspondence relationship between the first set, the first file ID, and the second file ID in the memory. The first command is a command sequence including a plurality of commands,
The control unit identifies the last command of the command sequence by checking whether a predetermined time has elapsed since the first means received the latest command of the command sequence. The gateway device according to claim 4.   After the second file is created on the file server, the first means includes the first set corresponding to the first file from the client computer, and reads the first file. When the fourth command according to the first type protocol is received, the control unit includes the second file ID and stores the first file stored in the second file. 3. The gateway device according to claim 2, wherein a fifth command in accordance with the second format protocol is transmitted to the file server, which instructs the file server to transmit update contents to the gateway device. A gateway device connected to a client computer and a file server,
The client computer and the file server are connected via a network, receive a first format file access request based on a first format protocol from the client computer, and receive a second format from the file server. Means for transmitting a file access request in a second format based on the protocol of:
A processing unit connected to the means;
A memory connected to the processing unit,
The file access request of the first format includes a path name indicating a directory including a file to be accessed, and a file name that is unique within the directory and indicates the file,
The file access request in the second format includes a file ID that is unique within the file server and indicates the file;
The memory stores information on the correspondence between the path name, the file name, and the file ID,
The means includes the first set of the path name and the file name corresponding to the first file, instructing the client computer to create the first file, in the first format. When receiving the first command based on the protocol, the processing unit instructs the file server to generate the first file to which the first file ID is assigned. 2 command is sent to the file server,
After the processing of the first command, the means instructs the client computer to update the contents of the first file, and the path name corresponding to the first file and the file name When receiving a third command that includes the first set and conforms to the protocol of the first format, the processing unit is assigned a second file ID and is designated by the third command. Sending a fourth command to the file server in accordance with the protocol of the second format, instructing the file server to generate a second file containing the updated contents of the file;
The gateway device, wherein the first file ID and the second file ID are different.   The means is connected to the client computer, connected to the file server, and first means for receiving the first type file access request based on the first type protocol from the client computer. 8. The gateway according to claim 7, further comprising second means for transmitting the file access request of the second format based on the protocol of the second format to the file server. apparatus.   9. The gateway device according to claim 8, wherein the first type protocol is NFS or CIFS.   The gateway device according to claim 9, wherein the control unit stores a correspondence relationship between the first set, the first file ID, and the second file ID in the memory. The first command is a command sequence including a plurality of commands,
The control unit identifies a final command of the command sequence by checking whether or not a predetermined time has elapsed since the means received the latest command of the command sequence. Item 11. The gateway device according to Item 10.   After the second file is created on the file server, the means instructs the client computer to read the first file including the first set corresponding to the first file. When the fifth command according to the protocol of the first format is received, the control unit includes the updated content of the first file stored in the second file including the second file ID. 8. The gateway apparatus according to claim 7, wherein a sixth command in accordance with the second type protocol for instructing the file server to transmit to the gateway apparatus is transmitted to the file server.

Images