JPH07253894A - Shared storage device - Google Patents

Abstract

PURPOSE:To preserve the consistency of data by storing a history of access requests which are generated asynchronously in the plural for one shared file and the history of data on the contents of the change made in the file according to the access requests and rewriting the file based on the two histories. CONSTITUTION:An access monitor part 12 stores the history of access request in an access state storage part 14 for access requests 105 to be generated for one shared file. A history management part 13 stores and manages the history on the edition contents of the shared file. Based on the two histories, the file, that is, the data in a storage device 20 presented by a file management part 10 are rewritten. Thus, if plural access requests 105 are generated for one shared file, writing and reading and updating data can be performed without damaging the consistency of data.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION The present invention relates to a shared storage device,
Especially shared computer file systems and databases
The present invention relates to a shared storage device that manages a plurality of asynchronous accesses to a shared file / data and update of the file / data in a system.

[0002]

2. Description of the Related Art Conventionally, a file system used for a computer does not support asynchronous editing by a plurality of users. Here, "asynchronous" means that a plurality of people access the shared data (the same data) at random and update the data at arbitrary times, and the "asynchronous editing" means the above. Even in such situations, it means editing that does not impair data consistency.

What does not support asynchronous editing is
This is because file access, which is generally performed asynchronously, causes data destruction and data structure inconsistency.
Normally, for asynchronous access from multiple users, exclusive control is performed to maintain data consistency.

FIG. 16 shows the basic structure of a conventional general shared storage device. This shared storage device is used by a plurality of access requesters 221 to access common data stored in the storage device 220. Since it is inconvenient to directly read from or write to the storage device 220 to access common data, the data is managed as some meaningful chunks and is viewed as a file 210. The method of managing data from the file 210 to the storage device 220 is well known and will not be described.

The access requester 221 issues a file access request 206 to the file access means 211. In a normal operating system, this request is "open" that requests opening of the file, "close" that requests closing of the file, "read" that requests reading of the file, and "write" that requests writing to the file. It is usually realized in the form of a system call such as.

[0006] Here, the access requester 221 is not limited to the operator (the terminal operated by) who accesses,
This includes all access subjects such as the process that issues the system call and the file descriptors that are created in the process. The storage device 220 is a temporary storage device such as a hard disk, a memory, or an IC card,
Includes all removable items.

[0007] In such a conventional shared storage device, the operation when assuming asynchronous access from a plurality of access requesters 221 is as follows. First, the first access requester 221 (hereinafter referred to as access requester A) opens the file to add data to the end of the file, and before the second access requester 221 closes this file. Similarly, it is assumed that the file 221 (hereinafter referred to as the access requester B) has opened the file to add data to the end of the same file. At this time, the images of the files held by the requesters A and B are as shown in FIG. However, this is a virtual image, and the actual data is not held by the requesters A and B, but is managed by the file 210. Since the file has been opened to add data, the access pointers 232 indicating the destinations for storing the next data all point to the end of the data.

After that, as shown in FIG. 17B, the requester A issues a "write" file access request 206 to write the additional data 233. The file access means 211 receives this and actually
Write to the corresponding position of 0. Further, the requester A is “clo
Then, the file access means 211 knows that the file access by the requester A is completed. On the other hand, the requester B has not written anything but the file 210 of the file 210 The data has already been modified by requester A.

Next, when the requester B writes the additional data 234 in the same procedure, as shown in FIG.
10 data are changed. No matter what change is made by the requester A, all the file access requests 206 issued by the requester B are processed.

Therefore, at this time, the file access request issued by the requester A is destroyed by the file access request issued by the requester B and is not correctly reflected in the file. In other words, neither the requester A nor the requester B has the expected contents of the file change left correctly.

As described above, when the conventional shared storage device accepts the asynchronous access to the same file, there is a problem that the data consistency is broken. Therefore,
In order to maintain data consistency, in the conventional shared storage device, a lock is provided when a file is accessed, and a mechanism that prevents other requesters from accessing the file after releasing the lock is used to perform exclusive control. Is normal. However, in order to access the file, the other requester must wait until the access of the requester who is locked is completed, and the requester is the operator (terminal operated by the operator). Is extremely inefficient in working, imposes an extra burden on the operator, and if the requester is a process that makes a system call, the processing speed will be impaired. there were.

