Shared file system

Description: TECHNICAL FIELD [Detailed description of the invention]

A. Industrial application fields The present invention is an improvement in a data processing system that generally supports shared files, and more specifically, the file is accessed directly and immediately by one or more readers while the file is being updated by the updater. Regarding the process that makes it possible to do. B. Conventional technology and its problems In a large data processing system that runs a database application program, there are generally multiple users who access the files in the database at the same time. In addition, one file in the database may be accessed by more than one user at the same time. The multiple access to a file is permitted if each of the users simply reads the file, but is problematic if one of the users accesses the file for the purpose of editing or updating the file. There is. In such cases, the updater locks out other users until the update is complete or committed, causing a significant delay for the user who needs to access the file to perform the read operation. Sometimes. In such a shared file environment, it is desirable to allow multiple users to read the file being updated in parallel. That way, the reader does not have to wait on the file updater or see for updates to occur until the unit of work, including the update, is committed. Therefore, each reader who opens a file will look up the latest committed file level. An object of the present invention is to provide a shared file environment in which a plurality of users can read a file being updated in parallel. Furthermore, an object of the present invention is an N-level shadow for a file to allow multiple users to read the file even if the file is continuously updated by one or more updaters. To provide a process to maintain (shadow). C. Means to solve the problem According to the present invention, the reader of a file does not have to wait for the updater of the file or check for updates in progress. Each reader who opens the file checks the latest committed level of the file. That is, if reader A opens the file for reading before updater B commits to modify the file, a one-level shadow will appear for the file after updater B commits. Further, while good embodiments of the present invention allow only one file updater at a time, the present invention contemplates a process of maintaining an N-level shadow for a single file. The present invention introduces a new structure called a NAY (meaning "also not usable") structure. This structure contains items from all files that are currently open for reading. More specifically, the NAY structure contains items at each level of the file that are open for reading. The counter associated with the item indicates the number of readers at that level in the file. These items are anchors for a list of the number of blocks in a shadow block. Since there is at least one reader at that level, they cannot be unallocated. The present invention contemplates a procedure for logging block allocations and deallocations to track N-level shadow blocks. D. Example In order to explain the method used to carry out the N-level file shadow according to the present invention, some structures used in the shared file system will be described. A shared file system catalog called OBJECTCAT has a description of files. Figure 1 shows the OBJECT CAT item. This type of item is for each file that exists on the shared file system. The item has block number 10 on the disk where the file data resides. The block number is an internal reference mechanism used to place a 4K block on a given physical direct access storage device (DASD) managed by a shared file system. Since this mechanism is conventional and is not related to the present invention, its description will not be given. The block numbers in the file items are stored in the logical file block order. That is, the first item corresponds to the first block of the file, the second item corresponds to the second block, and so on. When one unit of work updates a file, these file blocks are not updated in the same location. Instead, another block containing the update is allocated. The first block of the file is called the shadow block. When the updater commits to the change, the shadow block is deallocated and the OBJECTCAT item is updated to reflect the updated block number. Related to a file item in OBJECTCAT is the commitment level 12 of the file. This includes the committed level at the end of the file. Immediately, each time a file is updated, the commitment level of the file is increased during the commitment process. The NAY structure shown in Figure 2 contains items for all files currently open for reading. It actually has items for each level of the file that are open for reading. There is a counter associated with the item to represent the number of readers at that level of the file. These items are anchors in the list of block numbers for shadow blocks. Since there is at least one reader at that level, the allocation cannot be canceled. The NAY structure shown in FIG. 2 consists of a set of control blocks of the same size, which can be one of the following. (1) NAY heading block (NAYHBLK) 22 (2) NAYGATE24 to identify the file / commitment level currently open for reading (3) NAYPBNE26, which has been modified by the updater, but contains the physical block number of the block that this reader is still reading. There is only one NAYHBLK22. This control block is a free queue anchor for unused NAY block (NAYBLK) 27. There is also a hash table (NAYHASHT) 28 that optimizes access to NAY structures when searching for open files for reading. The recovery process consists of blocking allocation and deallocation logging. User data in the file is not logged. Allocations are logged each time they occur, but deallocations are logged as part of the commitment log record. Recovery is done at that point to ensure that the block is usable if the unit of work reverts. The part of the recovery process is also a checkpoint. Checkpoints take a snapshot of the system regardless of the state of the unit of work in progress. The fact that you are checkingpoint is logged. When the shared file system is restarted after a shutdown, the system appears to have restarted at the last checkpoint, whether expected or unexpected. The logs are synchronized to the last checkpoint via the checkpoint log record and the recovery process begins at the last checkpoint. To maintain file data consistency, a second block containing updates to the file is allocated by logical units of work. When an update is committed, the OBJECTCAT item in the file (see Figure 1) is updated with the block number containing the update, releasing the shadow block (the picture committed at the end of the block). The commitment level of the file is also increased. If the file has never been shared by readers and updaters, the process is quite simple. When you open a file and search for a block of files, the block number of the data is obtained from the OBJECTCAT item and the data is read from the DASD. When a file block is updated and rewritten, a second block is assigned to the updated file block and these block numbers replace the corresponding OBJECTCAT entry. But in a shared environment, things are not so easy. When a file is opened for reading, a copy of the file's OBJECTCAT entry is cached. Items are also entered in a new structure called the NAY structure, which indicates that this level of the file is open for reading, as shown in Figure 2. The file updater also has a cached copy of the OBJECTCAT entry, but no entry is entered in the NAY structure. Here, the system has records for all readers at any level of any file. The system uses this list to maintain that level of the file until all readers at that level close the file. The latest level (always up-to-date because there is only one updater at a time) updater commits to the update, the OBJECTCAT entry of the file is updated to reflect the new block number containing the update, and the file Commitment level is increased. The affirmation process queries the NAY structure to see if there is a previous level reader of the file. If there is a reader at that level, the shadow block (previous version) will be chained from the NAY entry at that file level and will not be released at this point. When the last reader of the file closes the file, the close process removes this level of NAY structure items in the file and deallocates any blocks chained from the item. The blocks to be allocated and the blocks to be deallocated are logged in the shared file system log as part of the logging performed in the unit of work. The new block allocation is logged as the new record type and the block release is logged as part of the commitment log record. The reason for not releasing the block until it is committed is to maintain file consistency when the unit of work reverts. Otherwise, the block may be allocated to other updated files. If the unit of work reverts, the newly allocated block is released (by reading the log) and the shadow block remains allocated. Further consideration is the interaction with multiple levels of files and checkpointing of shared file systems. As mentioned in the recovery process description, checkpoints take a snapshot of the system, regardless of the unit of work in progress. Now, even if some blocks are still allocated by the readers of the file, they do not exist after restarting, and there is no way to deallocate these blocks, so it does not have to be recorded. .. Therefore, the checkpoint process queries the NAY structure and records in its picture that these blocks are deallocated. Another new structure used in this process is the list of block numbers released by the update. These lists are anchored from a table containing files updated by the unit of work and items by level. Therefore, for each deallocated block of any file updated by the unit of work, the table is traversed for the appropriate file item and the block number is added to the appropriate list. It collects all the blocks to be released for efficient processing by the affirmation process. The logic of the process described above is shown in the flow charts of Fig. 3, Fig. 4 and Fig. 5. In the functional block 30 of FIG. 3, the block allocation / deallocation release process is started by writing the updated block. In the determination block 31, an inspection is performed to determine whether this is the first block update. If not the first time, functional block 32 writes the updated block and terminates the process. However, if this is the first block update, a new block will be allocated at functional block 33. At functional block 34, the updated block is written to the new block, and then at functional block 35, the old block number is added to the deallocated list before the process terminates. Figure 4 shows the commitment process. This process begins with an inspection of determination block 40 to determine if there are any deallocated list items. If not, the user is determined to be the reader only and the process ends. If there is a list item that has been unallocated, a check to determine if there is a reader is performed in the determination block 41. If not, functional block 42 deallocates the old block and control shifts to functional block 44. If there is no reader, control shifts to functional block 44 after functional block 43 adds the old block number to the NAY structure. At functional block 44, the old block number is logged. Then, in functional block 45, OBJECTCAT is updated with the block number, and in functional block 46, the commitment level is increased and then the process terminates. Figure 5 shows the closing process. This process begins with a check in decision block 50 to determine if the user is a reader. If you are not the reader, the process ends. If it is a reader, a check is performed in determination block 51 to determine if the reader is the last reader of the file. If not the last reader, the process ends. If it is the last reader, determination block 52 will perform a check to determine if the file has been updated. If not updated, the process ends. If so, functional block 53 terminates the process after the old block is deallocated. The following pseudo-code written in Program Design Language (PDL) is the detailed logic shown in the flow diagrams of Figures 3, 4 and 5 required to maintain the N-level shadow according to the present invention. To realize. A skilled programmer can write the source code from pseudocode in any programming language such as Pascal or C and retrieve the object code with the appropriate compiler. Open read process Hash the file's FILEID and commitment level IF NAYHASHT item = empty THEN DO Get NAY BLOCK from NAY FREEL Build a NAYGATE consisting of FILEID / commitment levels Chain to NAYHASHT items END ELSE DO Scan the NAYGATE chained from the NAYHASHT item IF FILE ID / commitment level NAYGATE not found THEN DO Get NAYBLOCK from NAYHASHT item Build a NAYGATE consisting of FILEID / commitment levels Chain to NAYHASHT items END ELSE (NAYGATE found) Increase open count during NAYGATE END Block write processing IF THEN where the block is being updated first in this unit of work DO Log the block number to allocate a new block containing updates Add the old block number (which will be deallocated by commitment) to the LNALLOCATE list Store the newly allocated block number of the file updated by the commitment in the cached OBJETCAT. END (Note): The deallocation list is composed of FILEID / commitment level. The block numbers are chained to their appropriate file items. Close read process Decrease NAYGATE open count IF open count = 0 THEN DO Unallocate the blocks chained to NAYGATE Return NAY BLOCK to NAY FREEL END Affirmation processing For each file item in the allocation release list DO Hash the FILEID and commitment level IF NAYHASHT item = empty THEN (read's lightning If you do not) DO Unallocate Blocks in the list item are unallocated END ELSE For each DO update block About NAYPBNE Get NAYBLOCK of NAYFREEL (free list). Store the block number in NAYPBNE Unchain NAYGATE END Log the block number to the commitment log record Update the OBJECTCAT of this file with the new block number to increase the commitment level (so new readers will check for updates) END Checkpoint processing Scan the NAY structure For each NAYPBNE DO Unallocate the checked-pointed copy of the block in the block allocation map END E. Effect of invention According to the present invention, the file can be read even before the update of the file is promised.

[Simple explanation of drawings]

Figure 1 is a block diagram showing the file description format for items in the shared file system catalog called OBJECTCAT. FIG. 2 is a block diagram showing a NAY structure. FIG. 3 is a flow chart showing the logic of the block allocation / allocation release process according to the present invention. FIG. 4 is a flow chart showing the logic of the commitment process according to the present invention. FIG. 5 is a flow chart showing the logic of the closing process according to the present invention.