JPH11219311A - File access method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent a load on a file server computer from increasing by allocating disk blocks to file blocks on the file server computer side and performing block input/output request processing based on block position information obtained on a client computer side. SOLUTION: When an OS 12 on a client computer 1 requires new block position information for the extension of a file or the like, at the time of input/ output processing, the OS 12 requests the new block position information from an OS 13 on a file server computer 2 through a block position information acquiring processor 27. Then, the OS 13 on the file server computer 2 sends back the block position information requested by the client side to the OS 12 on the client computer 1 when having the block position information. When not, on the other hand, the new block position information is added and sent back to the OS 12 through a disk block allocating processor 28.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

The present invention relates to a file access method, and more particularly to a file access method in a computer system including a computer including a processor and a secondary storage device and a communication network interconnecting the computers.

[0002]

2. Description of the Related Art In many ordinary computer systems, the reading of data requested by a user process from a secondary storage device or the writing of data to the secondary storage device is performed by O.
S converts the request into a form suitable for the device and executes the request. For example, in order to access file data stored in a block type device represented by a magnetic disk device (a device that manages data in blocks of a predetermined size), the OS performs a block input / output request process. Further, based on the request, device-specific input / output processing for creating an input / output command specific to each device is performed.

As such an OS, UNIX (X / Open Company) often used in a workstation is used.
(Registered trademark) is known. "UNIX 4.3 BSD
Design and Implementation ”Maruzen, 1991 (“ The Design
and Implementation of the4.3 BSD UNIX Operating S
ystem "Addison-Wesley Publishing Company, 1989) 173-182, 198-202, 211-2.
See page 17 (hereinafter referred to as Reference 1).

On the other hand, in a distributed memory type parallel computer system and computers interconnected by a local area network, a computer that performs file input / output requests (client computer) and a computer that manages files (file server computer) are different. There is.

For example, consider a case where a user program in a computer A (client computer) issues an input / output request for a file X managed by another computer L (file server computer). However, it is assumed that the file server computer L also manages the device storing the file X.

When the OS on the client computer A that attempts to process the input / output request finds that the file is managed by the file server computer L,
An I / O request to the OS of the file server computer L is issued by network communication. The file server computer L that has received the request creates and executes a block input / output request using the file management table of the OS. Further, based on the request, a device-specific input / output request is created and executed. This execution result is returned to the client computer A that is the input / output request source.

For example, "An OSF / 1 UNIX for Massive
ly Parallel Multicomputers "1993 Winter USENIX, 1
993 (hereinafter referred to as Reference 2), pages 449-468.

[0008]

However, as can be seen from the above, when the network communication performance is sufficiently high, the overall input / output performance of the computer system connected via the network is independent of the number of client computers.
It depends on the processing capacity of the file server computer.

Therefore, when the block input / output request processing and the device specific input / output request processing are executed only by the file server computer as in the prior art, the load on the file server computer increases as the number of client computers increases, and the computer system There was a problem that the overall input / output performance did not improve.

Further, even if the number of file server computers is increased so as to improve the input / output performance of the entire computer system, files managed by each file server computer may be shared by client computers. However, there has been a problem that data consistency control becomes complicated, a load on a specific file server computer increases, and input / output performance of the entire system deteriorates.

An object of the present invention is to provide a file access method for preventing an increase in load on a file server computer due to an input / output request from a client computer.

Another object of the present invention is to provide a file access method for preventing an increase in load on a file server computer due to file consistency control processing when an input / output request for the same file is issued from a plurality of client computers. It is to be.

[0013]

In order to solve the above-mentioned problems, according to the present invention, a file managed by a file server computer on a network in a computer system including a plurality of computers and a network interconnecting the plurality of computers. Assigning a disk block to a file block on the file server computer side, obtaining block position information on the client computer side, and And performing a block input / output request process.

[0014]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS A file access method according to the present invention will be described in more detail with reference to an embodiment shown in the drawings.

FIG. 1 shows an entire computer system to which an embodiment of a file access method according to the present invention is applied.

In FIG. 1, the computer system includes a client computer 1 as an input / output request source, a file server computer 2 as an input / output processing destination, and a communication network 3 interconnecting them. Further, a magnetic disk device 4 as a secondary storage device is connected to the file server computer 2. The client computer 1 and the file server computer 2 include an instruction unit for executing instructions, a main memory, a storage control device for controlling the main memory, and the like, but these circuits are not shown for simplicity. instead,
In the figure, one running user process 11 and OSs 12 and 13 are shown in blocks of the client computer 1 and the file server computer 2. Although a large number of user processes are actually running simultaneously on the client computer 1 and the file server computer 2, only one user process 11 is shown in the figure for simplification.

When the user process 11 on the client computer 1 issues an input / output request 21 for a certain file in the secondary storage device 4 connected to the file server computer 2, the request is issued in the following flow. Is processed.

First, the OS of the client computer 1
12 executes a block input / output request creation process 22 by using a client computer inode 16 described later. This request is transmitted to the file server computer 2 via the communication network 3, and the client computer and the file server computer execute communication processes 23 and 24, respectively, to perform the communication. As for the communication processes 23 and 24, the block input / output request created by the OS 12 of the client computer 1 is transmitted to the OS 13 of the file server computer 2.
, Any communication process may be performed, and a description thereof will be omitted.

OS 13 of file server computer 2
Then, the data transfer processing 25 and the device-specific input / output request processing 26 are executed in accordance with the received block input / output request. As will be described in detail later, the data transfer process 25 secures the block buffer 18 for data input / output, performs data transfer with the client computer and the device using this, and notifies the OS 12 of the client computer 1 of the result. Then, the input / output processing ends.

At the time of the input / output processing, the OS 12 of the client computer 1 may need new block position information due to file expansion or the like. At this time, the OS
12 requests new block position information from the OS 13 of the file server computer 2 by the block position information acquisition processing 27. If the OS 13 already has the block position information requested by the client, the OS 13 returns it to the OS 12. If not, the new block position information is added by the disk block allocation processing 28 and returned to the OS 12.

As described above, the block request creation processing 25 known per se is executed by the O
In S12, the device-specific input / output request processing 26 known per se is executed by the OS 13 of the file server computer 2.
By executing on the file server computer 2
Thus, a file access method for preventing an increase in the load on the file is realized.

OS 12 of the client computer 1
Uses a client computer inode 16 including a copy of the block position information of the inode 17 managed by the OS 13 on the file server computer side in place of the inode known per se, except for using a block input / output request in a known procedure. Execute the process 22 (for example, see Reference 1)
See).