[0012]

As described above, in the conventional shared storage device, when access is made from a plurality of access requesters, the first access requester when the lock mechanism is provided. Other than that, there is a drawback that processing efficiency is deteriorated because it is necessary to wait until the lock is released, and there is a problem that data consistency is broken when multiple asynchronous accesses are accepted.

The present invention has been made in consideration of the above problems, and it is possible to maintain the consistency of contents even if a plurality of asynchronous access requests for one shared file are accepted. The purpose is to provide.

[0014]

A shared storage device according to the present invention (claim 1) is a file storage means for storing a file which is a set of data, and the same file stored in this file storage means. Request management means for asynchronously receiving a plurality of access requests to the file, first storage means for storing the history of the access requests received by the request management means, and a change made to the file according to the history of the access requests. Second storage means for storing a history of data indicating the contents, and stored in the file storage means based on the history stored in the first storage means and the history stored in the second storage means. And a file rewriting means for rewriting the file.

[0015] Preferably, the request management means has a plurality of processing units provided corresponding to the contents of the access request for performing a predetermined process by using a program executed on an operating system. , System calls provided by the operating system
Address information for activating each of the plurality of processing units is set in the table, and the access request is given in a form of activating the desired processing unit using the system call table. And

[0016]

In the shared storage device according to the present invention (claim 1),
First, even when a plurality of access requests for one shared file stored in the file storage means are asynchronously generated, the request management means accepts the access requests.

Then, the request management means stores the history of the received access request in the first storage means. This means that each access requester who has issued the access request changes the contents of the file in the first storage means, instead of directly changing the contents of the file in the file storage means.

The history of data indicating the contents of the changes made to the file by the access requester is stored in the second storage means in accordance with the history of the access request. That is,
By referring to the history of the data indicating the content of this change, the result of the asynchronous change of the content of the file can be reproduced at the time of an arbitrary access request.

The file rewriting means rewrites the file stored in the file storing means on the basis of the history of the access request and the history of the data showing the contents of the change.
Therefore, even if a plurality of access requests are asynchronously issued to one shared file, all can be accepted without performing exclusive control, and data read / write / data update can be performed without impairing data consistency. .

Further, each access requester can perform file access without considering that this shared storage device is shared with other access requesters. This means that an existing application program or the like can be used as an access requester with little or no modification.

When the operating system is used to issue the access request as in claim 2, the file rewriting means set in the call table provided by the operating system is directly executed. "Open", "close", "rea"
The value of the address pointer to the system call such as "d" or "write" is sent to the request management means as "ope".
n ”,“ close ”,“ read ”,“ write ”
Value of an address pointer for passing each access request, such as "op" provided in the request management means.
en ”,“ close ”,“ read ”,“ writ ”
Use as an access requester without changing the existing application software or other program itself, simply by rewriting the value of the address pointer for activating the processing unit corresponding to each e "access request. You can

[0022]

Embodiments of the present invention will be described below with reference to the drawings. (First Embodiment) First, a shared storage device according to a first embodiment of the present invention will be described. FIG. 1 shows the main configuration of the shared storage device of this embodiment. This shared storage device is a device for providing an environment in which a plurality of access requesters 21 can asynchronously access common data stored in the storage device 20, and includes an access monitoring unit 12, an access state storage unit 14, and a history management. Section 13, file access section 11,
A file management unit 10 and a storage device 20 are provided.

A plurality of access requesters 21 are connected to the access monitoring unit 12. Here, the access requester is not limited to the operator (the terminal operated by the operator) who accesses it, but also the process that issues a system call, the file descriptors that are created in the process, and all other access requests. Including the subject.

In reality, the data stored in the storage device 20 is managed by the file management unit 10 as a file which is a meaningful and solid data, and the access requester 21 is managed by the file management unit 10. By editing the provided file, the data stored in the storage device 20 is indirectly edited. A publicly known file management unit 10 provided to virtually access the storage device 20 is used, and a data management method from the file management unit 10 to the storage device 20 will be described. Is omitted. It should be noted that the storage device 20 may be of any type such as a hard disk, a memory, an IC card or the like, such as a temporary one or a removable one.

