DE3889739T2

DE3889739T2 - Anordnung und Verfahren zur Benutzung der Cachespeicherdaten in einem Ortsnetzknoten nach der Neuöffnung einer Datei eines entfernten Knoten in einem verteilten Netz.

Info

Publication number: DE3889739T2
Application number: DE3889739T
Authority: DE
Inventors: Albert Chang; Grover Herbert Neuman; Amal Ahmed Shaheen-Gouda; Todd Allen Smith
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1987-02-13
Filing date: 1988-01-26
Publication date: 1994-12-01
Anticipated expiration: 2008-01-27
Also published as: JPH0561662B2; US4897781A; JPS63201845A; BR8800246A; EP0278317A3; DE3889739D1; EP0278317B1; EP0278317A2

Description

Diese Erfindung bezieht sich auf Verarbeitungssysteme, die durch ein Netz verbunden sind, und insbesondere auf das Zugreifen von Dateien zwischen lokalen und entfernten Verarbeitungssystemen in einem verteilten Netz.
Wie Fig. 1 zeigt, besteht ein verteiltes Netz 1 aus zwei oder mehreren Knoten A, B, C, die über einen DFV-Verbindungsweg oder ein Netz 3 verbunden sind. Das Netz 3 kann entweder ein Lokalnetz (LAN) oder ein Weitverkehrsnetz (WAN) sein. Letzteres besteht aus Verbindungen zur Datenfernverarbeitung (TP), die zu anderen Knoten oder zu einer Systemnetzwerkarchitektur (SNA) vermittelt werden oder festgeschaltet sind.
In jedem der Knoten A, B, C, kann ein Verarbeitungssystem 10A, 10B, 10C vorhanden sein, wie zum Beispiel ein Personal-Computer. Jedes dieser Verarbeitungssysteme 10A, 10B, 10C kann ein Einzelplatz- oder ein Mehrplatzsystem sein, das fähig ist, Netz 3 zum Zugriff auf Dateien in einem entfernten Knoten zu verwenden. Das Verarbeitungssystem 10A im lokalen Knoten A ist zum Beispiel in der Lage, auf die Dateien 5B, 5C in den entfernten Knoten B, C zuzugreifen.
Die beim Zugriff auf eine Datei in einem entfernten Knoten auftretenden Probleme können besser verstanden werden, denn zuerst untersucht wird, wie ein selbständiges System auf Dateien zugreift. In einem selbständigen System, wie dem in Fig. 2 abgebildeten System 10, wird ein lokaler Puffer 12 in dem Betriebssystem 11 verwendet, um die zwischen dem Dauerspeicher 2, zum Beispiel eine Hartdatei oder eine Festplatte in einem Personal-Computer, und dem Benutzeradreßbereich 14 übertragenen Daten zwischenzuspeichern. Der lokale Puffer 12 in dem Betriebssystem 11 wird auch lokaler Cache- oder Kern-Puffer genannt.
In dem selbständigen System wird der Kern-Puffer 12 durch die Blöcke 15 identifiziert, die als Gerätenummer bezeichnet werden, und durch die logische Blocknummer im Gerät. Wenn ein Lesesystemaufruf 16 ausgegeben wird, wird dieser mit einer Dateibeschreibung von Datei 5 und einem Bytebereich Innerhalb von Datei 5 ausgegeben, wie Schritt 101 in Fig. 3 zeigt. Das Betriebssystem 11 nimmt diese Information und konvertiert diese in die Gerätenummer und die logischen Blocknummern in dem Gerät, Schritt 102, Fig. 3. Dann liest das Betriebssystem 11 den Cache-Speicher 12 nach der Gerätenummer und den logischen Blocknummern, Schritt 103.
Die von der Platte 2 gelesenen Daten verbleiben in dem Cache- Speicher-Block 15, bis der Cache-Speicher-Block 15 benötigt wird. Demzufolge erfolgt der Zugriff auf jede nachfolgende Leseanforderung aus einer Anwendung 4, die in dem Verarbeitungssystem 10 für die gleichen, zuvor gelesenen Daten läuft von dem Cache-Speicher 12 und nicht von der Platte 2 aus. Das Lesen aus dem Cache-Speicher ist weniger zeitaufwendig als zur Festplatte 2 herauszugehen, auf die richtigen Plattensektoren zuzugreifen und von der Platte zu lesen.
Ebenso werden aus der Anwendung 4 geschriebene Daten nicht sofort auf der Platte 2 gesichert, sondern in den Cache-Speicher 12 geschrieben. Dieser sichert Plattenzugriffe, wenn eine weitere Schreiboperation an den gleichen Block ausgegeben wird.
Geänderte Datenblöcke im Cache-Speicher 12 werden regelmäßig auf Platte 2 gesichert.
Eine weitere Verwendung des lokalen Cache-Speichers in einem selbständigen System ist, gültige Daten für eine Datei zu behalten, auch nachdem diese geschlossen wurde. Wenn die Datei neu geöffnet wird, während diese Blöcke noch in dem Cache- Speicher vorhanden sind, dann ist kein Plattenzugriff zum Lesen der Blöcke erforderlich.
Die Verwendung eines Cache-Speichers in einem selbständigen System, das ein AIX¹ (Advanced Interactive Executive) Betriebssystem benutzt, verbessert die Gesamtleistung des Systems, da der Plattenzugriff bei aufeinanderfolgenden Lese- und Schreiboperationen entfällt. Die Gesamtleistung wird gesteigert, da der Zugriff auf den Dauerspeicher langsamen und aufwendiger als der Zugriff auf einen Cache-Speicher ist.
In einem verteilten Netz, wie das in Fig. 1, gibt es für das Verarbeitungssystem 10C in dem Ortsnetzknoten C zwei Möglichkeiten, die Datei 5A aus dem Knoten A zu lesen. Eine davon ist, daß das Verarbeitungssystem 10C die gesamte Datei 5A kopiert und diese anschließend liest, als wäre es eine lokale Datei 5C, die sich in Knoten C befindet. Eine Datei auf diese Weise zu lesen, verursacht ein Problem, wenn ein anderem Verarbeitungssystem 10B, 10A in einem anderen Knoten A, in B die Datei 5A ändert, nachdem die Datei 5A in Knoten C kopiert wurde. Das Verarbeitungssystem 10C hat auf diese jüngsten Änderungen in Datei 5A keinen Zugriff.
¹AIX ist ein Warenzeichen der IBM Corporation.
Eine weitere Möglichkeit für das Verarbeitungssystem 10C auf eine Datei 5A in Knoten A zuzugreifen, ist, einen Block N1 zu einem Zeitpunkt zu lesen, zu dem das Verarbeitungssystem in Knoten C dies verlangt. Ein Problem bei diesem Verfahren ist, daß jede Leseoperation durch den DFV-Netzverbindungsweg 3 zu Knoten A gehen muß, wo sich die Datei befindet. Das Senden von Daten für jeden nachfolgenden Lesevorgang ist zeitaufwendig.
Der Zugriff auf Dateien durch ein Netz stellt, wie oben geschildert, zwei konkurrierende Probleme dar. Ein Problen liegt in der Zeit, die erforderlich ist, bei aufeinanderfolgerden Lese- und Schreiboperationen Daten durch das Netz zu übertragen. Wenn andererseits die Dateidaten in dem Knoten gespeichert werden, um den Netzverkehr zu reduzieren, kann die Vollständigkeit der Datei verlorengehen. Wenn zum Beispiel einer der verschiedenen Knoten auch in die Datei schreibt, können die anderen Knoten, die auf die Datei zugreifen, nicht auf die zuletzt aktualisierte Datei zugreifen, die gerade geschrieben wurde. Im Grunde genommen, geht die Vollständigkeit der Datei verloren, da ein Knoten auf inkorrekte und überholte Dateien zugreift.
Innerhalb dieses Dokuments wird der Begriff "Server" zur Angabe des Knotens verwendet, in dem die Datei ständig gespeichert ist, wobei der Begriff "Client" zur Bezeichnung des anderen Knotens mit Verarbeitungen verwendet wird, die auf die Datei zugreifen. Es muß jedoch klar sein, daß der Begriff "Server" nicht einen dedizierten Server meint, wie der Begriff in einigen Lokalnetzsystemen verwendet wird. Das verteilte Servicesystem, in dem die Erfindung realisiert wird, ist ein tatsächlich verteiltes System, das eine große Vielfalt von Anwendungen unterstützt, die in verschiedenen Knoten in dem System laufen, die auf Dateien zugreifen können, die sich irgendwo in dem System befinden.
"Caching Hints in Distributed Systems," IEEE Transactions on Software Engineering, Vol. SE-13, No.1, January 1987, pages 48-54, beschreibt ein System zum Zugriff auf eine Datei in einem Server-Verarbeitungssystem zur Benutzung durch ein Client- Verarbeitungssystem in einem Client-Knoten. Zur Zwischenspeicherung der Blöcke von der Datei in dem Client-Knoten aus dem Server-Verarbeitungssystem enthält das System einen Client- Cache-Speicher in dem Client-Verarbeitungssystem. Das Client- Verarbeitungssystem bestimmt die Gültigkeit des Blocks in dem Client-Cache-Speicher als eine Funktion von einer Zeit in dem Server-Verarbeitungssystem. Auf die Blöcke von der Datei in dem Client-Cache-Speicher wird zugegriffen, wenn diese als gültig anerkannt wurden. Auf die Datei jedoch wird aus dem Server-Verarbeitungssystem zugegriffen, wenn die Blöcke als ungültig anerkannt wurden. Die Blöcke von der Datei in dem Client-Cache-Speicher werden jedesmal weggeworfen, wenn die Blöcke als ungültig anerkannt wurden.
Die nachstehend beschriebene Erfindung wurde in einer Version des UNIX* Betriebssystems realisiert, sie kann jedoch in anderen Betriebssystemen verwendet werden, wenn deren Charakteristika ähnlich wie die des UNIX Betriebssystems sind.
Das UNIX Betriebssystem wurde von den Bell Telephone Laboratories, Inc., zur Benutzung in einem Digital Equipment Corporation (DEC) Minicomputer entwickelt, wurde jedoch für eine breite Palette von Minicomputern und seit kurzem auch von Mikrocomputern zu einem beliebten Betriebssystem. Ein Grund
* Von AT&T entwickelt und lizenziert. UNIX ist ein eingetragenes Warenzeichen von AT&T in den USA und anderen Ländern. für diese Beliebtheit ist vielmehr, daß das UNIX Betriebssystem in der C Programmiersprache geschrieben ist, die ebenfalls in den Bell Telephone Laboratories entwickelt wurde, als in der Assembliersprache, so daß es nicht prozessorspezfisch ist. Auf diese Weise ermöglichen es die Kompilierer, die für zahlreiche Computer geschrieben wurden, diesen C Leistungsfähigkeit zu geben, um das UNIX Betriebssystem von einem zum anderen Computer zu transportieren. Deshalb sind die für die UNIX Betriebssystemumgebung geschriebenen Anwendungsprogramme ebenfalls von einem zum anderen Gerät übertragbar. Für weitere Informationen zu dem UNIX Betriebssystem wird der Leser auf UNIX System, User's Manual, System V, verwiesen, das von Western Electric Co., im Januar 1983 herausgegeben wurde. Ein guter Überblick von dem UNIX Betriebssystem wird von Brian W. Kernighan und Rob Pike in ihrem Buch mit dem Titel The Unix Programming Environment gegeben, das von Prentice-Hall (1984) herausgegeben wurde. Eine ausführlichere Beschreibung von dem Design des UNIX Betriebssystems findet sich in einem Buch von Maurice J. Bach, Design of the Unix Operating System, das von Prentice-Hall (1986) herausgegeben wurde.
AT&T Bell Labs hat eine Anzahl von Teilnehmern für die Benutzung des UNIX Betriebssystems lizenziert, und es sind nun mehrere Versionen verfügbar. Die gängigste Version von AT&T ist die Version 5.2. Eine weitere Version, als Berkeley Version des UNIX Betriebssystems bekannt geworden, wurde von der Universität von Kalifornien in Berkeley entwickelt. Microsoft, der Herausgeber der beliebten MS-DOS und PC-DOS Betriebssysteme für Personal-Computer, hat eine Version, die unter ihrem Warenzeichen XENIX bekannt wurde.
Mit der Ankündigung des IBM RT PC³ (RISC (reduced instruction set computer = Computer mit reduziertem Befehlsvorrat) Technology Personal Computer)) in 1985 brachte die IBM Corp. ein neues Betriebssystem, AIX, auf den Markt, das in der Ebene der Anwendungsschnittstelle kompatibel mit dem UNIX Betriebssystem, Version 5.2, von AT&T ist und Erweiterungen in dem UNIX Betriebssystem, Version 5.2 enthält. Für eine ausführlichere Beschreibung des AIX Betriebssystems wird der Leser an AIX Operating System Technical Reference verwiesen, das von der IBM Corp., Erstausgabe (Nov. 1985), herausgegeben wurde.
Die Erfindung befaßt sich insbesondere mit verteilten Datenverarbeitungssystemen, die durch eine Vielzahl von Prozessoren gekennzeichnet werden, die in einem Netz verbunden sind. Wie tatsächlich realisiert, läuft die Erfindung in einer Vielzahl von RT PC's von IBM, die mit einer Systemnetzwerkarchitektur (SNA) von IBM, und insbesondere mit der SNA LU 6.2 Advanced Programm to Programm Communication (APPC) verbunden sind. An Introduction To Advanced-Program-To-Program Communication (APPC), Technical Bulletin by IBM International Systems Centers, July 1983, number GG24-1584-0, und IBM RT PC SNA Access Method Guide and Reference, August 15, 1986, sind zwei Schriften, die die SNA LU 6.2 ausführlicher beschreiben.
³RT und RT PC sind Warenzeichen der IBM Corporation.
Die SNA benutzt für ihre Verbindungsebene Ethernet&sup4;, ein Lokalnetz (LAN), das von der Xerox Corp. entwickelt wurde, oder die SDLC (Synchronous Data Link Control = Synchrone Datenübertragungssteuerung). Eine vereinfachte Beschreibung der Lokalnetze einschließlich der des Ethernet Lokalnetzes finden sich in einem Buch von Larry E. Jordan und Bruce Churchill mit dem Titel Communications and Networking for the IBM PC, das von Robert J. Brady (einer Prentice-Hall Gesellschaft) (1983) herausgegeben wurde. Eine eindeutigere Beschreibung von Konmunikationssystemen für Computer, insbesondere der SNA und SDLC, findet sich in einem Buch von R.J. Cypser mit dem Titel Communications Architecture for Distributed Systems, das von Addison-Wesley (1978) veröffentlicht wurde. Es sollte jedoch klar sein, daß die Erfindung in anderen Computern als in den RT PC's von IBM realisiert werden kann, die mit anderen Netzen als dem Ethernet Lokalnetz oder der SNA von IBM verbunden sind.
Wie erwähnt, richtet sich die nachstehend beschriebene Erfindung an ein verteiltes Datenverarbeitungssystem in einem DFV- Netz. in dieser Umgebung kann jeder Prozessor in einem Knoten in dem Netz potentiell auf alle Dateien in dem Netz zugreifen, wobei unwichtig ist, in welchem Knoten die Dateien sind.
Andere Annäherungen, ein verteiltes Datenverarbeitungssystem in einer UNIX Betriebssystemumgebung zu unterstützen, sind bekannt. Sun Microsystems hat zum Beispiel ein Network File System (NFS) auf den Markt gebracht und Bell Laboratories hat
&sup4;Ethernet ist ein Warenzeichen der Xerox Corporation. ein Remote File System (RFS) entwickelt. Das NFS von Sun Microsystems wurde in einer Reihe von Veröffentlichungen beschrieben, zu denen die von S.R. Kleiman, "Vnodes: An Architecture for Multiple File System Types in Sun UNIX", Conference Proceedings" USENIX 1986 Summer Technical Conference and Exhibition, pp. 238 to 247; Russel Sandberg et al., "Design and Implementation of the Sun Network Filesystem", Conference Proceedings, Usenix 1985,, pp. 119 to 130; Dan Walsh et al., "Overview of the Sun Network File System", pp. 117 to 124; JoMei Chang, "Status Monitor Provides Network Locking Service for NFS"; JoMei Chang, "SunNet", pp. 71 to 75; and Bradley Taylor, "Secure Networking in the Sun Environment", pp. 28 to 36 gehören. Das RFS von AT&T wurde ebenfalls in einer Reihe von Veröffentlichungen beschrieben, zu denen die von Andrew P. Rifkin et al., "RFS Architectural Overview", USENIX Conference Proceedings, Atlanta, Georgia (June 1986), pp. 1 to 12; Richard Hamilton et al., "An Administrator's View of Remote File Sharing", pp. 1 to 9; Tom Houghton et al., "File Systems Switch", pp. 1 to 2; and David J. Olander et al., "A Framework for Networking in System V", pp. 1 to 8 gehören.
Ein Merkmal des verteilten Servicesystems, in dem die betreffende Erfindung realisiert wurde, das sich zum Beispiel von dem NFS von Sun Microsystems unterscheidet, ist, daß die Annäherung von Sun darin bestand, einen im wesentlichen statuslosen Computer zu entwerfen. Genauer gesagt, kann der Server in einem verteilten System so konzipiert werden, daß diesem statuslos ist. Dies bedeutet, daß der Server keinerlei Informationen über Client-Knoten, einschließlich Informationen darüber speichert, welche Client-Knoten eine Server-Datei geöffnet haben, ob Client-Verarbeitungen eine Datei in read_only oder read_write Modi geöffnet haben, oder ob ein Client Sperren in Byte-Bereichen der Datei plaziert hat. Solch eine Realisierung vereinfacht das Design des Servers, da der Server sich nicht mit der Fehlerbehebung befassen muß, die bei Ausfall oder Off-Line-Zustand eines Clients auftreten kann, ohne den Server richtig zu informieren, damit er seinen Anspruch auf die Server-Betriebsmittel freigibt.
Eine ganz andere Annäherung wurde bei dem Design des verteilten Servicesystems durchgeführt, in dem die vorliegende Erfindung realisiert wurde. Genauer gesagt, kann das verteilte Servicesystem als eine "statusreiche Realisierung" bezeichiet werden Ein "Statusreicher" Server, z.B. der hier beschrieben ist, behält Informationen darüber, wer seine Dateien benutzt und wie die Dateien benutzt werden. Dies erfordert, daß der Server die Möglichkeit hat, den Kontaktverlust bei einen Client zu erkennen, so daß die gesammelte Statusinformation über diesen Client weggeworfen werden kann. Die hier beschriebenen Strategien der Cache-Speicher-Verwaltung können jedoch nicht realisiert werden, es sei denn, der Server behält die Statusinformation. Die Cache-Speicher-Verwaltung wird, wie nachstehend beschrieben, durch die Anzahl von Client-Knoten beeinflußt, welche Anforderungen zum Öffnen einer Server-Datei und die Lese-/Schreib-Modi von den Eröffnungen ausgegeben haben.
Es ist deshalb ein Gegenstand dieser Erfindung, die Reaktionszeit beim Zugriff auf entfernte Dateien zu verbessern.
Es ist ein weiterer Gegenstand dieser Erfindung, die Vollständigkeit von Dateien in einem verteilten Netz beizubehalten.
Es ist ein weiterer Gegenstand, einen Cache-Speicher sowohl in Server- als auch in Client-Knoten zu benutzen, um gültige Daten zu behalten, wenn eine Datei in dem Client-Knoten geschlossen wird.
Ein System zum Zugriff auf eine Datei in einem Server-Verarbeitungssystem in einem Server-Knoten zur Verwendung in einem Client-Verarbeitungssystem in einem Client-Knoten (B), wobei das System enthält:
einen Client-Cache-Speicher in dem Client-Verarbeitungssystem zur Zwischenspeicherung einer Vielzahl von Blöcken der Datei in dem Client-Knoten (B) aus dem Server-Verarbeitungssystem, wobei das Client-Verarbeitungssystem die Gültigkeit der Blöcke in dem Client-Cache-Speicher als eine Funktion von einer Zeit in dem Server-Verarbeitungssystem festlegt, auf die Blöcke der Datei in dem Client- Cache-Speicher zugegriffen wird, wenn die Blöcke als gültig anerkannt wurden, wobei auf die Datei aus dem Server- Verarbeitungssystem zugegriffen wird, wenn die Blöcke als ungültig anerkannt wurden, die Blöcke der Datei in dem Client-Cache-Speicher jedesmal weggeworfen werden, wenn die Blöcke als ungültig anerkannt wurden;
dadurch gekennzeichnet, daß das System außerdem enthält;
Mittel zum Schreiben der Zeit einer letzten Änderung in die Datei in dem Server-Verarbeitungssystem, und zwar jedesmal, wenn die Datei aktualisiert wird;
eine Vielzahl von Cache-Datenblöcken in dem der Datei zugeordneten Client-Cache-Speicher, wobei jeder der Datenblöcke die Zeit der letzten Änderung enthält, die in die Datei in dem Server-Verarbeitungssystem geschrieben wurde, wenn die Datei in dem Client-Verarbeitungssystem geschlossen wird;
einen Cache-Block in dem Client-Cache-Speicher mit der Zeit der letzten Änderung, die in die Datei in dem Server- Verarbeitungssystem zugleich mit einer ersten Öffnung der Datei in der Client-Verarbeitung geschrieben wurde;
Mittel zum Vergleichen der Zeit der letzten Änderung, die in dem Client-Verarbeitungssystem bei der ersten Öffnung zu der Zeit der letzten Änderung in dem zugeteilten Cache- Block aufgezeichnet wurde;
Mittel zum Zugriff auf Daten aus dem Client-Cache-Speicher des Client-Verarbeitungssystems, wenn die in dem Client- Verarbeitungssystem bei der ersten Öffnung aufgezeichnete Zeit gleich mit der Zeit in dem Cache-Block ist, und
Mittel zum Zugriff auf die Datei aus dem Server-Verarbeitungssystem, wenn die in dem Client-Verarbeitungssystem bei der ersten Öffnung aufgezeichnete Zeit nicht gleich mit der Zeit in dem Cache-Block ist.
Um die Netzverkehrsorganisation zu reduzieren, wenn auf Dateien in anderen Knoten zugegriffen wird, und um die Vollständigkeit von Dateien beizubehalten, wird der Zugriff auf die zahlreichen Dateien in einem verteilten Netz durch Dateisychronisierungsmodi gesteuert. Einer Datei wird ein erster Synchronisierungsmodus gegeben, wenn eine Datei in nur einem Knoten geöffnet wird, um darauf entweder zum Lesen oder zum Schreiben zuzugreifen. Einer Datei wird ein zweiter Synchronisierungsmodus gegeben, wenn eine Datei in einem Knoten geöffnet wird, um darauf nur zum Lesen zuzugreifen. Einer Datei wird ein dritter Synchronisierungsmodus gegeben, wenn dit Datei in mehr als einem Knoten geöffnet wird, um darauf zum Lesen zuzugreifen und mindestens ein Knoten die Datei geöffnet hat, um zum Schreiben darauf zuzugreifen.
Wenn sich eine Datei entweder in dem ersten oder zweiten Synchronisierungsmodus befindet, benutzt der Client-Knoten und zwar der Knoten, der auf die Datei zugreift, in seinem Betriebssystem einen Cache-Speicher, um die Datei zu speichern. Alle Lese- und Schreiboperationen werden anschließend an diesen Cache-Speicher gesendet.
System und Verfahren dieser Erfindung benutzen sowohl in den Client- als auch in den Server-Knoten einen Cache-Speicher, um bei Schließen der Datei in dem Client-Knoten die gültigen Daten zu behalten. Ob der Client-Knoten den Client-Cache-Speicher wieder benutzt oder nicht, hängt davon ab, ob die Daten in dem Client-Cache-Speicher in einem anderen Knoten während der Zeit, in der die Datendatei in dem Client-Knoten geschlossen war, verändert wurden oder nicht. Wenn die Daten nicht verändert wurden, kann auf den Client-Cache-Speicher zum Lesen und Schreiben von Verarbeitungen in dem Client-Knoten zugegriffen werden, ohne daß die Vollständigkeit der Datei verlorengeht. Alle Daten in dem Client-Cache-Speicher sind gültige Daten. Wird der Client-Cache-Speicher zum Zugriff auf eine geöffnete Datei benutzt, nachdem diese einmal geschlossen wurde, wird die Netzverkehrsorganisation reduziert, und die Reaktionszeit bei Lese- und Schreiboperationen wird verringert, was zur Verbesserung der Reaktionszeit führt.
Um festzustellen, ob die Daten in dem Client-Cache-Speicher in einem anderen Knoten verändert wurden oder nicht, während die Datei in dem Client-Knoten geschlossen war, enthält das System dieser Erfindung einen Surrogat-Knoten in dem Client-Cache- Speicher. Der Surrogat-Knoten enthält ein Feld, das den Server-Knoten identifiziert, sowie eine Dateihandhabung, die die Datei in diesem Knoten identifiziert. Ein Surrogat-Knoten wird in dem Client-Cache-Speicher erstellt, jedesmal wenn die Datei erstmalig in einem Knoten geöffnet wird, oder nach einem letzten Schliessen erstmals geöffnet wird. Die Zeit der letzten Änderung der Datei, wie diese von der Uhr des Servers aufgezeichnet wurde, wird in den Surrogat-Knoten geschrieben, jedesmal wenn ein Surrogat-Knoten erstellt wird. Das System dieser Erfindung enthält auch ein Dateifeld zur Änderung der Zeit in den Cache-Datenblöcken, das die Zeit der letzten Änderung der Datei in dem Server angibt. Das Dateifeld zur Änderung der Uhrzeit in den Cache-Datenblöcken wird bei dem letzten Schließen der Datei in dem Client-Knoten aktualisiert.
Zum Öffnen, Lesen und Schließen einer Datei in einem Client- Knoten enthält das Verfahren dieser Erfindung die folgenden Schritte.
Wenn der Befehl zum Öffnen einer Datei in einem Client-Knoten ausgegeben wird, wird die Sorrogat-Knoten-Tabelle in dem Client-Verarbeitungssystem auf einen vorhandenen Surrogat-Knoten abgetastet. Wenn keiner vorhanden ist, dann wird ein neuer Surrogat-Knoten zugeteilt und ein Aufruf zur Eröffnung einer Fernverarbeitung wird an den Server gesendet. Wenn die Eröffnung in dem Server beendet ist, enthält die Eröffnungsbestätigung von dem Server an den Client die Zeit der letzten Änderung von der Datei. Diese Zeit wird in dem neu zugeteilten Surrogat-Knoten für die Datei in dem Client-Knoten aufgezeichnet.
Wenn neue Datenblöcke aus der Datei gelesen werden, wird dem Client-Cache-Speicher ein neuer Cache-Block zugeteilt. Jeder Cache-Block enthält den Namen des Server-Knotens, die Dateihandhabung und die Zeit der letzten Änderung von dem Surrogat- Knoten.
Wenn die Datei zum zweiten Mal oder in der Folge geöffnet wird, und die Surrogat-Knoten-Tabelle in dem Client-Verarbeitungssystem auf einen vorhandenen Surrogat-Knoten abgetastet wird, wird ein Surrogat-Knoten bereits aus einer früheren Eröffnung vorhanden sein. in diesem Fall gibt es keine Veänderung in der Zeit der Änderung oder in dem Surrogat-Knoten. Die Zeit der letzten Änderung in den Datenblöcken wird auch nicht bei einer zweiten Eröffnung verändert.
Während dem letzten Schließen einer Datei, die im ASYNCH Modus ist, kommen die folgenden Schritte vor. Zuerst sendet der Client eine Schließung an den Server. Dann, nach Erhalt der Aufforderung zum Schließen von dem Client, sendet der Server eine Bestätigung der Schließung an den Client. Mit der Schliessungsbestätigung sendet der Server die Zeit, zu der die Datei im Client zuletzt geändert wurde. Der Server muß zu der Platte in dem Server gehen, um die Zeit dieser letzten Änderung zu erhalten. Der Client gibt dann den Surrogat-Knoten frei und tastet alle entfernten Cache-puffer auf Blöcke ab, die den Namen des Server-Knotens und die Dateihandhabung von der soeben geschlossenen Datei haben. Der Client ändert dann alle Zeiten der letzten Änderungen in den entsprechender Cache-Blöcken in diejenige, die von dem Server zusammen mit der Bestätigung von der Schließung empfangen wurde.
Jedesmal wenn ein Block aus dem Client-Cache-Speicher gelesen wird, wird die Zeit in dem Surrogat-Knoten mit der Zeit in dem Cache-Datenblock verglichen. Eine Zeit in dem Surrogat-Knoten, die größer als die Zeit in den Cache-Datenblöcke ist, gibt an, daß die Daten in dem Client-Cache-Speicher geändert wurden, während die Datendatei in dem Client-Knoten geschlossen wurde. In diesem Fall muß der Client-Knoten über das Netz zum Server gehen, um die zuletzt geänderten Daten zu erhalten. Damit die Vollständigkeit der Datei erhalten bleibt, müssen alle Datenblöcke für die Datei in dem Client-Cache-Speicher ungültig gemacht werden.
Eine Zeit in dem Surrogat-Knoten, die gleich ist mit der, die in den Cache-Datenblöcken aufgezeichnet wurde, gibt an, daß die Daten in dem Client-Cache-Speicher noch gültig sind. Kein anderer Knoten hat diese Daten geändert, während die Datei in dem Client-Knoten geschlossen wurde. In diesem Fall können Verarbeitungen in dem Client-Knoten den Datenblock in dem Client-Cache-Speicher benutzen, ohne durch das Netz zu dem Server gehen zu müssen, wo sich die Datei eigentlich befindet.
Die Erfindung, die in den beiliegenden Ansprüchen definiert ist, wird nachstehend im einzelnen mit Bezug auf die Zeichnungen beschrieben, von denen
Fig. 1 drei Verarbeitungssysteme zeigt, die in einem Netz verbunden sind, wie dies in der Technik bekannt ist.
Fig. 2 ein selbständiges Verarbeitungssystem mit einem Kernpuffer zeigt, wie dies in der Technik bekannt ist.
Fig. 3 ein Flußdiagramm von einer Leseoperation in dem Kernpuffer in einem selbständigen System zeigt, wie dies in der Technik bekannt ist.
Fig. 4 drei verteilte Verarbeitungssysteme zeigt, die in einem Netz verbunden sind, um auf Dateien durch das Netz mit Client- und Server-Cache- Speicher zuzugreifen.
Fig. 5 einen Client- und Server-Knoten mit Client- und Server-Cache-Speicher bzw. in READONLY oder ASYNC Synchronisierungsmodus zeigt.
Fig. 6 die drei Synchronisierungsmodi zeigt, die zur Steuerung der Benutzung von Client- und Server- Cache-Speicher in einem verteilten Netz benutzt werden.
Fig. 7 die Übergänge zwischen den drei Synchronisierungsmodi zeigt.
Fig. 8 den Zugriff eines Client auf eine Datei in dem Server ind FULLSYNC s_mode zeigt.
Fig. 9 die Schritte während einer Leseoperation zeigt, wenn ein Client-Cache-Speicher benutzt wird und wenn der Client-Cache-Speicher nicht benutzt wird.
Fig. 10 ein verteiltes Netz zeigt, wobei der Client- Cache-Speicher einen Surrogat-Knoten und Zeitbits in den Cache-Blöcken zur Festlegung der Gültigkeit von Daten in den Cache-Datenböcken hat.
Fig. 11 die Schritte der vorliegenden Erfindung beim Öffnen, Lesen und Schließen der Datei in dem Client-Knoten zeigt.
In der vorliegenden Erfindung, wie Fig. 4 zeigt, ist in jedem Knoten A, B, C ein lokaler Cache-Speicher 12A, 12B, 12C vorhanden. Wenn sich Datei 5 ständig in Knoten A auf Platte 2A befindet, wird Knoten A als Server bezeichnet. In dem Server A erfolgt die Benutzung des Cache-Speichers 12A durch lokale Verarbeitungen 13A, die in dem Server-Knoten ausgeführt werden, wie die in einem selbständigen System, das zuvor in dem Stand der Technik erörtert wurde.
Die Datenfernverarbeitungen 13B, 13C jedoch, die in den Knoten B, C ausgeführt werden, greifen auf die Datel 5 über ein zwei-Schritt-Cache-Schema zu, das einen Server-Cache-Speicher und einen Client-Cache-Speicher benutzt, wie dies deutlich in Fig. 5 gezeigt wird. Der Server-Knoten A erhält die Blöcke von Datei 5 von der Platte 2A und speichert diese in dem Server- Cache-Speicher 12A. Der Client-Knoten B geht über das Netz 3 heraus und erhält die Blöcke von Datei 5 aus dem Server-Cache- Speicher 12A. Der Client-Knoten B speichert die Blöcke von Datei 5, wie diese in dem Server-Cache-Speicher 12A in dem Client-Cache-Speicher 12B vorhanden sind. Wenn der Benutzeradreßbereich 14B des Client-Knotens B Daten aus Daten 5 im ASYNCH oder READONLY Synchronisierungsmodus sucht, wird auf den Client-Cache-Speicher 12B zugegriffen, anstatt für jeden Zugriff durch Netz 3 zu gehen. Wenn der Client-Cache-Speicher 12B benutzt wird, um auf eine entfernte Datei 5 zuzugreifen, so kann dies deutlich die Leistung verbessern, da dieser den Netzverkehr und die Organisation sichern kann.
Die Benutzung des Client-Cache-Speichers 12B und des Server- Cache-Speichers 12A wird in einer verteilten Umgebung gesteuert, um hohe Leistung zu vollbringen, während die Dateizugriffsemantik in der Anwendungsprogrammebene erhalten bleibt. Dies ermöglicht es vorhandenen Programmen, die in einem selbständigen System laufen, ohne irgendeine Änderung in einem verteilten System zu laufen.
Die Dateizugriffssemantik erhält die Vollständigkeit eäner Datei, wie diese von verschiedenen Verarbeitungen geöffnet wird, die Lese- und Schreibsystemaufrufe ausgeben, um auf die Datei zuzugreifen und diese zu veränden. Die Dateizugriffssemantik verlangt, daß nur eine E/A Operation in einem Bytebereich zu irgendeiner Zeit erlaubt wird, und sobald eine E/A Operation startet, kann diese nicht durch eine andere E/A Operation in dem gleichen Bytebereich der Datei belegt werden.
Ein Beispiel hierfür wird wieder mit Bezug auf Fig. 5 gegeben. Wenn die Verarbeitung 131 einen Schreibsystemaufruf an einen Bytebereich N1-N2 in Datei 5 ausgibt, kann der Schreibsystemaufruf nur ausgeführt werden, wenn der gesamte Bytebereich N1- N2 für den Zugriff durch die Verarbeitung 131 verfügbar ist, und keine Leseoperation innerhalb des Bytebereichs N1-N2 ausgeführt wird. Während der Ausführung des Schreibsystemaufrufs werden alle anderen Operationen innerhalb des Bytebereichs N1- N2 in Datei 5 bis zum Abschluß der Schreiboperation eingestellt. Die Schreiboperation ist nicht abgeschlossen, bis die Bytes in den lokalen Cache-Speicher 12A geschrieben sind. Wenn eine Schreibanforderung abgeschlossen ist, werden die in den Cache-Speicher 12A geschriebenen Daten in jeder nachfolgende Leseoperation durch eine der anderen Verarbeitungen 131 - 13N sichtbar.
Ein weitere Anforderung an die Dateizugriffssemantik ist, daß wenn ein Dateibytebereich, wie z.B. der N1-N2, der eine Aufzeichnung oder ein Satz von zusammengehörigen Aufzeichnungen sein kann, auf die mit der gleichen E/A Operation zugegriffen wird, in einer Leseverarbeitung sichtbar ist, muß der Dateibytebereich N1-N2 stets einen festen Satz von Daten haben, die die letzte Aktualisierung in diesem Bereich reflektierer. Während eine Schreiboperation ausgeführt wird, ist dieser Bereich nie verfügbar. Auf diese Weise wird die nächste Leseoperation, die von einer Verarbeitung ausgegeben wird, die gerade geschriebenen Daten und nicht die alten, überholten Daten lesen.
In einem verteilten Netz von dieser Erfindung, wie Fig. 5 zeigt, wird die Ausführung von Lese- und Schreibsystemaufrufen aus verschiedenen Anwendungsprogrammen 4A, 4B und die Verarbeitungen 131-13N, 231-23N synchronisiert, so daß die Dateizugriffssemantik, wie zuvor erörtert, erhalten bleibt. Die Synchronisierung wird durch Verwendung der verschiedenen Cache- Synchronisierungsmodi (sync) garantiert. Bei einer spezfischen Datei 5 werden die E/A Aufrufe entweder von dem C dient B oder dem Server A synchronisiert, was von der Speicherstelle der Verarbeitungen 131-13N, 231-23N abhängt, welche Datei 5 zum Zugriff und für den Synchronisierungsmodus geöffnet haben.
Die drei Synchronisierungsmodi sind in Fig. 6 abgebildet und mit Bezug auf Fig. 4 beschrieben. Der erste Modus 41 wild als ASYNCH S_mode oder asynchroner Modus bezeichnet. Datei 5 arbeitet in diesem Modus 41, wenn Datei 5 zum Lese- /Schreibzugriff von den Verarbeitungen 13C geöffnet wird, die nur einen entfernten Client-Knoten C ausführen, wie Block 44 in Fig. 6 zeigt. In diesem Modus 41 befindet sich die gesamte Steuerung in dem Client-Knoten C. Sowohl der Server-Cache- Speicher 12A als auch der Client-Cache-Speicher 12C werden für diese Lese-/Schreiboperationen benutzt. Eine Lese- oder Schreiboperation erfordert den Zugriff auf den Server-Cache- Speicher 12A nur, wenn dieser nicht von dem Client-Cache-Speicher 12C erfüllt werden kann. Geänderte Blöcke in dem Client 12C werden durch die regelmäßige Synchronisierungsoperation in den Server 12A geschrieben, oder wenn Datei 5 durch alle Verarbeitungen 13 C in dem Client-Knoten C geschlossen wird, oder wenn ein Block geschrieben werden muß, um Platz für andere Daten zu schaffen, die in den Cache-Speicher eingebracht werden. Außerdem werden geänderte Blöcke in den Server geschrieben, wenn die Datei von ASYNCH s_mode in FULLSYNC s_mode wechselt.
Ein zweiter Modus 42 ist der READONLY s_mode. Der READONLY s_mode 42 wird für Dateien 5 verwendet, die zum Nur-Lese-Zugriff von den Verarbeitungen 13C in nur einem Knoten C geöffnet wurden, oder von den Verarbeitungen 13B, 13C in mehr als einem Knoten B, C, wie in Block 45 in Fig. 6 gezeigt wird. In diesem Modus 42 werden der Server-Cache-Speicher 12A und der Client-Cache-Speicher 12B und/oder 12C benutzt. Die Leseanforderung wird zugleich für einen Block oder mehrere Blöcke ausgegeben. Jede weitere Leseanforderung von dem gleichen Client, entweder von B oder C, an den spezifischen Block geht nicht zu dem Server 12. Er wird stattdessen aus dem jeweiligen Cient- Cache-Speicher, entweder aus B oder C, gelesen. Mit anderen Worten, eine Leseoperation erfordert keinen Zugriff auf den Server 12A, wenn dieser von dem Client-Cache-Speicher 12C oder 12B erfüllt werden kann. Kurz zusammengefaßt: die Datei 5 arbeitet in Modus 42, wenn Datei 5 zum Nur-Lese-Zugriff von einer der Verarbeitungen 13A, 13B, 13C in einem der Knoter A, B, C geöffnet wird.
Ein dritter Modus 43 ist der FULLSYNCH s_mode. Der FULLSYNC s_mode wird verwendet, um Dateien 5 zum Schreibzugriff durch eine Verarbeitung 13A in dem Server-Knoten A zu öffnen, die Block 48 in Fig. 6 zeigt. Dieser Synchronisierungsmodus 43 wird auch verwendet, wenn Datei 5 in dem Server-Knoten A geöffnet wird und mindestens ein weiterer Knoten B, C und mindestens eine Verarbeitung 13A, 13B oder 13C Datei 5 zum Schreibzugriff geöffnet hat, wie die Blöcke 46, 47 in Fig. 6 zeigen. Im allgemeinen, wenn mehr als ein Knoten die Datei geöffnet hat und irgendeiner dieser Knoten die Datei zum Schreibzugriff geöffnet hat, befindet sich die Datei in FULLSYNC s_mode. In dem FULLSYNC s_mode 43 wird der Client-Cache-Speicher 12C oder 12B umgangen und nur der Server-Cache-Speicher 12A wird benutzt. Alle Lese- und Schreiboperationen werden in dem Server 12A ausgeführt.
In einer verteilten Umgebung 1, Fig. 4, werden die meisten Dateien 5 häufiger für Nur-Lese-Operationen von den Verarbeitungen 13A, 13B, 13C in den einzelnen Knoten A, B, C im READONLY s_mode 42, Fig. 6, geöffnet oder zur Aktualisierung in nur einem Knoten im Asynchronous s_mode 41, Fig. 6, geöffnet. Es ist weniger häufig, daß es ein Öffnen zum Lese- und Schreibzugriff von Verarbeitungen gibt, die in mehr als einem Knoten in dem Fullsync s_mode 43, Fig. 6, ausgeführt werden. Sowohl im READONLY s_mode 42, Fig. 6, als auch im ASYNCH s_mode 41, Fig. 6, reduziert die Benutzung eines Client-Cache-Speichers 12B, Fig. 5, deutlich die Reaktionszeit von entfernten Lese- /Schreibvorgängen bei Zugriff auf Datei 5 und verbessert die Leistung des gesamten Systems.
Wie Fig. 8 im FULLSYNC s_mode zeigt, wird der Client-Cache- Speicher nicht benutzt. Der Client-Knoten B greift für jeden Lese- und Schreibvorgang aus Server A über Netz 3 auf Datei 5 zu. Obwohl die Reaktionszeit bei Lese-/Schreibvorgänge in diesem Modus ansteigt, bleibt die Dateizugriffssemantik erhalten, da ein Client in einem lokalen Cache-Speicher eine Datei 5 nicht behält, die nicht zusammen mit der entsprechenden Datei aktualisiert wurde, die sich im Server befindet.
Die Verwendung der drei Modi zur Steuerung der Benutzung des Client-Cache-Speichers optimiert die Leistung des gesamten Systems, indem beide, ein durchschnittlicher Gesamtanstieg in der Reaktionsgeschwindigkeit bei Lese-/Schreibvorgängen mit der Vollständigkeit der Datei kombiniert werden. Wenn in einigen Situationen ein Client-Cache-Speicher benutzt wird, fällt die Reaktionszeit bei Lese-/Schreibvorgängen ab; währenddessen bei Nichtbenutzung eines Client-Cache-Speichers in anderen Situationen die Dateisystemsemantik erhalten bleibt.
Der Synchronisierungsmodus einer Datei hängt nicht nur davon ab, welche Knoten die Datei geöffnet haben, und ob die Datei zum Lesen oder Schreiben geöffnet wurde, sondern auch davon, ob die Einheit, in dem sich die Datei befindet, im Ursprungszugriffsmodus geöffnet wird. Ursprungszugriff auf eine Einheit bedeutet, daß auf ein Block mit Daten LBN1, Fig.5, in einer Einheit 2A zugegriffen wird. Auf diese Weise werden die Lese- und Schreiboperationen von Einheit 2A in einen Block LBN1 von Einheit 2A gelesen und geschrieben. Es ist nicht relevant, zu welcher Datei der Block gehört. Die Einheit 2A kann zum Ursprungszugriff von einer Verarbeitung 131-13N im Server-Knoten A geöffnet werden. Für den Ursprungszugriff kann sie nicht von einem entfernten Knoten B, C, geöffnet werden.
Mit Bezug auf Fig. 5 wird der Cache-Speicher 12A wie die Blöcke LBN1 von einer Einheit 2A gesteuert, die ähnlich einem selbständigen System ist, das oben mit Bezug auf Fig. 2 beschrieben wurde. Server A sieht den Server-Cache-Speicher 12A als einen logischen Block LBN1 in einer Einheit 2A an. Client B hat keine Kenntnis darüber, wo sich Datei 5 in der Einheit 2A befindet. Client B weiß nur, daß er auf eine Datei 5 in Block Nummer N1 in Einheit 2A zugreift. Der Client-Cache-Speicher 12B behandelt die Daten als logische Blöcke N1 der Dateien 5. In dem Server-Cache-Speicher 12A werden die Daten als logische Blöcke LBN1 der Einheiten 2A behandelt. Werden die Daten auf diese Art behandelt, kann der Server garantieren, daß wenn Daten in die Einheit als Ursprungseinheit geschrieben werden und es eine weitere Leseoperation von einem Block der Datei gibt, die in dem gleichen Block stattfindet, der in die Einheit geschrieben wurde, die Leseoperation dann die neugeschriebenen Daten sehen würde. Dies behält die Dateisystemsemantik.
Wenn auf die Datei in einem Client-Knoten B zugegriffen wird und die Datei im ASYNC oder READONLY Modus ist, wie Fig 5 zeigt, konvertiert das Client-Betriebssystem 11B die Dateibeschreibung und den Bytebereich innerhalb der Datei bei dem Systemaufruf READ (Dateibeschreibung N1) 16 nicht in Gerätenummer und logische Blocknummer in der Einheit. Der Client konvertiert die Dateibeschreibung und den Bytebereich in eine Dateihandhabung, Knotenkennzeichnung und logische Blockrummer in der Datei. In dem Client-Cache-Speicher 12B gibt es Blöcke 17, die durch Dateihandhabung, Knotenkennzeichnung und logische Blocknummer in der Datei gekennzeichnet sind. Wenn eine Leseoperation 16 von einer Client-Anwendung 4B, Schritt 104, Fig. 9, ausgegeben wird, geht die Anforderung für die Leseoperation mit Dateibeschreibung und Bytebereich in der Datei an das Betriebssystem 11B. Das Betriebssystem sieht dann in den Client-Cache-Speicher 12B, Schritt 105, Fig. 9. Wenn Dateihandhabung, Knotenkennzeichnung und die logische Blocknummer in der Datei vorhanden sind, wird der Cache-Speicher 12B gelesen, Schritt 106, Fig. 9. Sind diese nicht vorhanden, Schritt 107, Fig. 9, wird die Leseoperation zu dem Server gesendet, Schritt 108, Fig. 9. Der Server nimmt dann die Dateihandhabung und die logische Blocknummer in der Datei und konvertiert diese in eine Gerätenummer und einen logischen Block in der Einheit, Schritt 109, Fig. 9. Diese Konvertierung ist erforderlich, da der Server-Cache-Speicher 12A von der Gerätenummer und der Blocknummer in der Einheit gesteuert wird, da er in einem selbständigen System ist. Nachdem die Leseoperation an den Server gesendet wurde, wird diese so behandelt, als wäre die Leseoperation aus ihrer eigenen Anwendung in einem gelbständigen System gekommen, was mit Bezug auf Fig. 2 oben beschrieben wurde.
Eine geschlossene Datei hat keinen Synchronisierungsmodus. Sobald jedoch eine Datei von einer Verarbeitung zuerst geoffnet wird, wird der Synchronisierungsmodus der Datei gemäß folgendem Ablauf initialisiert, wie in Fig. 7 abgebildet.
Der Synchronisierungsmodus für eine Datei wird in ASYNCH 41 initialisiert, wenn die Einheit (D), in der sich die Datei befindet, geschlossen wird, 61, d.h. diese wird nicht als spezielle Einheit geöffnet, und die Datei wird zum Schreibzugriff in einem entfernten Knoten 62 geöffnet.
Der Synchronisierungsmodus für eine Datei ist READONLY 42, wenn die Einheit, in der sich die Datei befindet, geschlossen wird und die Datei zum Nur-Lese-Zugriff in einem oder mehreren Knoten 63 geöffnet wird, oder sowohl Einheit als auch Datei zum Nur-Lese-Zugriff 64 geöffnet werden.
Der Synchronisierungsmodus für eine Datei wird in FULLSYNCH 43 initialisiert, wenn die Einheit, in der sich die Datei befindet, als spezielle Blockeinheit zum Lese-/Schreibzugriff 65 geöffnet wird, oder die Datei in mehr als einem Knoten geöffnet wird und wenigstens eine der Dateien für eine Schreiboperation geöffnet wurde. Eine spezielle Blockeinheit bedeutet, daß es in der Einheit einen Ursprungszugriff gibt.
Sobald eine Datei in einem Modus initialisiert wurde, kann sich der Dateimodus ändern, wenn sich die Bedingungen ändern. Übergänge von einem Modus zu einem anderen, die durch die Linien 71-76 in Fig. 7 dargestellt sind, können unter folgenden Bedingungen auftreten.
Wenn eine Datei derzeit in ASYNC Modus 41 ist und die Anzahl von Knoten, in denen die Datei geöffnet wurde, zwei oder mehr beträgt, 81, dann ändert sich der Synchronisierungsmodus in FULLSYNC 44, wie Linie 72 in Fig. 6 zeigt. Auch wenn es eine Öffnung der speziellen Blockeinheit D gibt, in der sich die Datei befindet, 82, ändert sich der Synchronisierungsmodus von ASYNC 41 in FULLSYNC 43. Beim Schließen der Datei, wenn die Operation zum Schließen nicht die letzte Schließung der Datei ist, und die Datei zum Schreiben noch offen ist, gibt es keine Modusänderung. Wenn jedoch die Operation zum Schließen die letzte Schließung der Datei zum Schreibzugriff ist, so daß alle verbleibenden Öffnungen zum Lesezugriff sind, 83, dann ist der neue Modus READONLY 41, wie Linie 74 zeigt. Wenn die Operation zum Schließen die letzte Schließung der Datei ist, dann gibt es keinen Synchronisierungsmodus.
Wenn eine Datei derzeit in READONLY s_mode 42 ist und es eine Operation zum Öffnen der Datei gibt, gibt es keine Modusänderung, wenn die Datei zum Lesen geöffnet wurde. Wenn jedoch die Datei zum Schreiben geöffnet wird, dann ist der neue Synchronisierungsmodus ASYNC 41, wenn sich alle Öffnungen in einem Client-Knoten, 84, befinden, wie Linie 73 zeigt. Andernfalls ist der Synchronisierungsmodus FULLSYNC. Wenn die Einheit, in der sich die Datei befindet, außerdem zum Lese- /Schreibzugriff, 87, geöffnet wird, ist der neue Synchronisierungsmodus für die Datei der FULLSYNC Modus 43. Für eine Schließungsoperation, wenn die Schließung die letzte Schließung der Datei ist, gibt es für die Datei keinen Synchronisierungsmodus. Wenn die Datei noch in einem oder mehreren Knoten nach einer Schließungsoperation geöffnet ist, gibt es keine Änderung des Synchronisierungsmodus.
Wenn eine Datei, die derzeit in FULLSYNC Modus 43 ist und es eine weitere Öffnung für die Datei gibt, oder die Einheit, in der sich die Datei befindet, geöffnet ist, gibt es keine Änderung des Synchronisierungsmodus. Wenn nach einer Schlieißungsoperation der Datei, eine Datei zum Lese-/Schreibzugriff in einem entfernten Knoten verbleibt und die spezielle Blockeinheit, in der sich die Datei befindet, nicht offen ist, ändert sich der Synchronisierungsmodus in ASYNC s_mode 41, wie Block 88 über Linie 71 zeigt. Der Synchronisierungsmodus wird von FULLSYNC 43 ind READONLY 42 geändert, wenn die spezielle Blockeinheit, in der sich die Datei befindet, nicht offen ist und die Datei für Nur-Lese-Zugriff in einem oder mehreren Knoten geöffnet ist, wie Block 89 auf Linie 75 zeigt, oder wenn die spezielle Blockeinheit, in der sich die Datei befindet, für Nur-Lese-Zugriff geöffnet ist und die Datei für Nur-Lese- Zugriff geöffnet ist, wie Block 90 auf Linie 75 zeigt.
Alle Öffnungs- und Schließungsoperationen für Dateien und Einheiten werden in dem Server-Knoten durchgeführt. Der Server bestimmt den Synchronisierungsmodus von einer offenen Datei, wenn irgendeine Operation ausgeführt wird, die den Modus ändern kann. Der Server führt auch die Änderung der Synchronisierungsmodi durch. Da der Server neue Öffnungen oder Schließungen für die Datei erhält, kann für die Datei ein Wechsel in den Synchronisierungsmodi ausgelöst werden. Wenn der verlangte Synchronisierungsmodus nicht der aktuelle ist, sendet der Server einen "change sync mode" Fernverarbeitungsaufruf (rpc) an alle Clients mit offener Datei.
Nachdem eine Datei zum ersten Mal geöffnet wurde, wird der Client, der die Datei geöffnet hat, über den Modus der Datei informiert. Wenn der Modus entweder ASCNC oder READONLY ist, kann der Client beginnen, indem der Client-Cache-Speicher zum Lesen und auch zum Schreiben benutzt wird, wenn der Modus ASYNC ist, wie Fig. 5 zeigt. Der Client muß nicht über den DFV-Verbindungsweg aus/in den Server lesen oder schreiben. Wenn der Modus FULLSYNC ist, wie Fig. 8 zeigt, wird der Client-Cache-Speicher nicht benutzt, und der Client muß Lese- oder Schreiboperationen über den DFV-Verbindungsweg 3 an den Server senden.
Der Server A, Fig. 5, setzt immer den Modus 51 von Daten 5. Der Server A weiß auch, welche Knoten die Datei geöffnet haben und ob die Öffnungen zum Lesen oder Schreiben sind. Der Server A muß nicht wissen, welche Verarbeitungen 131-13N, 231-23N in einem Knoten eine Datei geöffnet haben. Der Server behält alle diese Informationen in einer Dateizugriffsstruktur 50, die den Synchronisierungsmodus 51, eine Liste mit Knoten, die die Datei 52 geöffnet haben, die Anzahl der Leseoperationen 53 und die Anzahl der Schreiboperationen 54 in einer Datei 5 enthält.
Die Dateizugriffsstruktur 50 wird mit dem Knoten 55 verbunden. Der Knoten 55 enthält die Dateikopfzeile 56, die eine Datei 5 kennzeichnet. Der Knoten 55 enthält ebenfalls einen Block 57, der die Information enthält, in welcher Einheit sich die Datei befindet und einen Block 58, der die Information enthält, wo in der Einheit sich die Datei befindet.
Der Knoten 55 enthält auch zwei Zeitbits 111 und 112. Zeitbits werden in dem Knoten 55 verwendet, um zu helfen, Informationen über die Datei zu verfolgen. Das Zeitzugriffsbit 111 gibt an, daß die Datei oder die Daten gelesen wurden. Das Zeitänderungsbit 112 gibt an, daß die Daten oder die Datei durch einen Schreibzugriff geändert wurden.
Wenn das Zeitänderungsbit 112 gesetzt wurde und eines der folgenden drei Ereignisse eintritt, wird die aktuelle Zeit in dem Server A und die geänderten Daten in dem Server-Cache-Speicher 12A in die Platte 2 geschrieben. Die drei Ereignisse enthalten die Überprüfung des Status einer Datei, das Schließen einer Datei, oder eine regelmäßige Synchronisierung. Eine regelmäßige Synchronisierung schreibt den Cache-Speicher regelmäßig in die Platte, z.B. jede Minute. Wenn die Server-Zeit und die Daten in dem Server-Cache-Speicher 12A in die Platte 2 geschrieben werden, wird der Zeitänderungsbit 112 zurückgesetzt.
Wenn es eine Anforderung zur Prüfung des Status einer Datei gibt, prüft der Server A, ob die Datei offen ist, und durch Prüfen der Knotenbits, ob das Zeitänderungsbit 112 gesetzt wurde, die neue Zeit geschrieben wurde, welche die Zeit der Statusanforderung angibt und ob der Status zurückgeführt wurde. Wenn danach eine Anforderung für einen Status auegegeben wird, erhält der Anforderer die Zeit, welche die Zeit angibt, zu der die Datei geändert wurde. Das Zeitänderungsbit 112 wird sich für die nächsten Statusanforderungen nicht ändern.
Die Zeit von der Änderung der Datei, wird - wie oben ausgeführt - von Client B als Angabe verwendet, daß Datei 5 geändert wurde, nachdem Client B Datei 5 geschlossen hat. Wenn ein Client B eine Datei schließt, gibt der Server selbst die Dateizugriffsstruktur 50 für die geschlossene Datei 5 frei, wenn dies die zuletzt geschlossene Datei war. Wenn ein anderer Knoten die Datei geöffnet hat, während die Datei in Knoten B geschlossen ist, hat die Dateizugriffsstruktur 50 nur die Information in dem offenen Knoten in Block 52. Mit anderen Worten, sobald Knoten B eine Datei schließt, behält Server A keinerlei Information, die angibt, daß Knoten B Datei 5 zuvor geöffnet hat.
Wie zuvor erörtert, kann eine Datei für Nur-Lese-Zugrif von Verarbeitungen geöffnet werden, die in einzelnen Client-Knoten B, C, und dem Server-Knoten A (d.h. READONLY Synchronisierungsmodus) ausgeführt werden; oder die Datei kann von den Verarbeitungen zum Lesen und Schreiben in nur einem Client- Knoten B (d.h. ASYNC Synchronisierungsmodus) geöffnet werden. In jedem Fall hat der Client-Cache-Speicher in jedem Client- Knoten potentiell gültige Blöcke der Datei. Wenn die Datei von allen Verarbeitungen in dem Client B geschlossen wird, sollten die Blöcke in Client B nicht automatisch ungültig gemacht werden. Indem die Blöcke mit Daten in Client B verfügbar gehalten werden, wenn die Datei von irgendeiner Verarbeitung in Knoten B neu geöffnet wird, werden keine entfernten Leseanforderungen für diese Daten an den Server A ausgegeben.
System und Verfahren dieser Erfindung gibt dem Client-Knoten B ein Mittel, um festzustellen, ob eine Datei in einen anderen Knoten während der Zeit geschrieben wurde oder nicht, in welcher der Client-Knoten B Datei 5 geschlossen hat. Ein Client B kann die Dateiblöcke in dem Client-Cache-Speicher nur benutzen, wenn keine Schreiboperationen in der Datei durchgeführt wurden, während die Datei in Client B geschlossen wurde. Wenn der Client-Knoten B die Datei neu öffnet, und die Datei nicht geändert wurde, während diese in Client-Knoten B geschlossen wurde, dann kann der Client-Knoten B direkt aus dem Client- Cache-Speicher 12 B auf Datei 5 zugreifen. Wenn der Client- Knoten B Datei 5 neu öffnet und Datei 5 geändert wurde, während die Datei in Client-Knoten B geschlossen wurde, dann muß der Client-Knoten B über Netz 3 zu dem Server gehen, um die geänderte Datei 5 zu erhalten. Die geänderte Datei wird dann in dem Client-Cache-Speicher 12B zwecks weiteren Zugriffs gespeichert.
System und Verfahren dieser Erfindung wird am besten mit gleichzeitigem Bezug auf Fig. 10 und Fig. 11 dargestellt. Wenn eine Datei 5 zum ersten Mal von einer Verarbeitung 231 in dem Client-Knoten B, Schritt 120, geöffnet wird, erstellt der Client-Knoten B einen Surrogat-Knoten 114, Schritt 121. Ein Surrogat-Knoten ist einem Verbindungsknoten ähnlich, mit der Ausnahme, daß dieser nicht all die Informationen enthält, die ein Verbindungsknoten enthält.
Wenn eine Öffnung für eine entfernte Datei 5 in einem Client B ausgegeben wird, wird die Surrogat-Knoten-Tabelle in dem Client-Verarbeitungssystem auf einen vorhandenen Surrogat-Knoten für Datei 5 abgetastet. Wenn keiner vorhanden ist, dann wird ein neuer Surrogat-Knoten zugeteilt. Ein Aufruf zur Eröffnung einer Fernverarbeitung wird von dem Client an den Server gesendet. Wenn die Eröffnung in dem Server abgeschlossen ist, enthält eine Eröffnungsbestätigung von dem Server an den Client die Zeit der letzten Änderung von Datei 5. Die Zeit der letzten Änderung 22, die in die Serverplatte 2 für Datei 5 geschrieben wurde, wird in dem neu zugeteilten Surrogat-Knoten 114 in Block 115 in Client B, Schritt 122, aufgezeichnet. Die Änderungszeit T1, die in Block 22 und Block 115 aufgezefchnet wurde, ist die Zeit in Server A und nicht die Zeit in Client B. In dem Server-Knoten A wird die Dateizugriffsstruktur 50 in Block 52 aktualisiert, um zu zeigen, daß die Datei in Knoten B, Schritt 123, geöffnet ist.
Wenn dann eine erste Leseoperation ausgegeben wird, wird dem Client-Cache-Speicher 12B ein Datenblock 116 zugeteilt, Schritt 124. Das erste Bit 152 in dem Datenblock 116 kennzeichnet den Server-Knoten A. Das zweite Bit 153 enthält eine Dateihandhabung, um Datei 5 zu kennzeichnen. Wenn ein neuer Cache-Block einem Block in Datei 5 zugeteilt wird, wird die Änderungszeit T1 von Block 115 des Surrogat-Knotens 114 in die Kopfzeile des Cache-Blocks in Bit 117 des Datenblocks 116 kopiert. In dem Server-Knoten A gibt die Dateizugriffsstruktur 50 die Anzahl von Leseoperationen an, die 1 in Block 53 sind, Schritt 125, sind.
Bei einer zweiten Öffnung, Schritt 126, wird von Client-Knoten B, z.B. von Verarbeitung 232, kein zusätzlicher Surrogat-Knoten 114 erstellt. Nachfolgende Öffnungen von Datei 5 in Client B werden den zuvor zugeteilten Surrogat-Knoten 114 benutzen und die Zeit der Änderung der Datei nicht aktualisieren, wie diese bei der ersten Öffnung aufgezeichnet wurde.
Bei einem zweiten Lesen von einer der Verarbeitungen 231-23N in Client-Knoten B, die Datei 5 geöffnet haben, wird ein weiterer Datenblock 118 in dem Client-Cache-Speicher 12 B Zugeteilt und die Zeit T1 in Block 115 des Surrogat-Knotens 114 wird in Block 119 des neuen Datenblocks 118, Schritt 127, geschrieben. Dementsprechend wird die Dateizugriffsstruktur 50 in dem Server-Knoten A aktualisiert, um zwei Öffnungen zum Lesen in Block 53, Schritt 128, zu reflektieren.
Wenn die Verarbeitung 231 in Client-Knoten B Datei 5, Schritt 129, schließt, wird die Schließung an den Server-Knoten A gesendet. Der Server A dekrementiert dann die Gebrauchszählung, die die Anzahl von Leseoperationen in Block 53, Schritt 130 angibt. in diesem Beispiel würde von 2 nach 1 gezählt.
Bei der letzten Schließung, Schritt 131, von Datei 5 in Client-Knoten B, dekrementiert Server A im Fall der zweiten Schließung die Gebrauchszählung in der Dateizugriffsstruktur 50, so daß es keine Öffnungen in Knoten B gibt. Block 53 und Block 54 in der Dateizugriffsstruktur gehen auf Null. Wenn diese Blöcke für einen Client-Knoten auf Null gehen, weiß der Server, daß dies eine letzte Schließung war und entferne die Dateizugriffsstruktur 50 für Client B, Schritt 132. Server A sendet eine Schließungsbestätigung an Client B, Schritt 133. Zusammen mit der Bestätigung führt der Server die letzte Zeit zurück, wenn die Datei, wie in dem Server aufgezeichnet geändert wurde. Wenn die Datei in ASYNC Modus ist, wird der Client-Cache-Speicher abgetastet und für jeden Cache-Block, der eine Dateihandhabung für Datei 5 hat, wird die Änderungszeit unter Verwendung der Zeit in der Schließungsbestätigung aktualisiert. Im wesentlichen werden alle Zeiten in den Datenblöcken 116, 118 entsprechend der letzten Zeit T2 in Black 22 aktualisiert, die in Einheit 2 für Datei 5, Schritt 134 geschrieben wurde. Auch mit der letzten Schließung in einem Client-Knoten B gibt der Client-Knoten B den Surrogat-Knoten 114 frei, der bei der ersten Öffnung in Schritt 121 erstellt wurde.
Nach der letzten Schließung im Client, kann eine Verarbeitung 231-23N in Client B die Datei 5, Schritt 135, neu öffnen. Bei dieser Neuöffnung erstellt Client B einen neuen Surrogat-Knoten 150 für Datei 5 und schreibt die letzte Zeit T3 aus dem Server in Block 22 von Einheit 2 in Block 151 in dem Surrogat- Knoten 150, Schritt 136. Wenn keine weiteren Knoten A, C, Datei 5 geändert haben, während die Datei in Client B geschlossen war, würde Zeit T3 auf Platte 2 nicht von Zeit T2 geändert, die von Platte 2 in die Datenblöcke 116, 118, während der Schließungsbestätigung, Schritte 133, 134, geschrieben wurde. Wenn jedoch weitere Knoten A, C, in Datei 5 geschrieben wurden, während die Datei in Client B geschlossen war, kann Zeit T3 in Block 22 in Gerät größer als Zeit T2 sein, die von Platte 2 in die Datenblöcke 116, 118, während der Schließungsbestätigung, Schritte 113, 135, geschrieben wurde.
Wie in dem Verknüpfungsblock 137, Fig. 11, gezeigt wird, wird bei Neuöffnung einer Datei in einem Client-Knoten B die Zeit T3, die gerade in den neuen Surrogat-Knoten 150 in Block 151 geschrieben wurde, mit der Zeit T2 in Block 117, 119, der Datenblöcke 116 bzw. 118 verglichen. Wenn die Zeit T3 in dem Surrogat-Knoten 150 nicht gleich mit Zeit T2 in den Datenblöcken 116, 118 ist, dann können die Daten in den Datenblöcken des Client-Cache-Speichers nicht verwendet werden. Client B muß auf Server A über das Netz 3 zugreifen und das zwei-Schritt-Cache-Schema aufrufen: von Platte 2 zu Server- Cache-Speicher 12A und Client-Cache-Speicher 12B. Wenn Zeit T3 in dem Surrogat-Knoten 150 gleich ist mit Zeit T2 in den Datenblöcken 116, 118, des Cache-Speichers ist, dann können die Verarbeitungen 231-23N in Client B direkt auf die Daten aus dem Client-Cache-Speicher 12B zugreifen, ohne durch das Netz 3, Schritt 139 zu gehen.
Für eine Datei im ASYNC oder READONLY Synchronisierungsmodus entscheidet der Client, ob die Daten in einem spezifischen Cache-Block gültig sind, die auf den zuvor beschriebener Schritten basieren. Um es dem Client zu ermöglichen, diese Entscheidung zu treffen, enthält die Kopfzeile für jeder Cache-Block die Zeit von der letzten Änderung der Datei entsprechend der Uhr des Servers. Die Zeit der letzten Änderung wird in dem Cache-Block aufgezeichnet, wenn der Block aus dem Server gelesen wird, und zugleich aktualisiert, wenn die Datei in dem Client-Knoten zuletzt geschlossen wurde. Wenn auf einen vorhandenen Cache-Block zum Lesen zugegriffen wird (oder zum Schreiben eines partiellen Blocks), wird die Zeit in dessen Kopfzeile mit der in dem Surrogat-Knoten verglichen. Wenn die Zeit in dem Surrogat-Knoten mit der in dem Cache-Block gleich ist, sind die Daten in dem Block gültig und können von dem Client verwendet werden, während die Dateisystemsemantik erhalten bleibt. Wenn die Zeit in dem Surrogat-Knoten nicht gleich mit der Zeit in dem Cache-Block ist, dann sind die Daten in dem Block ungültig und können von dem Client nicht verwendet werden. Der Client sendet für diesen Datenblock einen Leseaufruf zur Fernverarbeitung an den Server.
Das bevorzugte Ausführungsbeispiel kann wie folgt zusammengefaßt werden. Erstens: jeder Surrogat-Knoten hat ein Dateifeld für die Änderungszeit. Zweitens: die Client-Cache-Blöcke haben ein Dateifeld für die Änderungszeit. Drittens: ein Client- Cache-Block ist nur gültig, wenn die Zeit der Änderung der Datei des Cache-Blocks gleich mit der Zeit der Änderung der Datei des Surrogat-Knotens ist. Viertens: die Surrogat-Knoten werden in einem Client erstellt, nachdem die Datei in dem Client geöffnet wurde, wenn die Datei nicht schon in dem Client geöffnet ist.
Fünftens: dem Dateifeld der Änderungszeit des Surrogat-Knotens wird ein Wert zugeteilt, wenn entweder 1) ein Surrogat-Knoten aufgrund einer Öffnungsanforderung von dem Server erstellt wird, 2) eine Anforderung zur Änderung des Synchronisierungsmodus durch den Server aufgrund einer Anforderung zur Änderung des Synchronisierungsmodus von dem Server empfangen wird, 3) eine Schließung im Client die Datei veranlaßt, von dem ASYNC Modus in den READONLY Synchronisierungsmodus in dem Client zu gehen, oder 4) eine Schließung in dem Client die Datei veranlaßt, im Client nicht länger offen zu bleiben. Zu bemerken ist, daß die Änderungszeit der Datei des Surrogat-Knotens nicht geändert wird, wenn die Öffnungen in dem Client auftreten, die den Surrogat-Knoten nicht veranlassen, erstellt zu werden. Dies deshalb, weil die Datei bereits in dem Client offen ist. Zu bemerken ist auch, daß die oben angegebenen Bedingungen 3) und 4) durch die Bedingung für jede Schließung einer Datei entsprechend einer Öffnung der Datei zum Schreiben ersetzt werden können.
Die Änderungszeit der Datei des Surrogat-Knotens wird dem Wert zugeteilt, der durch den Server in der Anforderung zum Öffnen gesendet wird von 1) wie oben, oder der Anforderung zur Änderung des Synchronisierungsmodus in 2) wie oben, oder der von dem Server an den Client zurückgeführten Schließungsbestätigung in 3) oder 4) wie oben. Dieser Wert ist die Zeit, zu der die Datei zuletzt, wie von dem Server erfaßt, geändert wurde.
Sechstens: die Client-Cache-Blöcke für eine Datei haben ihre Dateifelder für die Änderungszeit, welchen ein Wert zugteilt wird, wenn entweder 1) dieser aufgrund eines Lesens von Daten aus dem Server oder eines Schreibvorgangs durch eine Client- Verarbeitung in die Datei zugeteilt wird, oder 2) eine Schließung entsprechend der Situation in 3) oder 4) wie oben, auftritt. Dieser Wert, welcher der Zeit für die Änderung der Datei des Cacheblocks zugeteilt wurde, ist der Wert, dem in dem Dateifeld der Änderungszeit des Client-Surrogat-Knotens festgestellt wurde. Unbedingt zu bemerken ist: sofort nach den obengenannten Bedingungen, die die Zuteilung von Werten in die Dateifelder für die Änderungszeit des Cache-Blocks verarlassen, werden die Dateifelder für die Änderungszeit der Cache- Blöcke und der Surrogat-Knoten gleich sein.
Das oben beschriebene System und Verfahren benutzt in dem Client-Verarbeitungssystem einen Client-Cache-Speicher, um eine Datei in einem Client-Knoten aus dem Server-Verarbeitungssystem zwischenzuspeichern. Das bevorzugte Ausführungsbeispiel bestimmt die Gültigkeit in dem Client-Verarbeitungssystem von Datenblöcken in dem Client-Cache-Speicher, indem die in dem Server aufgezeichnete Zeit verwendet wird, wie diese von der Uhr des Servers erfaßt wurde. Andere Ausführungsbeispiele, die der Server benutzt, um die Gültigkeit der Datenblöcke des Clients zu verfolgen, können die Server Betriebsmittel verwenden, die kritischer als die Betriebsmittel des Client sind. Auch kann der Server Datenblöcke in dem Client-Cache-Speicher verfolgen, die sich nicht länger in dem Client-Cache-Speicher befinden.