Specifically, as shown in FIG. 9, when the user process 11 first issues an open system call in order to input / output a file, the file management table 1 for managing access to a file from a process possessed by the OS 12 is provided.
The OS 12 opens the file requested by this system call based on the file 12 and the file descriptor table 111 provided for each user process. Then, the client computer inode 113 for the file
Is generated as described later, an entry is added to the file table 112 known per se, an entry is added to the file descriptor table 111 corresponding to the user process 11, and this file descriptor table is added to the user process 11. 111
Returns the contents of the entry added to. This content is called a file descriptor and consists of a pointer to the entry added to the file table 112.

As in the known file management table, one entry in the file management table 112 is the reference number 121 from the process, the starting point of the next input / output and the byte offset 122 in the file expected, and is open. The access right (read, write) 123 to the process is held. The difference from known file management table entries is that
Instead of the known file management table including a pointer to the inode of the opened file, the known file management table includes a pointer 124 to the client computer inode 16 of the opened file.

The byte offset of the file management table entry determines the next read / write position in the file. For example, when reading and writing from the beginning of the file when the file is opened, the byte offset 122 in the file management table entry is set to 0. If the user process opens the file in the additional write mode, the byte offset 122 in the file management table entry is set to the size of the file. Subsequent input / output requests from the user process 11 are made using a read or write system call. At this time, these system calls include a file descriptor, a buffer address in the user process space, and a data size as arguments. That is, read or writ
The e system call does not specify the offset in the file to read or write. When reading and writing of file data are performed, the byte offset 122 in the file management table entry is updated by the size of the input / output processed data. The byte offset 122 in the file management table entry can be directly set by the user process by the lseek system call.