The access requester 21 uses the access monitoring unit 1
2, the shared file access request 105 is issued.
Here, the shared file access request refers to an access request for asynchronously editing a shared file, in contrast to the conventional exclusively permitted file access request. On the other hand, in this embodiment, a request issued by the access monitoring unit 12 to the file access unit 11 to read / write a file provided by the file management unit 10 is called a file access request.

The shared file access request includes
File name or file descriptor to be accessed, "open" request to open this file, "read" request to read the contents of the file, "write" request to add / delete data to the file, file Any of the "close" requests to close the
And data to be added / deleted in the case of the “write” request.

The shared file access request is, for example, "open", "close", "r" in a generally provided general operating system.
It may be realized in the form of a system call such as "ead" or "write".

The access monitoring unit 12 that has received the shared file access request 105 stores the record that has received the shared file access request 105 in the access state storage unit 14. At the same time, the access monitoring unit 12 sends a shared file access request of “open”, as will be described later.
“Close” shared file access request, “re
shared file access request for "ad", "write"
Performs processing according to the shared file access request of. Further, the contents of each process are as follows.
The file access request 101 is issued to the file access unit 11 in some cases, and the file access request 101 is not issued in other cases.

The file access unit 11 processes the received file access request and changes the actual data to the file management unit 10. File management unit 1
The data written to 0 is actually actually written to the storage device 20 through a device driver (not shown) that is an access mechanism to the storage device.

The present embodiment will be described below assuming that the file access unit 11 accepts only the file access request from the access monitoring unit 12. However, the access requester 21 may directly provide the file access request to the file access unit 11 as in the conventional case.

The history management unit 13 manages the history of the edit contents of the shared file in the asynchronous editing from the first access requester 21 to the last access requester 21.

Next, a specific example of performing asynchronous editing in the shared storage device having the above-mentioned configuration will be described in detail according to the execution procedure of processing. In the initial state, it is assumed that no access is made to the file management unit 10. At this time, the access state storage unit 14 is in a state of not having any valid data.

First, the first access requester 21
A read-only “op” is issued to the access monitoring unit 12 in order to read the file (hereinafter, referred to as requester A).
The shared file access request 105 indicating "en" is issued. At this time, the access monitoring unit 12 creates the access history list 31 and stores it in the access state storage unit 14. The contents of the access history list 31 in this state are stored. It is shown in FIG.

The access history list 31 is a list in which an access request to a corresponding file existing at the present time in order to access the corresponding file of the file management unit 10 is stored. Specifically, the access requester 21
Is a list of the same number as the shared file access requests 105 issued to the access monitoring unit 12 as file open requests (requests to start read or write processing).

The data registered in the access history list 31 is only the information necessary for asynchronous editing. That is, it is not necessary to permanently record all access requests, and it is possible to delete all access requests when they are no longer needed. Note that the determination at the time when it is no longer needed will be described later.

At this point, the access requester 21 is only the requester A, so the access history list 31 has only the access history 120. The access history list 31 includes an ID code 110, a mode 111,
Open time 112, Close time 113, Current 1
There are seven fields, 14, state 115 and buffer 116.

The ID code 110 is the access requester 21
From the access monitoring unit 12
It is an identifier that is uniquely assigned to each n ”shared file access request. After the“ open ”request, the shared file access request from the access requester 21 is
It is managed using the ID code 110.

This ID code is issued to the access requester 21 each time the access monitoring unit 12 accepts the shared file access request of "open", and the access requester 21 thereafter carries this ID code. Alternatively, the shared file access request may be issued. Also, I
A D code issuing means may be separately provided. Alternatively,
When the access requester 21 issues an "open" shared file access request using an environment such as an operating system, does the file descriptor obtained at the time of this shared file access request be used as an ID code thereafter? Alternatively, information uniquely associated with this file descriptor may be used as the ID code. Further, one field may be deleted by substituting the open time and the version number described later.

Mode 111 is an operation for this file.
The "n" request mode is shown, and "r" written here means read-only. If "w" is written here, it means that the mode is a write-only mode or a read / write mode.

The open time 112 shows the time when the open request for this file is issued. In this example, it means that it was opened at time t1. Also, the close time 113 is the close to this file.
e indicates the time when the request is issued. In this example, since the closing time 113 is not written, it can be seen that it is currently open.