Claims

1. Ein System zum Zugriff auf eine Datei (5) in einem Server- Verarbeitungssystem (10A) in einem Server-Knoten (A) zur Verwendung in einem Client-Verarbeitungssystem (10B) in einem Client-Knoten (B), wobei das System enthält:

einen Client-Cache-Speicher (12B) in dem Client-Verarbeitungssystem (10B) zur Zwischenspeicherung einer Vielzahl von Blöcken der Datei in dem Client-Knoten (B) aus dem Server-Verarbeitungssystem, wobei das Client-Verarbeitungssystem (108) die Gültigkeit der Blöcke in dem Client- Cache-Speicher (12B) als eine Funktion von einer Zeit in dem Server-Verarbeitungssystem (10A) festlegt, auf die Blöcke der Datei in dem Client-Cachespeicher (12B) zugegriffen wird, wenn die Blöcke als gültig anerkannt wurden, wobei auf die Datei aus dem Server-Verarbeitungssystem (10A) zugegriffen wird, wenn die Blöcke als ungültig anerkannt wurden, die Blöcke der Datei in dem Client-Cache- Speicher (128) jedesmal weggeworfen werden, wenn die Blöcke als ungültig anerkannt wurden;

dadurch gekennzeichnet, daß das System außerdem enthält;