The advantage of having the byte offset of a file in one entry of the file management table 112 is that multiple user processes can share the byte offset for the same file, or have them at different byte offsets. Is what you can do. That is, the file descriptors of the plurality of entries can be determined so that the plurality of entries belonging to the plurality of file descriptor tables 111 for the plurality of user processes point to one entry of the file table 112. In this case, when performing file I / O from those user processes, these user processes can share the same byte offset in this shared entry. Also, the file descriptors of the plurality of entries in the file descriptor table 111 are changed so that the plurality of entries belonging to the plurality of file descriptor tables 111 for the plurality of user processes point to different entries in the file management table 112. Once determined, a pointer to the client computer inode in the different entry in the file table 112 may be determined so that these entries in the file management table 112 point to the client computer inode for one file. In this case, these user processes
You can have different byte offsets for the same file.

As shown in FIG. 9, the client computer i-node is generated by acquiring the block position information in the inode of the file managed by the OS on the file server computer which manages the file requested to be opened. . The block position information 127 indicates the data storage position on the disk for one file. The client computer inode 16 further includes an allocated block number 125 indicating the number of disk blocks allocated to the file, and a reference number in the client computer indicating the reference number of the file in each client computer. 1
Hold 26.

As shown in FIG. 10, the inode 17 manages files such as a file owner 132, a time stamp 133 holding the last update date and time, a file size 134, and the like, similarly to the known inode. Management information and block position information 137 for accessing a disk block storing data on the magnetic disk storage device 4.

The i-node 17 of the present embodiment is a publicly-known i-node.
Unlike the node, in order to manage the client computer inode 16 on the client computer side, a client computer reference count 138 and a pointer 139 to a client computer reference list are provided.
Also have. Client computer reference count 138
Represents the number of client computers holding client computer i-nodes derived from the corresponding i-node. The pointer 139 to the client computer reference list points to the client computer reference list holding the client computer number holding the client computer inode. The client computer reference list is used for, for example, invalidating the block position information of the client computer inode for the client computer that is referring to the file.

The block position information 137 of the inode includes a file block number (indicating a relative position from the head of the file) indicating the position of the block (file block) in the file, and the storage of the file block on the magnetic disk device. It is used for association with a disk block number indicating a position (a logical address of a magnetic disk device that can be specified by a processor; a block on this disk is called a disk block). Thereby, the disk space can be managed efficiently.

Next, the disk block input / output request processing 22 in the OS 12 of the client computer 1 will be described with reference to FIG. First, an input / output request from a user is converted into a file block number which is a relative position of a block in a file (step 31). Further, the client computer i-node 16 of the corresponding file is determined from the file name specified by the input / output request 11 from the user process 11, and the block position information 12 for the file block specified by the input / output request 11 is determined.
It is confirmed whether or not 7 exists in the client computer inode 16 (step 32). If not, block position information is obtained from the file server computer (step 33). The file block number is converted into a disk block number based on the obtained block position information 127 (step 34), and a disk block input / output request is created (step 35). Then, the request is issued to the file server computer (step 36).

Next, the data transfer processing 25 of the OS 13 and the device specific input / output request processing 26 in the file server computer 2 in response to the above request will be described with reference to FIG. First, when a disk block input / output request is received, a block buffer 18 for holding data of a disk block to be requested is secured (step 41).

Here, the block buffer 18 will be described. The block buffer 18 is secured so as to be uniquely determined for each disk block, and the input / output processing from a client computer is performed via the block buffer 18 so that another client computer can simultaneously input / output the same file. Ensure data consistency when done.

Next, when it is confirmed that the block buffer 18 has been secured, the block buffer 18 is locked in order to guarantee the consistency of data when the block buffer 18 is accessed at the same time (step 42). In the step, the device specific input / output request processing 26 is performed. Processing differs depending on whether the block input / output request is read or write (step 43).

In the case of reading, a device-specific input / output command is generated, and a data read request is issued to the disk (step 44). After that, it waits for the completion of reading data from the block buffer 18 (step 4).
5) The data is transferred from the block buffer 18 to the requesting client computer.

In the case of writing, the block buffer 18
It waits for the completion of the data transfer from the client computer to the client (step 47). During or after the completion, a device-specific input / output command is generated, a data write request is issued to the disk (step 48), and completion is waited for (step 49).