Here, the above-mentioned time is for indicating the context of the time when each event occurs, and may be, for example, the internal time possessed by the computer, or the version number is added to the file management. May be used as the time. Moreover, since this time is used only by the access monitoring unit 12, it is not always necessary to refer to this time directly from other parts (for example, the access requester 21).

The current 114 is a value (seek pointer) indicating the currently accessed position in the corresponding file of the file management unit 10 with respect to the currently accessed access request. This seek pointer indicates the read position (relative position in the file) for the next "read" shared file access request. In the case of read-only "open", the default value is the initial value. Is 0.

State 115 indicates where the actual access data is currently stored for this access requester. The state is "remote
e ”,“ local ”,“ copying ”,“ cop ”
There are five modes, ied "and" modified ".

"Remote" means that the content of the file exists only in the original file management unit 10. “Local” means that the content of the file is obtained by referring to the data of the history management unit 13.

"Copying" indicates that the contents of the file are currently being copied to the buffer.
“Ied” indicates that the copying to the buffer is completed, and “modified” means that the copied data has been changed even once.

In FIG. 2, the requester A state 115 is "remote", and the contents of the file exist only in the file management unit 10. That is, to actually read the file, the file access request must be issued to the file access unit 11.

The buffer 116 is a file content held for each access request. This may be the data itself, but in the present embodiment, it is described as a pointer to the data body. Currently, the requester A does not have a buffer, so the content of this data is undefined. The buffer has data only when it is "opened" in the write mode.