Mittel zum Schreiben (123) der Zeit einer letzten Änderung (T1 bis T3) in die Datei in dem Server-Verarbeitungssystem (10A), und zwar jedesmal, wenn die Datei aktualisiert wird;

eine Vielzahl von Cache-Datenblöcken (116, 118) in dem der Datei zugeordneten Client-Cache-Speicher (12B), wobei jeder der Datenblöcke die Zeit der letzten Änderung (T2) enthält, die in die Datei in dem Server-Verarbeitungssystem geschrieben wurde, wenn die Datei in dem Client- Verarbeitungssystein geschlossen wird;

einen Cache-Block (150) in dem Client-Cache-Speicher (12B) mit der Zeit (T3) der letzten Änderung, die in die Datei in dem Server-Verarbeitungssystem zugleich mit einer ersten Öffnung der Datei in der Client-Verarbeitung geschrieben wurde;

Mittel zum Vergleichen (137) der Zeit (T3) der letzten Änderung, die in dem Client-Verarbeitungssystem bei der ersten Öffnung zu der Zeit (T2) der letzten Änderung in dem zugeteilten Cache-Block (116, 118) aufgezeichnet wurde;

Mittel zum Zugriff (138) auf Daten aus dem Client-Cache- Speicher (12B) des Client-Verarbeitungssystems, wenn die in dem Client-Verarbeitungssystem bei der ersten Öffnung aufgezeichnete Zeit (T3) gleich mit der Zeit (T2) in dem Cache-Block ist, und