After completion of the processing in step 46 or step 49, the lock of the block buffer is released (step 50), and the completion of input / output is notified to the client computer (step 51).

In this manner, the load on the file server computer is reduced by executing the block input / output request processing and the device-specific input / output request processing conventionally performed by the file server computer on the client computer. Can be reduced.

Next, the file open processing will be described with reference to FIGS. FIG. 5 shows a file open process of the OS 12 of the client computer 1. First, when a file open request from the user is received (not shown), it is checked whether or not the client computer i-node of the file to be requested to open already exists in the client computer (step 7).
1). If the file already exists, the process proceeds to step 75, and if not, an open request is issued to the file server computer managing the file requested to be opened (step 72). As a result, block position information is received from the file server computer that is the file management destination (step 73). An entry of the client computer i-node holding the block position information 127 (FIG. 9) is created (step 74), an entry of a file management table known per se is assigned, and a pointer 124 to the client computer i-node is set in step 74. Are set to point to the client computer i-node created in step (step 75).

FIG. 6 shows the file server computer 2 side O
This is the file open process of S13. The OS on the file server computer that has received the open request in step 72 of FIG. 5 finds the inode of the file to be requested by a method known per se (step 81). Since this inode is referred to by the client computer, the reference number of the client computer described later with reference to FIG. 10 is incremented (step 82). Further, the client computer number is registered in a client computer reference list which will be described later with reference to FIG. 10 (step 83). When these processes are completed, the block position information in the inode is transmitted to the client computer which has issued the file open request, and the process ends (step 84).

FIG. 10 shows the structure of an inode used in this embodiment. FIG. 10 also shows the structure of the client computer reference list indicated by the pointer 139 to the client computer reference list. The inode used in the present embodiment is a client computer reference number 1
38 and a pointer 139 to the client computer reference list. Client computer reference number 13 which is one of the features of the present invention
8 stores how many client computers refer to the file represented by the inode managed by the file server computer. Also, the pointer to the client computer reference list points to the header of the client computer reference list as the name implies. The client computer reference list includes a list header 141 and a list 142 of client computer numbers having a double linked list structure. Based on the client computer reference number 138 and the client computer reference list, the file server computer-side OS 13 manages information as to which client computer refers to the file represented by the inode and the number of the client computers. . This is because the reference from the client computer is 0
In this case, the inode expanded on the memory is used to write back to the disk by a method known per se.

Next, as one of the features of the present invention, FIG. 4 shows a process when a file is increased by a write request from a user process and a disk block is newly allocated to a file block. It will be described using FIG.
The difference between the present invention and the prior art is that in the prior art shown in References 1 and 2, disk block allocation processing and block input / output request processing are performed by the same computer, whereas in the present invention, disk block allocation processing and block The point is that the input / output request processing is executed by a different computer.

Although not shown, when a write request is received from a user process running on the client computer, the user write request data is added to the block position information of the client computer i-node 16 managed by the OS of the client computer. It is assumed that disk blocks to be stored are not allocated. At this time, the client computer OS
A file block position acquisition request is issued to the OS on the file server computer side.

FIG. 4 shows the processing when the file server computer receives this request. First, the file server computer receives a block position information acquisition request (step 61). Since there is a possibility that a disk block has already been allocated to the file block in response to a request from another client computer OS, it is checked whether floc position information already exists (step 62). If so, the block position information is returned to the requesting client computer (step 67). If not, the lock of the inode is acquired (step 63), a disk block is allocated to the file block by a method known per se (step 64), and it is registered in the block position information (step 65). After registration, release the lock of the inode (step 6)
6) Return block position information to the requesting client computer (step 67).

As described above, while the block position information is shared by a plurality of client computers, the update of the block position information does not occur on the client computer side, so that the consistency can be maintained. On the other hand, a request for releasing a disk block (for example, reducing the file size) may be issued from the client computer. In this case, the block release of a certain file means that the reference from the client computer of the file is 0.
I will do it when it becomes. Of course, the load increases, but it is also possible to notify each client each time a disk block release request is made to maintain consistency.