Next, the second access requester 21 (hereinafter,
In order to write (overwrite) the file by the requester B, it is assumed that the shared file access request 105 for instructing “open” for writing is issued to the access monitoring unit 12 at time t2.

As described above, the writable "ope"
When “n” is instructed, unlike the case of the read-only “open” by the requester A, the access monitoring unit 12 activates the file management unit 10 using the file access unit 11, and once Read the entire file,
The data is written in the access state storage unit 14 and the history management unit 13.

Specifically, a file access request is issued to the file access unit 11, a read-only "open" is performed, and then "read" is performed, and the entire file is read and "closed". Then, the read contents are written in the buffer 201 and the history management unit 13 of the access state storage unit 14. Here, the requester B
The shared file access request is a write mode, but the file access request given to the file access unit 11 uses a read-only mode.

First, the state 115 is set to "copyin".
g ”is set and copying is started. At this point, the request for shared file access from the requester B to the access monitoring unit 12 to“ open ”is properly terminated.
In the case of a call, the status indicating that the call is normally completed is returned to the requester B. By doing so, it is possible to prevent the execution of the program processing of the requester B from being interrupted during the copying. When the copying is completed, the state 115 is set to "copied".

At this time, the write operation issued by the requester B
When the n request is the write mode regardless of the original data of the file management unit 10 (that is, the original data is erased), the copying of the data to the buffer 201 can be omitted.

Access state storage unit 1 after completion of this processing
4 and the data of the history management unit 13 are shown in FIG.
It becomes like (a) and FIG.3 (b). Access history 1
Since the state 115 of 21 is “copied”, the data read / written by the requester B is temporarily stored in the buffer 2
01 means to do.

Here, the state 1 of the access history 121
While 15 is "copying", the write request from the requester B is temporarily suspended. Therefore, this pending time cannot be ignored when handling a very large file. Therefore, it is effective to divide the buffer into several parts and add state information to each, because the pending time can be shortened. It should be noted that this method is similar to the conventional general method for shortening the lock time of a shared file, and therefore the description thereof will be omitted in this embodiment.

The state 115 of the access history 120, which is open information from the requester A, is "remote."
e ”changes to“ local. ”That is, when there is a read request from the requester A, the access monitoring unit 12 does not obtain the data by the file access request to the file access unit 11, but the history management unit 13 It means that it is obtained from the data of 1. By doing so, extra file access can be omitted and the speed can be increased.

The history management unit 13 stores the copied data
Block 134, creation time 131, deletion time 13
2. The size 133 of the data block 134 is recorded. The creation time is the time when the data in this block becomes valid, and in this case, it is t1 that was first opened by the requester A. The deletion time 132 is the time when the data in the block becomes invalid, and in this case, it is undefined.

The need for the deletion time 132 means that even if the data in this block is deleted, the above history is kept until the asynchronous editing is completed. Next, the third access requester 21 (hereinafter referred to as requester C), like requester A, requests the read-only “o” to the access monitoring unit 12 to read the file.
shared file access request 105 instructing "pen"
At time t3, and the next access requester 21 (hereinafter referred to as requester D) writes "ope" in the same manner as requester B.
It is assumed that the shared file access request 105 instructing "n" is issued at time t4.

At this time, the contents of the access state storage unit 14 are as shown in FIG. At this time, the access monitoring unit 1 receives a shared file access request from the requester D.
When 2 creates the buffer 202, the operation is different from that of the requester B. That is, in the case of the requester B, it was necessary to issue an access request for reading the file to the file access unit 11, but in the case of the requester D, the same data exists in the history management unit 13. So you can just copy it. As a copying method, one of the data blocks 134 of the history management unit 13 is
At the erasing time 132, all the unerased times that have not been recorded may be sequentially copied.

Since the operation in response to the access request from the requester D is the same as that of the requester B, the description thereof will be omitted. Now, the four requesters are now independent
I am doing ead / write. That is, requester A
The requester C and the requester C perform read / write on the corresponding file provided by the file management unit 10 in the same manner as in the conventional method, respectively, for the requester B and the requester D. . The data in the access state storage unit 14 being edited at this point is
It is assumed that it is as shown in FIG. That is, the requester B has changed (overwritten) the middle of the file,
Data is added from the requester D to the end of the file. The current 114 and state 115 of the access histories 121 and 123 are rewritten.

Next, it is assumed that the requester B issues a shared file access request 105 to "close" a file to the access monitoring unit 12 at time t5. At this time, the state 115 of the access history 121 is "cop.
If it is “ied”, nothing is written, and therefore the following processing is not performed. On the other hand, if the state 115 is changed to “modified”, the following processing is performed. Be seen.

First, the access monitoring unit 12 extracts the file contents at the time of the requester B's opening, based on the data of the history management unit 13. To this end, t2 is retrieved from the open time 112 of the access history 121. Next, in the data block 134 of the history management unit 13, the creation time 13
Those in which 1 is the same as or smaller than t2 (before it) and the erase time 132 is undefined or larger than t2 (after that) are sequentially fetched.

The extracted contents at the time of opening are compared with the current contents of the buffer 201 to detect a difference in contents (d
if processing). To detect the difference in content, for example, a known diff algorithm may be used. Also, d
The unit of the if process is arbitrary. For example, in the case of a document such as an electronic bulletin board or a collaborative work, it may be performed in character units.
It may be performed on a line-by-line basis or on a data record basis if it is a data base. Whatever method is used, the basic algorithm is the same.

As a result of the diff process, deletion, insertion, and replacement can be obtained. The replacement is treated as a combination of deletion and insertion, and divided into a deleted part and an inserted part. FIG. 6 graphically shows this result. This is numerically represented as (delete, # 30, # 20) (insert, # 30, # 20). The size # 20 is deleted from the position # 30 from the beginning at the time of opening, and the size # 20 is deleted from the position # 30 from the beginning at the time of opening.
This means that 20 data items have been inserted. The result is reflected in the data of the history management unit 13.

In the processing for reflecting the above result, a lock is applied and exclusive control is performed so as not to be performed at the same time as other close processing. However, the waiting time due to this exclusive control is considered to be extremely short.

In the processing for reflecting the above result, first, the position where data is deleted / inserted is detected. To do this, the data in the history management unit 13 is scanned from the beginning, and counting is performed up to the designated position. When counting data,
Only the blocks existing at the time of opening (t2) are counted, and the other blocks are not counted. Whether or not the file exists at the time of opening is determined using the creation time 131 and the erasing time 132 as in the case of reading.

When the designated position is detected, if the corresponding position is in the middle of the data block 134, it is divided there, so that the information before the change is not lost.
Merge the results of the if process. As a result, the data of the history management unit 13 becomes as shown in FIG. When different access requesters 21 insert at the same location, both insert data remain, and when the same location is deleted, they are simply deleted. The details of these procedures will be described later.

Using the data structure shown in FIG. 7,
By the method described above, not only the file content at time t5 but also the file content at any time can be obtained.

At this point, the file contents at the time t5 may be saved in the corresponding file of the original file management unit 10 to improve the reliability, but in this embodiment, the saving is not performed at this time, In order to improve the efficiency of the processing, the data is saved when all access requesters 21 have closed, as will be described later.

On the other hand, in the contents of the access history 121, the closing time t5 is written, and the current 114, the state 115 and the buffer 116 are undefined. Further, the buffer 201 becomes unnecessary and is erased. Note that this data is not referenced in the processing after this point, so
Erasing may be done together at the end.

In the close operation described above,
If there is unnecessary data among the data held by the history management unit 13, it can be deleted. The unnecessary data means that the erase time 132 is smaller than or equal to the smallest open time (earliest time) of the access histories listed in the access history list 31 other than those already closed. The data block 134 (excluding those whose erase time 132 is undefined) and its associated creation time 131, erase time 132, and size 133. In other words, the history of data erased before the open access is unnecessary. However, in this example, there is no unnecessary data (which should be erased).

On the other hand, during the processing as described above, the requester A performs "read" of the data, and the access history 120
The current of has advanced to # 70. It is assumed that the requester C also "reads" the data and the current 114 of the access history 122 has advanced to # 30. In this way, the processing of each access requester 21 can be executed in parallel with other processing.

By this procedure, the contents of the access state storage unit 14 after closing are as shown in FIG. Next, it is assumed that the requester C issues a “close” shared file access request at time t6 and closes it. The processing required here is that the closing time is written in the access history 122 of the access history list 31, and the current 1
14. The state 115 field is simply undefined.

Further, as in the case of the requester B, of the data held by the history management unit 13, if there is unnecessary data, it is deleted. However, in this case, nothing is unnecessary. Next, it is assumed that the requester D issues a "close" shared file access request at time t7 and closes it. In this case, as in the case of the requester B, first, the contents of the file at the open time (t4) of the requester D are read from the history management unit 13 in the same procedure, and the buffer 20 is read.
Detect the difference from the data in 2. As a result, (insert, # 100, # 20) is obtained. That is, it means that the data of size # 20 is inserted at the position # 100 from the beginning (the position corresponding to the end of the file). As in the case of the requester B, this change is reflected in the data of the history management unit 13, the closing time 113 of the access history 123 of the access history list 31 is written, the current 114, the state 115, and the buffer 116 are invalidated, and the buffer 202 Erase the data in.

The contents of the access state storage unit 14 and the history management unit 13 after performing these operations are shown in FIGS. 9 (a) and 9 (b), respectively. Finally, it is assumed that the requester A issues a "close" shared file access request and closes it. At this point, no requester is open and access history list 3
All access history described in 1 is deleted.

Then, a file access request for "opening" the file in the write mode is issued to the file access unit 11, all the contents of the latest (current) file are read from the history management unit 13, and the data of that data is read. The write request and the close request are issued to the file access unit 11, and the update of the data in the file management unit 10 is completed. The data of the history management unit 13 is also unnecessary and is deleted.

By the above, all the processes of asynchronous editing by the access requesters A to D taken as an example are completed. Here, the file "op" in write mode
A detailed description will be given of the procedure for reflecting the changed portion (diff) in the history management unit 13 when the file that has undergone "en" is closed.

This procedure is specifically described with reference to flowcharts in FIGS. 10 and 11 and FIGS. 10 and 11 show the procedure of the insertion process. "from" is the insertion position seen in the data at the time of "opening", and "size" is the size of the data to be inserted. "Cp" is a bias from the beginning of the data of the history management unit 13 that is currently being scanned. "T0" is the time when the requester 21 who performs this processing opens. "T"
Is the (current) time when the close process was performed. "S
“izeof” means the size of the area in which the variable is stored.

12 and 13 show the procedure of the erasing process. The meanings of the variables are the same as those in FIGS. However, "from" is the deletion start position seen in the data at the time of opening.

By the above procedure, requesters A, B,
Four separate accesses from C and D can be executed asynchronously, and reading and writing of those data can be executed without contradiction and reflected in the contents of the file.

As described above, in the shared storage device according to the present embodiment, the history of a plurality of access requests asynchronously generated for one shared file and the change made to the corresponding file by the access request. And a history of data indicating the contents of the above are stored, and a file provided by the file management unit, that is, (data in the storage device 20) is rewritten based on these two histories. Therefore, even if a plurality of access requests are asynchronously issued to one shared file, all can be accepted without performing exclusive control, and data read / write / data update can be performed without impairing data consistency. .

Further, each access requester can perform file access without considering that this shared storage device is shared with other access requesters. This means that an existing application program or the like can be used as an access requester with little or no modification.

(Second Embodiment) Next, a second embodiment of the present invention will be described. As an application of the first embodiment, this embodiment makes it possible to utilize the shared storage device of the same embodiment from an existing application program. Further, in the present embodiment, at least the access monitoring unit 12 has a unit that performs a predetermined process using a program executed on the operating system, and each shared access request is provided by the operating system. It is supposed to be done by using system call.

First, FIG. 14 shows a conventional shared storage device.
Will be described with reference to. In general, operating
In the system, open / close / read / w for files provided by the file management unit 10
A process such as write is provided in the form of a system call, which is used when an access requester (not shown) makes an access request. In the conventional shared storage device shown in FIG. 14, these system calls are issued to the file access unit 11 open / close / r.
Issue a file access request for ead / write,
The file access unit 11 that has received the file access request executes reading and writing of the file provided by the file management unit 10 according to the request content.

Specifically, the system that the access requester refers to the function of each system call as shown in FIG.
From the call table 41, the actual system call function 140 is referred to and executed. Each system call function 140 directly gives an instruction to the device driver 42 to read / write the file of the file management unit 10.

The structure of the system call table 41 described here is a general outline of a known operating system mechanism called dynamic linking, and generally has a more complicated structure. However, since it is well known, detailed description is omitted.

In the conventional shared storage device having the above structure, asynchronous editing cannot be performed as described above. On the other hand, the shared storage device of this embodiment shown in FIG. 15 uses the configuration of the first embodiment to enable asynchronous editing, and
In the system, rewrite the data in the system call table 41 that references the system call function,
The access monitoring unit 12 is configured to be replaced with a function that issues a shared file access request so that the access requester 21 can be connected to the shared storage device without modifying an existing application program.

As shown in FIG. 15, the configuration of this embodiment is basically the same as that of the first embodiment described above, and the shared file access request given to the access monitoring unit 12 by the access requester 21 is passed. It is a feature of the mechanism of. Therefore, the parts corresponding to those in FIG. 1 are denoted by the same reference numerals and detailed description thereof is omitted, and the shared access request, which is a feature of this embodiment, will be mainly described.

In this embodiment, the access requester 21
Is the system that the system call table 41 has
After referring to the function corresponding to the call, open / cl
Executes ose / read / write functions. The data of the system call table 41 that refers to the function of the system call in the operating system is provided by the operating system.
pen function / close function / read function / write
From the connection data (address pointer) to the e-function 140, the shared operation provided by the access monitoring unit 12
The connection data (address pointer) to the n function / shared close function / shared read function / shared write function 141 is rewritten.

Therefore, the access requester 21 consisting of the existing application program is set to open function / c.
As a result of executing the lose function / read function / write function, the shared open function / shared close function / shared read function / shared write function 141 is actually executed.

Here, shared open function / shared close
The e function / shared read function / shared write function are processes / “close” according to the shared file access request for “opening” described in the first embodiment, respectively.
Shared file access process / “r
This corresponds to a process in response to a shared file access request for "ead" / a process in response to a shared file access request for "write". Note that in FIG.
Although the en function / shared close function / shared read function / shared write function 141 are configured independently of each other, the portion corresponding to the processing common to each function 141 is configured as one processing entity and four functions are provided. You may share in 141.

On the other hand, an actual open function / close function / read function / wri for the file management unit 10 is executed.
The te function is called from inside the file access unit 11. The open function / close function / read function / write function are open / close / for which the file access unit 11 described in the first embodiment actually changes the data to the file management unit 10.
This corresponds to a read / write file access request.

As described in detail in the first embodiment, the access monitoring unit 12 manages the asynchronous access from the access requester 21, and according to the contents of the access information storage unit 14, the file access unit 11 if necessary. To the file management unit 10, and the file management unit 10 reads and writes the corresponding file.

As described above, according to the present embodiment, even if a plurality of access requests for one shared file are asynchronously generated as described in the first embodiment, all are accepted without performing exclusive control. , Data can be read / written / updated without impairing data consistency.

Furthermore, in this embodiment, the operating
Directly to the file access means 11 set in the call table 41 provided by the system, "o
pen ”,“ close ”,“ read ”,“ writ ”
The value of the address pointer to the system call such as "e" (see FIG. 14) is sent to the access monitoring means 12 as "op".
en ”,“ close ”,“ read ”,“ writ ”
Address for passing each access request such as "e"
The value of the pointer, that is, “open”, “close”, “read”, provided in the access monitoring means 12.
Function 141 corresponding to each access request of "write"
Asynchronous editing can be performed by using as an access requester without changing the program itself such as existing application software, simply by rewriting the value of the address pointer (see FIG. 15) for activating Is possible. Further, the present invention is not limited to the above-described embodiments, and various modifications can be carried out without departing from the scope of the invention.

[0095]

As described above in detail, in the shared storage device according to the present invention, the history of a plurality of access requests asynchronously generated for one shared file and the file requested by the access request are performed. The history of the data indicating the contents of the change is stored, and the file stored in the file storage means is rewritten based on these two histories.

Therefore, even if a plurality of access requests are asynchronously issued to one shared file, the changes in the file contents due to all the access requests can be reflected, so that data control can be performed without performing exclusive control. Asynchronous editing can be done without loss of consistency.

[Brief description of drawings]

FIG. 1 is a block diagram showing a main configuration of a shared storage device according to a first embodiment of the present invention.

FIG. 2 is an access state storage unit 1 after requester A has opened.
Figure showing the contents of 4

[FIG. 3] Access state storage unit 1 after requester B has opened
4 and the contents of the history management unit 13

FIG. 4 is an access state storage unit 14 after the requester D has opened.
Figure showing the contents of

FIG. 5 is a diagram showing the contents of an access state storage section 14 being edited.

FIG. 6 is a diagram showing an image of expression of a changed portion.

FIG. 7 is a diagram showing the contents of the history management unit 13 after the requester B has closed.

FIG. 8 is an access state storage unit 1 after the requester B is closed.
Figure showing the contents of 4

FIG. 9 is an access state storage unit 1 after the requester D is closed.
4 and the contents of the history management unit 13

FIG. 10 is a flow chart showing a procedure of insertion processing into the history management unit 13.

FIG. 11 is a flow chart showing the procedure of the insertion processing.

FIG. 12 is a flow chart showing the procedure of deletion processing to the history management unit 13.

FIG. 13 is a flow chart showing the procedure of the deletion process.

FIG. 14 is a diagram showing an example of a system call configuration in a conventional shared storage device.

FIG. 15 is a block diagram showing a main configuration of a shared storage device according to a second embodiment of the present invention.

FIG. 16 is a block diagram of a conventional shared storage device.

FIG. 17 is a diagram for explaining a file operation in a conventional shared storage device.

[Explanation of symbols]

10 ... File management unit, 11 ... File access unit,
12 ... Access monitoring unit, 13 ... History management unit, 14 ... Access state storage unit, 20 ... Storage device, 21 ... Access requester, 31 ... Access history list, 41 ... System call table, 42 ... Device driver, 131 ... Creation time, 132 ... Erase time, 133 ... Size, 134 ...
Data block

Claims (2)

[Claims] 1. A file storage means for storing a file which is a set of data, a request management means for asynchronously receiving a plurality of access requests for the same file stored in the file storage means, and the request management means. A first storage unit that stores a history of the received access request; a second storage unit that stores a history of data indicating the content of a change made to the file according to the history of the access request; And a file rewriting unit that rewrites the file stored in the file storage unit based on the history stored in one storage unit and the history stored in the second storage unit. Storage device. 2. The request management means is an operating system.
A system call table provided by the operating system, which has a plurality of processing units provided corresponding to the contents of the access request, which performs a predetermined process using a program executed on the system. And setting address information for activating each of the plurality of processing units, and the access request is given in a form of activating the desired processing unit using the system call table. The shared storage device according to claim 1.