Mittel zum Zugriff (138) auf die Datei aus dem Server-Verarbeitungssystem (10A), wenn die in dem Client-Verarbeitungssystem (108) bei der ersten Öffnung aufgezeichnete Zeit (T3) nicht gleich mit der Zeit (T2) in dem Cache- Block ist.

2. Das System von Anspruch 1, wobei der Cache-Block außerdem eine Dateihandhabung (153) zur Kennzeichnung der Datei enthält.

3. Das System von Anspruch 1, wobei der Cache-Block außerdem Mittel (152) zur Kennzeichnung des Server-Knotens der Datei enthält.

4. Ein Verfahren zum Zugriff auf eine Datei (5) in einem Server-Verarbeitungssystem (10A) in einem Server-Knoten (A) zur Verwendung in einem Client-Verarbeitungssystem (10B) in einem Client-Knoten (B), wobei das Verfahren enthält;

Zwischenspeicherung der Datei in einem Client-Cache-Speicher (12B) mit Datenblöcken, Bestimmung der Gültigkeit von Datenblöcken in dem Client-Cache-Speicher in dem Client- Verarbeitungssystem (10B) als eine Funktion einer Zeit in dem Server-Verarbeitungssystem;

Zugriff von Daten aus dem Client-Cache-Speicher (12B) des Client-Verarbeitungssystems (10B), wenn die Datenblöcke als gültig anerkannt wurden;