At the end of the description of this embodiment, the file closing process will be described with reference to FIGS. FIG. 7 is a flowchart of the file closing process of the OS on the client computer side. When a file close request is received from the user process (not shown), the reference number 126 in the client computer in the client computer inode of FIG. 10 is decremented (step 9).
1). The number of references in the client computer is checked (step 92). If the number is not 0, another process in the client computer refers to the inode of the client computer. If the result of the check is 0, the other process in the client computer does not refer to the client computer i-node, the client computer i-node is released, and a close request is sent to the management destination of the file requested to be closed. Issue (step 93).

FIG. 8 shows the file server computer side O
It is a flowchart of a file close process of S. The OS on the file server computer side executes step 9 in FIG.
When the close request issued from the client computer OS is received in step 3 (step 101), the client computer reference number 138 of the inode 17 is decremented and the entry is removed from the client computer reference list (step 102). At this time, the client computer reference number 138 is checked (step 10).
3) If it is not 0, the inode managed by the file server computer OS is left as it is because it is still referred from another client computer, and the process ends. If it is 0, the i-node is released because it is not referenced by other client computers (step 104). However, at this time, if the reference number 136 of FIG. 10 is not 0, the i-node is not released because the i-node is referred to in the file server computer.

As described above, in the present invention, the block input / output request processing is executed by the client computer.

[0049]

According to the present invention, the block position information of the inode managed by the OS on the file server computer is sent to the OS on the client computer, and the OS on the client computer uses the information to send a block input / output request. By doing so, it becomes possible to reduce the load on the file server computer in the file input / output processing.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an example of the overall configuration of an embodiment of the present invention.

FIG. 2 is a flowchart of a block input / output request process according to the embodiment;

FIG. 3 is a flowchart of a data transfer process according to the embodiment;

FIG. 4 is a flowchart of a disk block allocation process according to the embodiment;

FIG. 5 is a flowchart of a file open process on the client computer side.

FIG. 6 is a flowchart of a file open process on the file server computer side.

FIG. 7 is a flowchart of a file closing process on the client computer side.

FIG. 8 is a flowchart of a file closing process on the file server computer side.

FIG. 9 is an explanatory diagram of a data structure for file management on the client computer side.

FIG. 10 is an explanatory diagram of a file server computer-side file management data structure.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Client computer, 2 ... File server computer, 3 ... Communication network, 4 ... Magnetic disk, 11 ... User process, 12 ... Client computer side OS, 13 ... File server computer side O
S, 15: user buffer, 16: client computer inode, 17: inode, 18: block buffer, 21: file input / output request, 22: block input / output request processing, 25: data transfer processing, 26: device specific Input / output request processing, 27: block position information acquisition processing, 28: disk block allocation processing, 112: file management table, 124: pointer to client computer i-node, 126: reference number in client computer, 127: block position information.

 ────────────────────────────────────────────────── ─── Continuing on the front page (72) Inventor Yama ▲ saki ▼ Yasuo 1-280 Higashi Koigakubo, Kokubunji-shi, Tokyo Inside the Hitachi, Ltd. Central Research Laboratory

Claims (4)

[Claims] 1. A computer comprising a plurality of computers and a network interconnecting them, at least one of said computers holding at least one file holding a plurality of files accessible by a plurality of user processes running on a processor. An operating system (hereinafter abbreviated as OS) of a computer that has a secondary storage device and manages the secondary storage device manages logical arrangement information of the file on the secondary storage device,
S is a computer system that issues an input / output request for the file issued by any of the plurality of user processes to an OS of a computer that manages the secondary storage device. The OS of the computer that issued the request has a copy of the logical arrangement information from the OS of the computer that manages the secondary storage device, and uses the logical arrangement information to
A file for making an input / output request to an OS of a computer that manages the secondary storage device, wherein the OS of the computer that manages the secondary storage device makes an input / output request to the secondary storage device. how to access. 2. The file access method according to claim 1, wherein the duplication of the logical arrangement information is performed in the file reference start processing. 3. The file access method according to claim 1, wherein the updating of the logical arrangement information is performed by an OS of a computer that manages the secondary storage device. 4. The OS of a computer that manages the secondary storage device manages the number of references to the file, and when updating the logical placement information, deleting part or all of the placement information is performed at least by the secondary 4. The file access method according to claim 3, wherein the method is performed when the number of references from a computer other than the computer that manages the next storage device becomes zero.