Remote file access system

[Detailed Description of the Invention]

A, Field of the Invention The present invention relates to the processing system connected via the network, and relates to access of the file between the local processing system which is more specifically in distributed networking environment, and a remote process system. B, conventional technology As shown in Drawing 10, distributed networking environment 1 comprises two or more nodes A1B and C which were connected via the communication link or network 3. A local area network (LAN) or a wide area network (WAN) may be sufficient as network 3. WAN comprises tele processing (TP) connection by the switched line or dedicated line to a system-network-architecture (SNA) network of a system as opposed to other nodes. Arbitrary nodes A and 81G have processing system l0A110B110C, such as personal Con- pewter. A single user system or two or more user system may be sufficient as such processing system l0A110B110C, and it has the ability to access the file which is in a remote node via network 3. For example, processing system IOA in local node A can access file 5815C in remote node B and C. If it considers how a stand-alone system accesses a file first, he can understand well the problem which collides when accessing the file in a remote node. In the inside of a stand-alone system like ten of Drawing 2, Buffer storage of the data transmitted using local buffer 12 in operating system 11 between the disk in permanent memory storage 2, for example, a hard file and a personal computer, and a user address space is carried out. Local buffer 12 in operating system 11 is also called local cash or a kernel buffer. Within the stand-alone system, kernel buffer 12 is identified by block 15. This number is a device number and is also a logical block number in that device. When reading system call 16 is published, it is published with the file descriptor of file 5, and the byte range in file 5, as shown in Step 101 of Drawing 3. Operating system 11 takes out this information and changes it into a device number and the logical block number in a device (Drawing 3, Step 102). Next, operating system 11 reads cash 12 based on a device number and a logical block number (Step 103). The data read in disk 2 is stored by Cash Brock 15 until Cash Brock 15 is needed. As a result, if reading to the same data as what was read in application program 4 under run before is continuously required on processing system 10, it will be accessed by disk 2 from cash 12. In order to read in cash 12, it appears in a fixed disk and the right disk sector is accessed, and it does not take time rather than reading in the disk. Similarly, the data written in from application program 4 is not directly stored by disk 2, but is written in cash 12. For this reason, when another write-in operation is issued to the same Brock, access to a disk is saved. The corrected data block in cash 12 is periodically kept by disk 2. Another use of the local cash in a stand-alone system is effective data [ as opposed to / also after the file was closed / the file ] =5 - It is holding. When it is re-opened by the file while such Brock still existed in cash, although those Brock is read, access to a disk is unnecessary. AIX Since access to a disk is not needed in continuous reading and writing if the stand-alone system using an operating system (an extended dialogue executive and AIX are the trademarks of IBM) uses cash, the overall performance of a system improves. Overall performance ' is improved because cost starts later than the direction which accesses permanent memory storage accesses cash. In a distributed environment as shown in Drawing 10, there are two methods with which processing system 10C in local node C reads file 5A in node A. In one method, processing system 10C copies the whole file 5A, and it can perform that thing [ reading like ] which is local file 5C which has it in node C. If a file is read in this way, after file 5A is copied by node C, when another processing system 10B110A in another nodes A and B corrects file 5A, a problem will arise. Processing system 10C can access the newest correction to this file 5A. Another method which accesses file 5A which has processing system IOC in node A reads one Brock N1 at once, when the processing system in node C requires. The problem accompanying this method is having to go to node A which has a file at every reading via network communication link 3. Sending data at every continuous reading requires time. When accessing a file via a network", two incompatible problems of two accounts arise. One problem is that transmitting data via a network for continuous reading and writing takes time. On the other hand, when memorizing file data to a node in order to reduce a network traffic, there is a possibility that the compatibility of a file may be lost. For example, when one of some nodes is writing in the file, other nodes which have accessed the file may not have accessed the latest updated file in Decree writing Included rare It was. Therefore, since there is a possibility that the file which a certain node has accessed is not right and of becoming old, the compatibility of a file is lost. In this specification, the word "server" will be used to point out the node which has memorized the file eternally, and the word of a "client" will be used to point out other arbitrary nodes which have the processing which accesses the file. However, please understand that the word "server" does not mean a dedicated server which is used for some local area network system. The distributed service system which carries out the present invention in it is a system dispersed [ truly ] which supports the application of the extensive kind it runs by various nodes in a system which can also access the file which is where in a system. Although the case where the present invention is carried out by one version of a UNIX operating system (what AT & T develops and is licensing a grant, and UNIX are the registered trademarks of AT & T in the U.S.) is explained below, The present invention can use other operating systems with the feature similar to a UNIX operating system. A UNIX operating system is Bell Laboratories (Be11 Telephone Laboratories). Although Inc develops to the mini computers of a digital 0 equipment company (Digital EquipmentCorporation, DEC), These days, it is widely used for the wide range object for mini computers, and it as an operating system for microcomputers. As for a cause of this %f And, a UNIX operating system is written not by an assembly language but by C programming language developed too in Bell Laboratories. Therefore, it is a kind of processor Between trap =9 - It is and they are things. Therefore, if C compiler written to various computers is used, it will become possible to transplant a UNIX operating system to another computer from a certain computer. About the details of a UNIX operating system, they are [UNIXTM system, user's manual, and system V (U N I XTMSystem, User's Manual.). System V J Western Electric Co Refer to one monthly publication in 1983. The outlines which the UNIX operating system exceeded are B, W, and Kernighan (Brian Ij). The collaboration of Kernighan and lob A part (RobPike) "it has appeared in UNIX programming environment (The Unix Programming Environment) JPrentice-tlalls 1984 annual publication. About the details of a design of a UNIX operating system, M, J, and the Bach (Maurice J, Bach) work "it has appeared in design (Design of the Unix OperatingSystem) JPrentice-11all of a UNIX operating system, and 1986 annual publications. Bell Laboratories are licensing a grant UNIX operating system use to many organizations. There is a version of some now. The newest version that came out from AT & T is version 5*2. Another version of the UNIX operating system known as a Berkeley version was developed by 14 California State University bark. Microsoft Corp. which developed MS-DO8 and the PC-DOS operating system for personal computers which are used widely is taking out the version known for the trademark of XENIX. IBM RTPC (RISC (reduced instruction-set computer) technical personal computer) In connection with RT and RTPC having announced the trademark of 18M corporation in 1985, 18M corporation exhibited the new operating system called AIX. AIX has the UNIX operating system, version 5.2, and the compatibility of AT & T on an application interface level, and includes the expanded function to a UNIX operating system and version 5.2. About the details of an AIX operating system, "Please refer to 11 monthly publications in AIX operating system technical explanatory (AIX OperatingSystem TechnicalReference) J 1st edition N I BM Co r pll 985. Specifically, the present invention is related to a distributed data processing system, wherein interconnection of two or more processors is carried out in a network. the actually carried-out form -- the present invention -- the system network architecture (SNA) of IBM -- furthermore -- concrete -- SNA A plurality of IBM where interconnection was carried out by LU 6.2 Advanced Program to Program Communications (APPC) RT It functions on PC. SNA About the details of LU 6.2, It is MInternational Systems more. The technical report which Centerts published in July, 1983 "a guide to Advanced Program to Program Communications (APPC) (An Introduction to AdvancedProgram to Program Communication) (APPC) Guidance and explanatory of the rIBM PCSNA access method of J data number GG24-1584 to zero month, and the August, 1986 15 daily publication RT (IBM RTP CS N A Access Method Guide) With 08NA by which andReference J should be referred to, As the link level, the Ethernet (Ethernet is a trademark of Xerox Corporation) or 5DLC (Synchronous Data Link Control) which is the local area network (LAN) which Xerox Corp. developed is used. The easy explanation of a local area network including an Ethernet local area network is L. E, Jordan (Larry E, Jordan) and B, Collaboration rIBM of Churchill (Bruce Churchill) Communication networking J Robert J for PC (Communications andNetvorking for the IBM PC) It has appeared in Brady (subsidiary of Prentice-Hall), and 1983 annual publications. Explanation clearer than the communications system for computers especially SNA, SDL<?, and of, R, J, and Shipser (Cypser) work "it has appeared in communication architecture for distributing systems (Communications Architecture forDistributed System) J , and Addison-Wesleys 1978 annual publication. However, the present invention is an Ethernet local area network and IBM. IBM by which interconnection was done in networks other than SNA RT Please understand that it can carry out even if it uses various Cong Peter other than PC. As mentioned above, below, the present invention is explained for the distributed data processing system in a communication network. In this environment, if each processor in a node with a network will have a file in which node, it can access all the files in that network potentially. Otherwise, the method of supporting a distributed data processing system within a UNIX operating environment is known. For example, Sun Microsystems announced the Network File System (NFS), and Bell Laboratories developed the remote file system (RFS). NFS of Sun Microsystems is indicated in a series of publications. For example, S, R and Archie Tecuci + for a multiplex file system type in clay man (Kleiman) r V node:5unUNIX (Vnodes: An ArchitectureforMultiple File System) Types in Sun UNIX J USENIX A 198E3-year summer international technical meeting and the show minutes, 238 - 247 pages; R, sand Barb (Russel) A design and operation (Design andImplementation of the Sun NetworkFilesystem) J of Sandberg etc. of a rSUN Network File System UNEN I X The 1985 minutes of the meeting, 119 - 130 pages; D, outline (Overview of the SunNetwork File System) J 117 -124-page; of rSUN Network File Systems, such as Walshe (Dan 1Jalsh), -- Joey Chang (Jomei) "situation monitor of Chang brings network locking service to NFS (Status Mon1 tor ProvidesNetwork Locking 5ervice for NFS) -- J; Joey Chang's "Sun net (Sunnet) J 71-75 page; safe networking (SecureNetworking in theSun Environment) J in B and the rSun environment of a tiller (Bradly Taylor) 28 - 36 pages. RFS of AT & T is also indicated in a series of publications. For example, A, P Outline (RF S Arcchitectural Overview) J U 5ENIX minutes of the meeting of the rRFS architecture, such as Rifkin (Andrew P, Rifkin), Joe Xia state Atlanta (June, 1986), 1 - 12 pages; opinion (An Administrator'sView of Remote File Sharing) J of the administrator to "remote file common use of R, Hamilton (Richard) lamilton, etc., 1 - 9 pages; T, HEYTON (Tom Houghton) etc. "file system switch (File SystemsSwitch) J, 1- the framework for networking (AFramework for Networking in System V) in "systems V, such as 2page;D, J, and the Netherlands (David J, 01ander), -- J N 1-8 page. the distributed service system for which the present invention is carried out in it -- again -- NFS of the For example Sun old crosystems is that one feature distinguished was for the method of Sun to design a state un-saving type device fundamentally. Speaking more concretely, being able to design the server in a distributing system to a state un-saving type. Namely, as for the server, which client node opened the server file. the file of a client is open in read-only mode -- or it reads and is open by the write mode Or no information about a client node including whether the client has covered the lock over the byte range of the file is memorized. Since a server does not need to process the error recovery situation which arises when it becomes off-line, without telling exactly that the client node broke down or it canceled the demand to server resources to a server if such an embodiment is taken, the design of a server becomes easy. A completely different method was taken in the design of the distributed service system which carries out the present invention in it. Speaking more concretely, being able to characterize it as this distributed service system being a "state preservation type." The "state preservation type" server written in this specification holds the information about who is using the file and how the file is used. In it, a server detects loss of contact with the client which is a certain method, and needs to enable it to discard the accumulated state information about the client to it. However, the cache management strategy written in this specification cannot be carried out unless a server holds such state information. It is affected depending on whether the number of the client nodes which have published the demand "open a server file", and such opening are in reading mode, or it is write-in mode so that management of cash may be explained below. It is glance-like [ the present invention ] to improve the response time at the time of accessing the problem which C0 invention tends to solve, therefore a remote file. It is the 2nd object of the present invention to maintain the compatibility of a file in a distributed networking environment. When a file is closed by a client node, it is the 3rd object of the present invention to hold valid data using cash of both a server and a client node. The means for solving D0 problem In order to reduce the traffic overhead of a network when accessing the file in other nodes and to maintain the compatibility of a file, access to various files within distributed networking environment is managed in file synchronous mode. When the file opens only by one node for reading access or write-in access, the 1st synchronous mode is given to a file. When the file opens by arbitrary nodes for read-only access, the 2nd synchronous mode is given to a file. It reads by a plurality of nodes, and the file is open for access, and when it writes in by at least one node and the file is open for access, the 3rd synchronous mode is given to a file. When a file is in 1st or 2nd synchronous mode, a client node, i.e., the node which accesses a file, memorizes a file using the cash in the operating system. All of subsequent reading and writing are sent to this cash. When the file closes by the client node, although valid data is held, cash is used for the system and method of the present invention by both the client node and a server node. While the data file closed by the client node, it is decided [ whether the data in client cash was corrected, and ] by another node whether a client node will re-use client cash. When data is not corrected, a client node can be accessed by reading and writing from the process in a client node, without spoiling the compatibility of a file. All the data in client cash is valid data. When it opens once the file closed, by accessing using client cash, network traffic overheads decrease in number, therefore response time is improved. While the file closed by the client node, in order to judge whether the data in client cash was corrected by another node, the system of the present invention contains the substitute i node in client cash. The substitute i node contains the field which identifies a server node, and the file handle which identifies the file in the node. When it was opened by the substitute i node by the node which has a file first, or begins after the last closing and is opened, it is created within client cash. When a substitute i node is created, the last correction time of the file recorded with the clock of the server is written in a substitute i node. the system of the present invention -21= -- the file correction time field which shows the last correction time of the file in a server again is included in the cash data block. The file correction time field in a cash data block is updated while the file closes at the end by the client node. The method of the present invention contains each of following steps, while a file opens and is read and closed by a client node. If opening of a file is taken out to a client node, the substitute i node table in a client processing system will be scanned, and the existing substitute i node will be looked for. When there is anything [ no ], a new substitute i node is assigned and a remote open procedure call is sent to a server. If the opening is completed by a server, the last correction time of the file will be included in the open acknowledgment from a server to a client node. This time is recorded on the substitute i node which that file is new and was assigned by the client node. When the new data block of the file is read, new Cash Brock is assigned in client cash. Each cash Brock includes the last correction time from a server node name, a file handle, and a substitute i node. When it is opened by the file the 2nd time and afterwards, it scans the substitute i node table in a client processing system and looks for the existing substitute i node, the substitute i node will already have existed from former opening. In this case, there is no change of correction time or a substitute i node. The last correction time on a data block is not changed even the 2nd opening. While the file in ASYNC mode is closed at the end, each following step is performed. First, a client node sends a closing demand to a server. Next, if Acceptance takes a closing demand from a client node, a server will send the acknowledgment of the closing to a client node. With the acknowledgment of closing, a server spends the last time when the file was corrected to the client node. The server may have to go to the disk of a server, in order for this last correction time to come to hand. Next, a client node cancels assignment of a substitute i node, and scans all the remote cash buffers in search of the file handle to the server node name and file closed. Next, Acceptance changes from a server all the last correction time in Cash Brock to whom a client node corresponds into the taken last correction time with closing acknowledgment. When Brock is read in client cash, the time in a substitute i node is compared with the time in a cash data block. When the time in a substitute i node is larger than the time in a cash data block, while the data file is closed by the client node, it is shown that the data in client cash was corrected. In this case, the client node must go to a server via a network in order to obtain data corrected [ last ]. In order to maintain the compatibility of a file, all the data blocks to a file within a client node must be repealed. When the time in a substitute i node is the same as the time recorded on the cash data block, it is shown that the data in client cash is still effective. While the file was closed by the client node, other nodes did not correct this data. In this case, the data block in client cash can be used for the process in a client node, without a file going to the server which actually exists via a network. E, an example In the present invention, as shown in Drawing 4, local cash 12A112B and 12C exist in each node A1B and C, respectively. Node A is called a server when a file resides permanently eternally on disk 2A of node A. At server A, it is Saba Nor =25. - How to use cash 12A by local process 13A performed by Do A is the same as that of the case of the stand-alone system described in the example of the above-mentioned conventional technology. However, remote process 13B113C performed by nodes B and C accesses file 5 according to a two-step cash advance system using Saba Cash and client cash, as clearly shown in Drawing 5. Server node A obtains file Brock 5 from disk 2A, and memorizes it to Saba Cash 12A. Client node B obtains file Brock 5 from Saba Cash 12A via network 3. Client node B remembers file Brock 5 who was in Saba Cash 12A into client cash 12B. When user address space 14B of client node B seeks data from file 5 in ASYNC mode or READONLY synchronous mode, client cash 12B is accessed instead of accessing via network 3 for every access. Since a network traffic overhead is reducible if remote file 5 is accessed using client cash 12B, performance can improve remarkably. Saving the file access semantics in an application program level, use of client cash 12B and Saba Cash 12A is managed in a distributed environment so that high performance may be attained. It can be made to run without correction the existing program it runs by a stand-alone system with a distributing system by carrying out like this. File access semantics is compatibility To keep of a file, when another process opens a file, and publishing reading and a write-in system call, accessing a file and correcting it. The requirements for this file access semantics are that another input-and-output operation to the byte range of the same file cannot carry out forcible exclusion of that input-and-output operation once in which byte range of every time only one input-and-output operation is allowed but a certain input-and-output operation starts. With reference to Drawing 5, the example of - is shown again. When process 131 wrote in to byte range N1-N2 in file 5 and a system call is published, Only when process 131 can be accessed at the byte range N1-N2 whole and reading operation about byte range N1-N2 is not performed, a write-in system call can be performed. During execution of a write-in system call, other the operations of all the about byte range N1-N2 of file 5 are interrupted until the writing is completed. A byte is written in local cash 12A, it begins, and writing is completed. When a write request is completed, the data written in cash 12A comes to appear by the next reading operation by either of other process 131-13N. Another requirement for file access semantics, When the byte range of files, such as N1-N2 (1 set of related records which at least one record accesses by the same input-and-output operation may be sufficient) can be seen by reading operation, Byte range N1-N2 of a file must contain 1 set of consistent data which always reflected the latest updating to this range. This byte range cannot be accessed during execution of write-in operation. In this way, in the next reading demand advanced from a certain process, not data but the writ Took data before updating which became old read, and they are Take and To be. In the distributed networking environment of the present invention shown in Drawing 5, Different execution of reading from application program 4A14B and process 131-13N1231-23N and a write-in system call synchronizes, and the above-mentioned file access semantics is saved. A synchronization is guaranteed using various cash synchronous modes. According to the position of process 131-131N which is opened since file 5 is access, and has become synchronous mode about specific file 5, and 231-23N, an input-and-output call synchronizes by either client node B or server A. Three synchronous modes are shown in Drawing 6, and while referring to Drawing 4, it explains. The 1st mode is called the ASYNCs-mode, i.e., asynchronous mode. In this mode 41, as shown to Brock 44 of Drawing 6, when file 5 is open for reading / write-in access by process 13C performed only by one client remote mode, file 5 operates. In this mode 41, all the rights of control are in client node C. Saba Cash 12A and client cash 12C are used for these reading / write-in operations. Only when it cannot fill from client cash 12C, access to Saba Cash 12A is needed by reading or write-in operation. When file 5 is closed by periodic synchronous operation or all the processes 13C in the inside of client node C, Or in order to leave the space which puts other data into cash, when Brock must be written in, the corrected data block in client node 12C is written in server 12A. When a file is changed into the FULLSYNCs-mode from the ASYNCs-mode, a corrected data block is written in server 12A. The 2nd mode 42 is READONLY. It is in s-mode 42. READONLY s-mode 42 is used for file 5 which is open because of read-only access from process 13in a plurality of nodes B1C B113G from process 13G in one node C as shown to Brock 45 of Drawing 6. In this mode 42, both Saba Cash 12A, and client both [ one side or ] 12C are used. A reading demand is published to one or more Brock at a stretch. No other reading demands to the specific data block from the same client node B or C go to server 12, but are read in client cash 12A or 12C of this The. When in other words it can fill from client cash 12G or 12B, access to server 12A is not required of reading operation. File 5 is READONLY when file 5 is open for read-only access by arbitrary nodes A1B, process 13A in C, and either of the 13B113C, if it collects. It operates in s-mode 42. The 3rd mode 43 is the FULLSYNCs-mode. FULLSYNCs-mode 43 is used for file 5 which is open because of write-in access by process 13A in server node A as Brock 48 of Drawing 6 shows. Brock 46.47 of Drawing 6 shows this synchronous mode 43 -- as It is used, also when file 5 opens by server node A and other at least one node B1C, and it writes in by at least one process 13A113B113C and file 5 is open for access. The file is in FULLSYNCs-mode, when file 5 generally opens by a plurality of nodes, it writes in by one of those nodes and the file opens for access. In FULLSYNCs-mode 43, client cash 12C or 12B detours, and only Saba Cash 12A is used. All of reading operation and write-in operation are performed by server 12A. In distributed networking environment 1 of Drawing 4, a great portion of file 5 is, READONLY Process 13A113B in a plurality of node A1B1C in s-mode 42 (Drawing 6), The direction which is opened for read-only access by 13C, or is opened by one node in AsYNCHs-mode 41 for updating, It is more frequent than opening for reading / write-in access by the process performed by a plurality of nodes in FULLSYNCs-mode 43. READONLY s-mode 42 or ASYNCs-mode 41 is also client cash 12BI! In order to use 5 figures, the response time which accesses file 5 of remote reading / writing decreases remarkably, and overall system performance improves. As shown in Drawing 8, client cash is not used in the FULLSYNCs-mode. Client node B accesses at each reading and every writing via network 3 at file 5 from server A. In this mode, although reading / write-in response time increases, since a client node does not hold file 5 which is not updated together with the corresponding file which resides in server A permanently into local cash, file access semantics is saved. Since reading / write-in speed of response will average on the whole, and will increase and the compatibility of a file will be maintained if use of client cash is managed using these three modes, overall system performance becomes the optimal. Since client cash is used in a certain situation, reading / write-in response time decreases, and since client cash is not used in another situation, file system semantics is saved. Or [ that the file of the synchronous mode of a file is open by which node ], and it is open because of reading of a file -- or it is dependent on whether the device with which it being open because of writing and a file exist is open by the raw (raw) access mode. Raw access to a certain device is meant as data block LBNI in device 2A (Drawing 5) being accessed. That is, reading and the writing of device 2A are reading and the writing to data block LBNI of device 2A. The data block is not important in to which file it belongs. Device 2A cannot be opened because of raw access from remote node B1C, although it can open for raw access from process 131-13N in server node A. Reference of Drawing 5 will manage cash 12A as Brock LBN1 of device 2A like the stand-alone system previously explained about Drawing 2. Server A looks at Saba Cash 12A as logical block LBNI in device 2A. It is not known where [ on device 2A ] client node B has file 5. Client node B knowing is only having accessed file 5 in the Brock number N1 of device 2A. Client cash 12B treats data as logical block N1 of file 5. Within Saba Cash 12A, data is treated as logical block LBNI of device 2A. When treating data in this way, it can guarantee that as for server A the data written in newly appears by the reading when reading to Brock who data was written in the device as the main unit, and was written in the device of the file, and the same Brock suits independently. For this reason, file system semantics is saved. As shown in Drawing 5, the file is accessed by client node B, And when a file is in ASYNC mode or READONLY mode, it is client operating system IIB, The byte range in the file descriptor in system call READ16 (a file descriptor, N1) and a file is not changed into a device number and the logical block number in a device. A client changes a file descriptor and the byte range into a file handle, a node identifier, and the logical block number in a file. In client cash 12B, Brock 17 specified by the file handle, the node identifier, and the logical block number in a file exists. it reads in application program 4B of a client, and demand 16 publishes -- having (Step 104 of Drawing 9) -- the reading demand -- a file descriptor and the byte range in a file -- Operating 3 Huu It is the other side to A system IIB. Next, operating system IIB looks at client cash 12B (Step 105 of Drawing 9). When a file handle, a node identifier, and the logical block number in a file are there, cash 12B is read (Step 106 of Drawing 9). When there is nothing there (Step 107 of Drawing 9), the reading demand is sent to a server (Step 108 of Drawing 9). A server changes the logical block number in a file handle and a file into a device number and the logical block number in a file next (Step 109 of Drawing 9). A thing to be changed [ this ] is because Saba Cash 12A is managed by the device number and the Brock number like a stand-alone system. A reading demand is treated like the case where it reads by the stand-alone system previously explained about Drawing 2, and the demand is coming from the application program of itself, after being sent to a server. There is nothing in the file closed in synchronous mode. However, if it is begun and opened by the file according to a certain process, as shown in Drawing 7, initial setting of the synchronous mode of a file will be carried out as follows. The device (D) with which a file exists is closed, namely, when not specially opened as a device, initial setting of (61) and the synchronous mode of a file is carried out to AsYNC mode 41, and it is opened by the file to write-in access by one remote node (62). It is (63), when the device with which a file exists is closed and the file is open for read-only access by one or more nodes, Or when the device and the file are open because of read-only access, (64) and the synchronous mode of a file are READONLY42. It is (65) when the device with which a file exists is open as a Brock special device for reading / write-in access, Or a file opens by a plurality of nodes, and when at least one opening is a thing to writing, initial setting of the synchronous mode of a file is carried out to FULLSYNC mode 43. A Brock special device means that there is raw access to the device. If initial setting is carried out to the mode with a file and conditions will change, file mode may also change. The shift to another mode as shown by lines 71 thru/or 76 in Drawing 7 from a certain mode may take place on condition of the following. A file is in ASYNC mode 41 now, and when the number of nodes with which the file (F) is open becomes two or more, as line 72 shows in (81) and Drawing 7, synchronous mode changes to FULLSYNC mode 43. When there is opening of Brock special Equipment in which a file exists, (82) and synchronous mode change from ASYNC mode 41 to FULLSYNC mode 43. In not the last closing of a file but a file, to writing, as for a mode change, about closing operation of a file, the closing operation does not take place, when still open. However, the closing operation is the last closing to write-in access of the file, and when all opening that remains is the things to reading access, (83) becomes the mode in which READONLY mode 42 is new, as line 74 shows. When the closing operation is the last closing of the file, there is no synchronous mode. A file is READONLY now. If [ opening / the / as opposed to / when it is in s-mode 42 and file open operation occurs / reading ], there is no mode change. However, it is (84) when all the opening is performed by one client node, as the opening shows by line 73 to writing if. ASYNC mode 41 turns into new synchronous mode. Otherwise, synchronous mode is FULLSYNC mode 43. When the device with which a file exists is open to reading / write-in access, (87) and the new synchronous mode of the file are FULLSYNC modes 43. About closing operation, when the closing is the last closing of the file, there is no synchronous mode of the file. After closing operation, when the file is still open by one or more nodes, there is no change in synchronous mode. A file is in FULLSYNC mode 43 now, and when there is another opening to the file, or when it is opened by the device with which a file exists, there is no change in synchronous mode. Opening for reading / write-in access remains by one remote node after closing operation of a file, And when not opened by the Brock special device with which the file exists, as shown by Brock 88 via line 71, synchronous mode changes to ASYNCs-mode 41. It is not opened by the Brock special device with which a file exists, and is shown by Brock 89 on line 75, When opened by the file to read-only access by one or more nodes, Or when it is opened to read-only access by the Brock special device with which a file exists and is opened by the file to read-only access, synchronous mode changes from FULLSYNC mode 43 to READONLY mode 42. All the open operation and closing operations to a file and a device are solved by a server node. A server determines the synchronous mode of an open file, when performing arbitrary operations which may change synchronous mode. A server performs change in synchronous mode. When a server gains new opening or closing to the file, the trigger of the change in the synchronous mode of the file may be carried out. When the synchronous mode needed is not the present mode, a server sends a "synchronous mode change" remote procedure call (rpc) to all the clients to which the file is open. After being opened for the first time by the file, the mode of the file is known by the client which opened the file. When the mode is ASYNC or READONLY, in the case of [ for reading ] ASYNC mode, a client can start use of client cash also for writing, as shown in Drawing 5. The client does not need to perform reading or writing to a server via a communication link. As shown in Drawing 8, when the mode is FULLSYNC mode, client cash is not used but the client needs to send reading or writing to a server via communication link 3. Server A of Drawing 5 always sets up mode 51 of file 5. Server A knows again whether it is a thing to writing, or of which node the file's being open and those opening will not receive reading. Server A does not need to know whether the file is open to process 131in node-13N1231-23N. A server saves all the above-mentioned information in file access structure 50. In structure 50, synchronous mode 51, list 52 of nodes in which the file is open, 53 reading of file 5, and 53 writing to file 5 are included. File access structure 50 is linked to i node 55. i node 55 contains file header 56 for identifying file 5. One node 55 contains Brock 58 including the information about where [ on a device ] Brock 57 who includes the information about on which device a file exists again, and a file exist. i node 55 contains two time bits 111 and 112 again. A time bit is used in i node 55, in order to help pursuit of the information about the file. Time access bit 111 shows that the file or data was read. Time change bit 112 shows Tiger which the data or file wrote in and was correction-45= Carried out by access. If time change bit 112 is set up and either of the three following phenomena happens, the actual time in server A and the corrected data in Saba Cash will be written in disk 2. Three sorts of phenomena are a file situation inspection, a file closing, and periodic contemporary. A periodic synchronization writes cash in a disk for every minute periodically. If the data in server time and Saba Cash 12A is written in disk 2, time change bit 112 will be reset. When the file situation inspection demand has come out, server A inspects whether the file is open, when time change bit 112 is set up by the inspection of i node bit, new time to show situation demand time is written in, and a situation is returned. When a situation demand comes out after that, Acceptance will take time for a demand node to show the change time of a file. Time bit 112 is not changed to the next situation demand. After client B closes file 5, client B uses the file correction time set up as mentioned above as presentation which shows that file 5 was changed. When the file with client B was closed and it is the last closing, a server escapes from file access structure 50 over the closed file 5. When the file has been closed by node B and another node carries out the file to open, file access structure 50 includes only the information about an opening node in Brock 52. If in other words the file which has node B once is closed, a server will hold no [ which shows that node B opened the file before ] information. As mentioned above, a file is a process under execution at a plurality of client nodes B and C and server node A, What (namely, READONLY mode) is also opened to read-only access is made, and it can open according to the process only in one client node for reading and writing (namely, ASYNC mode). In both case, the client cash in each client node has effective Brock of the file potentially. When a file is closed by all the processes in client B, each block of client B is not cancelled automatically. When it re-opens a file according to one process of nodes B by holding the data block which can be used into Tarai End B, it is not necessary to take out remote reading to this data to server A. The system and method of the present invention give a means to judge whether the file which is while client node B closed file 5 in client node B was written in by another node. Client B can use file Brock in client cash, only when write-in operation to the file is not performed while the file was closed by client B. When it is not changed while client node B re-opened this file and that file was closed by client node B, client node B can access file 5 directly from client cash 12B. When it is changed while client node B re-opened file 5 and file 5 was closed by client node B, client node B must go to a server via network 3, in order to obtain changed file 5. Then, a changed file is memorized by client cash 12B in order to access later. The system and method of the present invention can be best explained, if Drawing 10 and Drawing 11 are referred to at the time of Easy. file 5 will not open without process 131 in client mate B -- having (Step 120) -- client node B creates substitute i node 114 (Stepe 21). The substitute i node is the same as that of i node except the point which does not include all the information that i node includes. If opening to remote file 5 is taken out with client node B, in order to look for the existing substitute i node to file 5, the substitute i node table in a client processing system is scanned. When a substitute i node does not exist, a new substitute i node is assigned. An open remote procedure call is sent to a server from a client. When the opening is completed by a server, the open acknowledgment sent to a client from a server will include the last correction time over file 5. The last correction time 22 over file 5 written in server disk 2 is recorded on substitute 1 node 114 which it is [ in Brock 115 of client node B ] new, and was assigned (Step 122). Correction time T1 recorded on Brock 22 and Brock 115 is not client B but the time in server A. In server node A, file-among Brock 52 access structure 50 is updated so that it may be shown that the file is open by node B (Step 123). Next, when the first reading is taken out, data block 116 under client cash 12B is assigned (Step 124). Bit 152 of the beginning of data block 116 identifies server node A. The 2nd bit 153 is by file alder Including dollar for identifying file 5. If new Cash Brock is assigned to a certain Brock in file 5, correction time T1 acquired from Brock 115 of substitute i node 114 will be copied to the cash block header of bit 117 of data block 116. By server node A, file access structure 50 shows that the number of reading in Brock 53 is 1 (Step 125). In the 2nd opening (Step 126) from process 232 from client node B, new substitute i node 114 is not created. When it is further opened by file 5 after that by a client node, using substitute i node 114 assigned before, the file correction time memorized by the first opening is not updated. When process 231-23N [ which ] which opened file 5 in client node B to 2nd reading is performed, Another data block 118 under client cash 12B is assigned, and time T2 in Brock 115 of substitute i node 114 is written in Brock 117, new data block 118. It is updated so that it may reflect that there was two opening for reading in Brock 53 of file access structure 50 of server node A corresponding to it (Step 128). When process 231 in client node B closes file 5 (Step 129), the cloth is sent to server node A. Next, server A carries out the decrease part of the use count which shows the number of reading in Brock 53 (Step 130). In this example, the count should be set to 1 from 2. When file 5 is closed at the end by client node B (Step 131), server A carries out the decrease part of the use count in file access structure 50, and it makes it there be no opening in node B. Brock 53 and Brock 54 in file access structure 50 become zero. If these Brock becomes zero about a certain client node, a server will get to know that the last closing was performed, and will remove file access structure 50 over the client B (Step 132). Server A sends closing acknowledgment to client B (Step 133). A server returns the time of the last corrected together with this acknowledgment as that file was recorded by the server. When a file is in ASYNC mode, client cash is scanned and correction time is updated using the time under closing acknowledgment about all the Cash Brock who does what of the file handle to file 5. In short, all the time in data block lie and 118 is updated in last time T2 to file 5 in Brock 22 written in device 2 (Step 134). When the last closing is performed by client node B, client node B cancels substitute i node 114 created in the first opening at Step 121. After last closing by a client node, process 231-23N in client node B may re-open file 5 (Step 135). In this re-opening, client node B creates new substitute i node 150 to file 5, and writes the last time T3 in Brock 151 of substitute i node 150 from Brock 22 of device 2 of a server (Step 136). When other nodes A1G do not change file 5 while file 5 had been closed by client node B, it is between [ T3 ] =54- at the time of disk 2"2, It should not be changed from time T2 written in from disk 2 during closing acknowledgment (Step 133.134) data block 11Ef and 118. However, when other nodes A1C write in file 5 while file 5 had been closed by the client node, Time T3 in Brock 22 of device 2 should become larger than time T2 written in from disk 2 during closing acknowledgment (Step 133.135) at data block 116.118. If it is re-opened by the file which is client node B as shown to judgment Brock 137 of title 11 figure, Time T3 in Decree writing Included rare It was is compared with time T2 in Brock 117.119, data block 118.118, at new substitute i node 150 in Brock 151, respectively. When time T3 in substitute i node 150 is not equal to time T2 in data block 116.118, the data in the data block of client cash cannot be used. Client B must access server A via network 3, and must start two steps of cash access systems said from disk 2 to client cash 12B through Saba Cash 12A. When time T3 in substitute i node 150 is the same as time T2 in cash data block 116.118, Data can be directly accessed from client cash 12B, without process 231-23N in client node B going away via network 3 (Step 139). In the file in ASYNC or READONLY synchronous mode, a client judges whether the data in specific Cash Brock is effective based on the above-mentioned steps. In order that a client can issue this judgment in the bottom, the last correction time over that file based on the clock of a server is included in each cash Brock's header. This last correction time is recorded on Cash Brock, when that Brock is read in a server, and when that file is closed at the end by that client node, it is updated. Since existing Cash Brock is reading, when being accessed (or for the writing to partial Brock), the correction time in the header is compared with the time in a substitute i node. When the time in a substitute i node is equal to the time in Cash Brock, it is an effect about the data in the Brock, and a client can use it, saving file system semantics. When the time in a substitute i node is not equal to the time in Cash Brock, the data in the Brock is invalid and a client cannot use it. A client sends the reading remote procedure call to the data block to a server. A desirable example can be summarized as follows. First, each substitute i node has the file correction time field. In the second, hula Yen = 57-A Cash Brock has the file correction time field. Only when Cash Brock's file correction time is equal to the file correction time of a substitute i node, client Cash Brock is effective in the third. When the file is not [ fourth ] open by a certain client node yet, shortly after being opened by the file by the client node, the client node On behalf of i node is created. Since there was a synchronous mode change demand from two servers when a substitute i node was created, since there was [ the fifth and ] an open demand from one server, When a client takes a synchronous mode change demand in Acceptance and it changes from the ASYNC mode to READONLY synchronous mode by the client node from a file, since closing was performed by 3 client node, Or since closing was performed by 4 client node, in which [ at the time of a file becoming less open at the client node ] case, the value in the file correction time field of a substitute i node is assigned. Although opening was performed by the client node therefore, when a substitute i node is not created, please care about that the file correction time of a substitute j node is not changed. This is because the file is already open by the client node. It should care about that the conditions of corresponding to opening of the file for writing of each closing of a file may be used instead of the above-mentioned conditions 3 and 4. The value which the server sent in the closing acknowledgment which is requiring the synchronous mode change of the open demand of above 1 or above 2, or is returned to a client from a server by above 3 or 4 is assigned to the file correction time of a substitute i node. This value is the time which the server measured and when the file was corrected at the end. When it is assigned [ the sixth and ] for data reading from one server, or the writing to the file by the process of a client, Or when the closing corresponding to the situation of 2 above 3 or 4 is performed, the value which has client Cash Brock to a certain file in the file correction time field is assigned. This value assigned to Cash Brock's file correction time field is a value in the file correction time field of a client substitute i node. Please care about that the file correction time field of Cash Brock and a substitute i node becomes equal just behind the above-mentioned conditions by which a value is assigned to Cash Brock's file correction time field. The system and method which were explained above carry out buffer storage of the file to a client node from a server process system using the client cash in a client processing system. In a desirable example, the validity of the data block in client cash is judged with a client processing system using the time which measured with the server clock and was recorded on the server. However, if it is a person skilled in the art, the validity of the data block in client cash can also be judged by a server process system in another example so that he can understand. However, in the example of others which pursue the validity of the data block of a client using a server, the resources of a server more important than the resources of a client will be used. The data block in the client cash which the server is pursuing may not exist any longer in client cash. The effect of F0 invention If the present invention is used, when accessing a remote file in a network, a network traffic overhead can be reduced, maintaining the compatibility of a file.

[Brief Description of the Drawings]

Drawing 1 is -'. It is a schematic diagram showing three sets of the processing systems connected within networking environment. Drawing 2 is a schematic diagram of the stand-alone processing system which used the well-known kernel buffer with this art. Drawing 3 is a flow chart of reading to the kernel buffer in the stand-alone system of common knowledge with this art. Drawing 4 is a schematic diagram showing three sets of the distributed processing systems provided with client cash and Saba Cash connected in the network so that a file could be accessed via a network. Drawing 5 is a schematic diagram of a client node and a server node provided with the client cash and Saba Cash who are in READONLY synchronous mode or ASYNC synchronous mode, respectively. Drawing 6 is an explanatory view in three sorts of synchronous modes used in order to manage use of client cash and Saba Cash within distributed networking environment. Drawing 7 is the opinion neighborhood which shows shift between three sorts of synchronous modes. Drawing 8 is a schematic diagram showing the place where the client has accessed the file in the server node in the FULLSYNCs-mode. Drawing 9 is a flow chart which shows each step under reading in case client cash is not used, when client cash is used. Drawing 10 is a schematic diagram which has a substitute i node and a time bit for client cash to judge the validity of the data in a cash data block in the Cash Brock and in which showing distributed networking environment. Drawing 11 is a flow chart which shows each step of the present invention under opening of the file which a client mate has, reading, and closing. A .... A server node, BlC .... Client node, 2 .... disk, 3 .... network, 4 .... application program, 5 .... file, 10 .... processing system, 11 .... operating system, 12 .... local cash, 13.131-13N, and 231-23N .... A local process, 14 .... User address space. Applicant International Business Machines corporation Representative Patent attorney Takashi Shikomiya - (besides one person)