Zugriff auf die Datei von dem Server-Verarbeitungsystem (10A), wenn die Datenblöcke als ungültig anerkannt wurden;

und Wegwerfen von Daten in dem Client-Cache-Block (12B), wenn die Datenblöcke als ungültig anerkannt wurden:

dadurch gekennzeichnet: Schreiben (123) einer letzten Änderungszeit (T1 bis T3) in die Datei in dem Server-Verarbeitungssystem (10A), jedesmal bei Aktualisierung hier Datei;

Aufzeichnung (122) der letzten Änderungszeit (T3) in dem Client-Verarbeitungssystem (10B) zugleich mit einer ersten Öffnung der Datei in dem Client-Verarbeitungssystem;

Zuteilung (124) eines Cache-Blocks, der der Datei in einem Client-Cache-Speicher (12B) in dem Client-Verarbeitungssystem zugeordnet wird, wenn ein Block der Datei gelesen wird, Aufzeichnung (124) der Zeit (T3), die in dem Client- Verarbeitungssystem zugleich mit der ersten Öffnung in dem zugeteilten Cache-Block aufgezeichnet wird;

Aktualisierung (134) der Zeit (T2), die in jedem zugeteilten Cacheblock (116, 118) aufgezeichnet wurde, die der Datei zugleich mit einer Schließung der Datei in dem Client- Verarbeitungssystem mit der letzten Änderungszeit in der Datei in dem Server-Verarbeitungssystem zugeteilt wird; und Vergleichen (137) der letzten Änderungszeit (T3), die in dem Client-Verarbeitungssystem bei der ersten Öffnung zu der letzten Änderungszeit (T2) in dem zugeteilten Cache-Block (116, 118) aufgezeichnet wurde; und

Zugriff (138) auf Daten aus dem Client-Cache-Speicher (12B) des Client-Verarbeitungssystems, wenn die in dem Client-Verarbeitungssystem aufgezeichnete Zeit (T3) bei der ersten Öffnung gleich mit der Zeit (T2) in dem Cacheblock ist und Zugriff (138) auf die Datei aus dem Server-Verarbeitungssystem (10A), wenn die in dem Client- Verarbeitungssystem (10B) bei der ersten Öffnung aufgezeichnete Zeit (T3) nicht gleich mit der Zeit (T2) in dem Cache-Block ist.