DE69031926T2

DE69031926T2 - Instandhaltung von Dateiattributen in einem verteilten Datenverarbeitungssystem

Info

Publication number: DE69031926T2
Application number: DE69031926T
Authority: DE
Inventors: Donavon William Johnson; Stephen Paul Morgan; Todd Allen Smith
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 1989-05-15
Filing date: 1990-04-10
Publication date: 1998-08-13
Anticipated expiration: 2010-04-11
Also published as: EP0398494A2; DE69031926D1; JPH073658B2; BR9002251A; EP0398494B1; JPH035848A; US5113519A; EP0398494A3

Description

Diese Erfindung betrifft die Verwaltung von Dateiattributen in einem verteilten Datenverarbeitungssystem, das eine Vielzahl von Datenverarbeitungssystemen, die über eine Übertragungsleitung miteinander verbunden sind, enthält, und den Zugriff auf Dateien zwischen lokalen und fernen Verarbeitungssystemen in der verteilten Netzwerkumgebung.
Wie in Fig. 1 gezeigt ist, besteht eine verteilte Netzwerkumgebung 1 aus zwei oder mehreren Knoten A, B, C, die über eine Übertragungsleitung oder ein Netzwerk 3 miteinander verbunden sind. Das Netzwerk 3 kann entweder ein lokales Netz (LAN) oder ein Weitverkehrsnetz (WAN) sein.
An einem beliebigen der Knoten A, B, C kann sich ein Verarbeitungssystem 10A, 10B, 10C, wie beispielsweise ein Arbeitsplatzrechner, befinden. Jedes dieser Verarbeitungssysteme 10A, 10B, 10C kann ein Einzelbenutzersystem oder ein Mehrbenutzersystem sein, das in der Lage ist, das Netzwerk 3 zum Zugriff auf Dateien zu benutzen, die sich an einem fernen Knoten befinden. Beispielsweise kann das Verarbeitungssystem 10A am lokalen Knoten A auf die Dateien 5B, 5C an den fernen Knoten B beziehungsweise C zugreifen.
In diesem Schriftstück dient der Begriff "Server" zur Bezeichnung des Verarbeitungssystems, an dem die Datei permanent gespeichert wird, und der Begriff "Client" dient zur Bezeichnung eines beliebigen anderen Verarbeitungssystems, das über Prozesse verfügt, die auf die Datei zugreifen. Es sollte sich jedoch von selbst verstehen, daß der Begriff "Server" nicht die Bedeutung eines funktionsspezifischen Servers, wie der Begriff in manchen lokalen Netzwerksystemen verwendet wird, hat. Das System für verteilte Dienste, in dem die Erfindung ausgeführt wird, ist wirklich ein verteiltes System, das eine große Vielzahl von Anwendungen unterstützt, die an verschiedenen Knoten in dem System, das auf Dateien zugreifen kann, die sich irgendwo in dem System befinden, ausgeführt werden.
Wie erwähnt wurde, betrifft die Erfindung, die nachstehend beschrieben wird, ein verteiltes Datenverarbeitungssystem in einem Kommunikationsnetz. In dieser Umgebung ist es jedem Prozesor an einem Knoten in dem Netzwerk möglich, auf alle Dateien in dem Netzwerk zuzugreifen, ungeachtet dessen, an welchen Knoten sich die Dateien befinden.
Andere Ansätze zur Unterstützung eines verteilten Datenverarbeitungssystems sind bekannt. Die verteilten Dienste von IBM für das Betriebssystem AIX sind beispielsweise in S.N. 014 897 "A System and Method for Accessing Remote Files in a Distributed Networking Environment", im Namen von Johnson u.a. am 13. Februar 1987 eingereicht, offengelegt. Darüber hinaus hat Sun Microsystems ein Network File System (NFS) herausgebracht, und Bell Laboratories hat ein Remote File System (RFS) entwickelt. Das NFS von Sun Microsystems wurde in einer Reihe von Veröffentlichungen beschrieben, unter anderem in "Vnodes: An Architecture for Multiple File System Types in Sun UNIX" von S.R. Kleiman, Conference Proceedings, USENIX 1986 Summer Technical Conference and Exhibition, Seiten 238 bis 247, "Design and Implementation of the Sun Network Filesystem" von Russel Sandberg u.a., Conference Proceedings, Usenix 1985, Seiten 119 bis 130, "Overview of the Sun Network File System" von Dan Walsh u.a., Seiten 117 bis 124, "Status Monitor Provides Network Locking Service for NFS" von JoMei Chang, "SunNet" von JoMei Chang, Seiten 71 bis 75, und "Secure Networking in the Sun Environment" von Bradley Taylor, Seiten 28 bis 36. Das RFS von AT&T wurde ebenfalls in einer Reihe von Veröffentlichungen beschrieben, unter anderem in "RFS Architectural Overview" von Andrew P. Rifkin u.a., USENIX Conference Proceedings, Atlanta, Georgia (Juni 1986), Seiten 1 bis 12, "An Administrator's View of Remote File Sharing" von Richard Hamilton u.a., Seiten 1 bis 9, "File Systems Switch" von Tom Houghton u.a., Seiten 1 bis 2, und "A Framework for Networking in System V" von David J. Olander u.a., Seiten 1 bis 8.
Ein Merkmal des Systems für verteilte Dienste, in dem die thematisierte Erfindung ausgeführt wird, das es beispielsweise vom NFS von Sun Microsystems unterscheidet, ist, daß Suns Ansatz die Entwicklung eines im wesentlichen zustandslosen Servers war. Das heißt, daß der Server keine Informationen über Client- Knoten speichert, einschließlich solcher Informationen, welche Client-Knoten eine Server-Datei geöffnet haben oder ob Client- Prozesse eine Datei im Nur-Lese-Modus oder im Schreib-Lese- Modus geöffnet haben. Eine solche Ausführung vereinfacht die Auslegung des Servers, weil sich der Server nicht mit Fehlerbehebungssituationen befassen muß, die eintreten können, wenn ein Client ausfällt oder sich abkoppelt, ohne den Server ordnungsgemäß darüber zu informieren, daß er auf seinen Anspruch auf Server-Ressourcen verzichtet.
Eine vollkommen andere Vorgehenweise wurde bei der Entwicklung des Systems für verteilte Dienste eingeschlagen, in dem die vorliegende Erfindung ausgeführt ist. Genauer gesagt, das System für verteilte Dienste kann als "zustandsvolle Ausführung" charakterisiert werden. Ein "zustandsvoller" Server, wie beispielweise der hier beschriebene, bewahrt Informationen darüber auf, wer seine Dateien benutzt und wie die Dateien benutzt werden. Dies setzt voraus, daß der Server eine Möglichkeit hat, den Verlust des Kontakts mit einem Client festzustellen, so daß angesammelte Zustandsinformationen über diesen Client gelöscht werden können. Die hier beschriebenen Cache- Verwaltungsstrategien können nur unter der Voraussetzung, daß der Server solche Zustandsinformationen aufbewahrt, realisert werden.
Das Problem, dem man beim Zugreifen auf ferne Knoten begegnet, läßt sich besser verstehen, indem man zuerst untersucht, wie ein eigenständiges System auf Dateien zugreift. In einem eigenständigen System, wie beispielsweise dem System 10, wie es in Fig. 2 gezeigt ist, wird ein lokaler Puffer 12 im Betriebssystem 11 zur Pufferung der Daten verwendet, die zwischen dem permanenten Speicher 2, wie beispielsweise einer Festplatte in einem Arbeitsplatzrechner, und dem Benutzeradreßraum 14 übertragen werden. Der lokale Puffer 12 im Betriebssystem 11 wird auch als lokaler Cache oder Kernel-Puffer bezeichnet.
In dem eigenständigen System wird der Kernel-Puffer 12 in Blökke 15 unterteilt, die durch die Einheitennummer und die Nummer des logischen Blocks innerhalb der Einheit gekennzeichnet sind. Wenn ein Lesesystemaufruf 16 ausgegeben wird, wird er mit einem Dateideskriptor der Datei 5 für einen Bytebereich innerhalb der Datei 5 ausgegeben, wie im Schritt 101, Fig. 3, gezeigtist. Das Betriebssystem 11 nimmt diese Informationen und setzt sie im Schritt 102, Fig.. 3, in die Einheitennummer und die Nummern der logischen Blöcke in der Einheit um. Wenn sich der Block im Cache befindet, Schritt 103, werden die Daten im Schritt 105 direkt aus dem Cache abgerufen. In dem Fall, in dem der Cache die Suche nach dem Block im Schritt 103 nicht anhält, werden die Daten im Schritt 104 in den Cache gelesen, bevor mit dem Schritt 105 fortgefahren wird, in dem die Daten aus dem Cache abgerufen werden.
Alle Daten, die von der Platte 2 gelesen werden, werden im Cache-Block 15 aufbewahrt, bis der Cache-Block 15 zu einem anderen Zweck gebraucht wird. Folglich wird auf aufeinanderfolgende Leseanforderungen von einer Anwendung 4, die auf dem Verarbeitungssystem 10 läuft, für dieselben Daten, die zuvor gelesen wurden, vom Cache 12 und nicht von der Platte 2 zugegriffen. Das Lesen aus dem Cache ist weitaus weniger zeitaufwendig als das Lesen von der Platte.
Genauso werden von der Anwendung 4 geschriebene Daten nicht sofort auf der Platte 2 gespeichert, sondern in den Cache 12 geschrieben. Dies spart Plattenzugriffe, wenn eine andere Schreiboperation an denselben Block ausgegeben wird. Geänderte Datenblöcke im Cache 12 werden in regelmäßigen Abständen auf der Platte 2 gespeichert.
Die Verwendung eines Cache in einem eigenständigen System, das ein AIX-Betriebssystem verwendet, verbessert die gesamte Leistungsfähigkeit des Systems, da Plattenzugriffe bei aufeinanderfolgenden Lese- und Schreiboperationen ausgeschaltet werden. Die gesamte Leistungsfähigkeit wird gesteigert, da der Zugriff auf einen permanenten Speicher langsamer und teurer ist als der Zugriff auf einen Cache.
Wie vorstehend beschrieben wurde, können lokale Puffer in dem Betriebssystem zur Verbesserung der Leistungsfähigkeit von eigenständigen Zugriffen auf Dateien verwendet werden. Diese lokalen Puffer werden im schnellen Speicher gehalten, während Dateien normalerweise in langsameren, permanenten Speichern, wie beispielsweise Plattenlaufwerken, aufbewahrt werden. Größere Cache-Pufferspeicher können die Leistungsfähigkeit eines Datenverarbeitungssystems verbessern, weil der Cache einen größeren Teil der Daten, die zu den Dateien des Systems gehören, halten kann und folglich die Notwendigkeit, die langsameren Plattenlaufwerke zu verwenden, mindert. Die Größe des physischen, schnellen Speichers eines Systems ist begrenzt. Statt den physischen Speicher zu unterteilen, indem ein fester Teil für die Kernel-Puffer des Betriebssystems reserviert wird, kann von virtuellen Speichertechniken Gebrauch gemacht werden, um den Zugriff auf die Plattendateien des Systems zu beschleunigen. Bei dieser virtuellen Speichertechnik gibt es keinen festen Cache aus Plattenblöcken. Statt dessen werden Daten im virtuellen und nicht im physischen Speicher zwischengespeichert.
Der virtuelle Speicher bietet einen größeren Speicherbereich als der verfügbare physische Speicher. Dieser virtuelle Speicherbereich wird in Seiten unterteilt und so von Programmen verwendet, als ob der virtuelle Speicherbereich ein echter physischer Speicher wäre. Die Seiten des virtuellen Speichers eines Systems befinden sich entweder in tatsächlichen physischen Speicherrahmen, in Plattenblöcken oder in beidem. Immer wenn eine virtuelle Speicherseite in einem physischen Rahmen nicht vorhanden ist, führt jeder Versuch, diese Seite zu benutzen, zu einer Ausnahmebedingung, die als Fehlseitenbedingung bekannt ist. Das Programm, das versucht, eine solche Seite zu benutzen, erzeugt eine Fehlseitenbedingung und wird vorübergehend angehalten, während die virtuelle Speicherseite von dem Plattenblock abgerufen wird, in dem sie sich gegenwärtig befindet, und in einen physischen Speicherrahmen kopiert wird. Nachdem der virtuellen Speicherseite ein physischer Rahmen zugewiesen worden ist, kann dem ursprünglichen, fehlerhaften Programm die Fortsetzung gestattet werden, und es stellt nun fest, daß die Daten in dieser virtuellen Speicherseite zur Verfügung stehen.
Eine andere Möglichkeit, die vom virtuellen Speicher gebotene Flexibilität vorteilhaft zu nutzen, ist die, Prozessen zu gestatten, Dateien in ihren virtuellen Adreßraum abzubilden. Auf diese Weise kann ein Prozeß auf den Inhalt einer Datei zugreifen, ohne einen Lese- oder Schreibsystemaufruf durchzuführen. Das Lesen und Schreiben einer Datei wird durchgeführt, aber es wird vom virtuellen Speichermanager als Antwort auf die Lade- und Speicheroperationen der Prozesse durchgeführt, die gegen die Adressen in ihrem Adreßraum ausgeführt werden, in den die Datei abgebildet worden ist. Zum Beispiel kann eine kurze Datei von 100 Byte in einen Adreßbereich von 4800 bis 4899 abgebildet werden. Wenn der Prozeß ein Byte vom Speicherplatz 4805 laden würde, würde der Prozeß das Byte am Offset 5 in der Datei erhalten. Wenn der Prozeß eine Speicheroperation in den Speicherplatz 4800 vornehmen würde, würde der Prozeß den Inhalt des Bytes am Offset 0 ändern, d.h. des ersten Bytes der Datei. Dadurch kann ein Prozeß ohne Lese- oder Schreibsystemaufrufe auf den Inhalt der Datei zugreifen und ihn ändern.
Wie in Fig. 2B veranschaulicht ist, könnte eine Speicheroperation in ein Speichersegment 91, das eine abgebildete Datei 92 enthält, die Datei 92 erweitern, aber die Dateisystemlogik 93 wird nicht für jede Speicheroperation aufgerufen. Wenn eine Anwendung 94 eine Datei abbildet und die Datei mit Speicheroperationen erweitert, wird das Dateigrößenattribut in der Dateiindex-Datenstruktur 95 daher nicht synchron aktualisiert. In einem bestimmten Moment entspricht die vom Dateisystem angenommene Größe der Datei (die Größe, die im Dateiindex gespeichert ist) aufgrund der jüngsten Speicheroperationen im virtuellen Speicher möglicherweise nicht dem aktuellen Stand. Der Dateiindex 95, der eine Datenstruktur ist, die Informationen für die Datei 92 enthält, wird durch Systemaufrufe wie beispielsweise sync, fsync, dose und durch periodische, vom Betriebssystem 96 ausgeführte Synchronisationsoperationen auf den aktuellen Stand gebracht. Wenn eine Datei durch herkömmliche Systemaufrufe (z.B. Schreibsystemaufrufe) geändert wird, wird die Dateisystemlogik 93 aufgerufen, und sie verwendet abgebildete Dateispeicheroperationen, um die Daten der Datei zu aktualisieren. Die Dateisystemlogik 93 weiß anhand der Parameter des Systemaufrufs, welche Änderungen gerade an der Datei vorgenommen werden und aktualisiert somit synchron die in der Dateiindex- Datenstruktur 95 festgestellte Dateigröße. Der Systemaufruf "stat" gibt den aktuellen Wert der Dateiindex-Dateigröße zurück; er fragt den virtuellen Speichermanager 97 nicht ab. Das Ergebnis ist, daß sich die Dateigröße, die in der Dateiindex- Datenstruktur 95 festgestellt und von "stat" zurückgegeben wird, immer auf dem neuesten Stand befindet, wenn an einer Datei 92 ausschließlich von Systemaufrufen Operationen ausgeführt werden. Wenn an der Datei jedoch Öperationen von abgebildeten Speicheroperationen ausgeführt werden, spiegelt die von "stat" zurückgegebene Dateigröße gegebenenfalls nicht die Ergebnisse der jüngsten Speicheroperationen wider. Die Anwendungen 94, die abgebildete Zugriffe (anstelle von Systemaufrufen) verwenden, können fsync ausgeben, wenn sie sicherstellen möchten, daß ein nachfolgender "stat" ihre jüngsten Änderungen widerspiegelt. Wenn eine Anwendung eine Datei 92 mit Speicheroperationen (im Gegensatz zu Systemaufrufen) erweitert, weiß der virtuelle Speichermanager 97, welche Seite die "äußerste rechte" Seite der Datei ist, er weiß aber nicht, welches Byte innerhalb dieser Seite das letzte Byte der Datei hält. Bei Verwendung von Systemaufrufen kennt das Dateisystem jedoch mit Byte-Auflösegenauigkeit die Größe der Datei.
In einer verteilten Umgebung, wie sie in Fig. 1 gezeigt ist, gibt es zwei Möglichkeiten, wie das Verarbeitungssystem 10C im lokalen Knoten C die Datei 5A vom Knoten A lesen könnte. Bei einer Möglichkeit könnte das Verarbeitungssystem 10C die ganze Datei 5A kopieren und sie dann lesen, als wäre sie eine lokale Datei 5C, die sich am Knoten C befindet. Das Lesen einer Datei auf diese Weise verursacht ein Problem, wenn ein anderes Verarbeitungssystem 10A an einem anderen Knoten A die Datei 5A ändert, nachdem die Datei 5A am Knoten C als die Datei 5C kopiert worden ist. Das Verarbeitungssystem 10C hätte keinen Zugriff auf diese neuesten, an der Datei 5A vorgenommenen Änderungen.
Eine andere Möglichkeit für das Verarbeitungssystem 10C, auf eine Datei 5A am Knoten A zuzugreifen, ist, einen Block, z.B. N1, zu einem Zeitpunkt zu lesen, zu dem das Verarbeitungssystem am Knoten C ihn benötigt. Ein Problem bei diesem Verfahren ist, daß jede Leseoperation über die Netzwerk-Übertragungsleitung 3 zum Knoten A gehen muß, an dem sich die Datei befindet. Das Senden der Daten für jede aufeinanderfolgende Leseoperation ist zeitaufwendig.
Der Zugriff auf Dateien über ein Netzwerk stellt zwei konkurrierende Probleme dar, wie oben veranschaulicht ist. Bei einem Problem spielt die Zeit eine Rolle, die bei aufeinanderfolgenden Lese- und Schreiboperationen zur Übertragung von Daten über das Netzwerk notwendig ist. Wenn die Dateidaten im Knoten gespeichert werden, um den Netzwerkverkehr zu verringern, geht andererseits möglicherweise die Dateiintegrität verloren. Wenn einer der vielen Knoten beispielsweise auch in die Datei schreibt, greifen die anderen Knoten, die auf die Datei zugreifen, gegebenenfalls nicht auf die neuesten, aktualisierten Daten zu, die soeben geschrieben worden sind. Als solches ist die Dateiintegrität verloren, da ein Knoten eventuell auf falsche und veraltete Dateien zugreift.
Zusätzlich zu der Schwierigkeit, die zu einer Datei gehörenden Daten in einer verteilten Umgebung zu verwalten, gibt es das Problem, die Attribute einer Datei, auf die zugegriffen wird, in einer verteilten Verarbeitungsumgebung zu verwalten. Dateien haben drei wichtige Attribute, die sich häufig ändem die Dateigröße, der Zeitpunkt der letzten Änderung und der Zeitpunkt des letzten Zugriffs auf die Datei. Jedesmal, wenn ein Prozeß Daten an das Ende einer Datei anfügt, ändert sich die Dateigröße zusammen mit dem Zeitpunkt der letzten Änderung und dem Zeitpunkt des letzten Zugriffs. Jedesmal, wenn eine Datei von einem Prozeß gelesen wird, ändert sich der Zeitpunkt des letzten Zugriffs.
Eine Möglichkeit, diese Informationen präzise zu verwalten, ist die Verwaltung der Informationen am Dateiserver. Jedesmal, wenn ein Client auf eine Datei zugreift oder eine Dateigröße ändert, sendet er eine Nachricht an den Server, in der er den Server über die Änderungen informiert. Jedesmal, wenn ein Client ein Attribut benötigt, sendet er eine Nachricht an den Server, in der er die Werte der Attribute anfordert. Diese Lösung verwaltet die richtigen Dateiattribute, jedoch zu sehr zu Lasten der Leistungsfähigkeit, da jedesmal, wenn eine Datei an einer beliebigen Client-Maschine gelesen oder geschrieben wird, Nachrichten an und vom Server gesandt werden müssen.
Wenn die Attribute an den Client-Maschinen aufbewahrt werden, haben der Server und andere Clients in der verteilten Umgebung andererseits nicht die richten Werte der Attribute. Da gegebenenfalls mehrere Clients gleichzeitig auf die Datei zugreifen, können bei den verschiedenen Clients zur selben Zeit nicht übereinstimmende Werte der Attribute vorhanden sein.
Eine weitere Komplikation kommt hinzu, indem man Prozessen erlaubt, Dateien auf ihren virtuellen Adreßraum abzubilden. Wenn dies geschieht, kann ein Prozeß den Inhalt einer Datei manipulieren, wobei er möglicherweise ihre Größe und den Zeitpunkt ändert, zu dem zuletzt auf sie zugegriffen oder sie geändert wurde, ohne einen Systemaufruf wie beispielsweise einen Lese- oder Schreibsystemaufzuf zu verwenden. Dieser Zugriff kommt durch Lade- und Speicheranweisungen zustande. Bei dieser Art von Situation hat das Betriebssystem keine Möglichkeit, den Zeitpunkt des letzten Zugriffs und die anderen Dateiattribute zu protokollieren, wie es sie bei Systemaufrufen hatte. In einer verteilten Umgebung, die es Prozessen erlaubt, ferne Dateien in ihren virtuellen Adreßraum abzubilden, gibt es diese Komplikationen genauso, wenn nützliche Dateiattribute verwaltet werden müssen.
In ACM Transactions on Computer Systems, Band 6, Nr. 1, Februar 1988, New York, USA, Seiten 51 bis 81, beschreiben Howard u.a. in ihrem Artikel "Scale and Performance in a Distributed File System" ein Verfahren zur Verwaltung von Dateiattributdaten in einem Datenverarbeitungssystem, das mehrere, über ein Übertragungsmedium miteinander verbundene Prozessoren umfaßt, wobei jeder Prozessor einen Dateispeicher hat und in bezug auf eine Datei Server und in bezug auf eine andere Datei Client sein kann, wobei das Verfahren folgendes umfaßt: Erfassen eines Bestands einer ersten Dateigröße einer Datei an ihrem Server; Verwalten eines Bestands einer zweiten Dateigröße der Datei an einem Client, der zur Änderung der Datei berechtigt ist; in bezug auf die Datei Verwalten eines Bestands an zusätzlichen Attributen einschließlich des Zeitpunkts der letzten Dateiänderung und des Zeitpunkts des letzten Dateizugriffs am Server; und Ändern des Bestands der zweiten Dateigröße am und durch den Client als Antwort auf die vom Client durchgeführte Änderung der Größe der Datei.
Gemäß der vorliegenden Erfindung wird nun ein Verfahren zur Verwaltung von Dateiattributdaten in einem Datenverarbeitungssystem bereitgestellt, das mehrere, über ein Übertragungsmedium miteinander verbundene Prozessoren umfaßt, wobei jeder Prozessor einen Dateispeicher hat und in bezug auf eine Datei Server und in bezug auf eine andere Datei Client sein kann, wobei das Verfahren folgendes umfaßt: Erfassen eines Bestands einer ersten Dateigröße einer Datei an ihrem Server; Verwalten eines Bestands einer zweiten Dateigröße der Datei an einem Client, der zur Änderung der Datei berechtigt ist; in bezug auf die Datei Verwalten eines Bestands an zusätzlichen Attributen einschließlich des Zeitpunkts der letzten Dateiänderung und des Zeitpunkts des letzten Dateizugriffs am Server; und Ändern des Bestands der zweiten Dateigröße am und durch den Client als Antwort auf die vom Client durchgeführte Änderung der Größe der Datei; dadurch gekennzeichnet, daß das Verfahren folgendes umfaßt: am Server Verknüpfen des Bestands der zweiten Dateigröße und des Bestands der ersten Dateigröße, um die neueste Dateigröße der Datei (5A) zu ermitteln; wobei der Änderungszeitpunkt der Datei verwaltet wird, indem der Server einen Änderungszählstand und einen entsprechenden Änderungszeitpunkt für die Datei protokolliert, der Client den Änderungszählstand erhöht, wenn der Client die Datei ändert, der Client den Änderungszählstand an den Server sendet, der Server den übermittelten Änderungszählstand mit dem protokollierten Änderungszählstand vergleicht, um festzustellen, ob die Datei geändert wurde, während der Client die Schreibberechtigung hatte, und der Server den entsprechenden protokollierten Änderungszeitpunkt auf den übermittelten Änderungszeitpunkt aktualisiert, wenn der Server anhand des Vergleichs feststellt, daß die Datei geändert wurde; und wobei die Zugriffszeit auf die Datei verwaltet wird, indem eine Client-Zugriffszeit in Verbindung mit einer dem Client vom Server erteilten Berechtigung zum Lesen der Dätei verwaltet wird, der Client die Client-Zugriffszeit erhöht, wenn der Client auf die Datei zugreift, der Client die entsprechende Client-Zugriffszeit in regelmäßigen Abständen an den Server übermittelt, der Server die übermittelte Client-Zugriffszeit mit einer aufgezeichneten Zugriffszeit, die vom Server verwaltet wird, vergleicht, um festzustellen, ob auf die Datei zugegriffen wurde, während der Client die Leseberechtigung hatte, und der Server die aufgezeichnete Zugriffszeit mit der übermittelten Client-Zugriffszeit aktualisiert, wenn der Server anhand des Vergleichs feststellt, daß auf die Datei zugegriffen wurde.
Eine solche Regelung ermöglicht es, Dateiattribute der Größe und, wie deutlich werden wird, darüber hinaus beispielsweise des Zeitpunkts der letzten Änderung und des Zeitpunkts des letzten Zugriffs so zu verwalten, daß die Dateiattribute tatsächlich präzise sind und an allen Clients in einer solchen verteilten Verarbeitungs umgebung zur Verfügung stehen, und sie wird als eine Regelung betrachtet, die dies ohne übermäßigen Aufwand, ohne übermäßige Leistungseinbuße und ohne übermäßigen Netzwerkverkehr tut.
Eine solche Regelung, die nachstehend beschrieben ist, stellt ein Protokoll bereit, das es Prozessen in einer verteilten Umgebung gestattet, entweder durch Systemaufrufe, beispielsweise Lese- und Schreibsystemaufrufe, oder durch einen Mechanismus auf eine Datei zuzugreifen, der die Datei auf ihren eigenen Adreßraum abbildet, so daß die Attribute der Dateien wirksam und präzise an alle interessierten Prozesse verteilt werden.
Die Attribute der Datei, wie zum Beispiel das Attribut Dateigröße, das Attribut Änderungszeitpunkt und das Attribut Zeitpunkt des letzten Zugriffs, werden jeweils getrennt und unabhängig von jedem der anderen Attibute in der verteilten Umgebung verwaltet.
Das Attribut Dateigröße wird auf die folgende Weise verwaltet. Clients, die Lese- oder Schreibsystemaufrufe ausführen, erhalten dazu vom Server der Datei die Berechtigung, indem sie eines der Lesetoken der Datei oder das Schreibtoken der Datei anfordem. Zusätzlich zur Erteilung der Berechtigung, die Operation an der Datei auszuführen, enthalten die Token auch die aktuelle Größe der Datei. Da nur jeweils ein Client das Schreibtoken haben kann, können nur Prozesse am Client mit dem Schreibtoken in die Datei schreiben, die Dateigröße kann im Schreibtoken festgehalten werden. Änderungen an der Dateigröße aufgrund von Schreibsystemaufrufen können durch Aktualisierung der im Schreibtoken festgehaltenen Größe angezeigt werden.
Prozesse, die auf die Datei zugreifen, indem sie die Datei in ihren eigenen virtuellen Adreßbereich abbilden, können die Datei erweitern und ihre Größe ändern, ohne das Schreibtoken zu erwerben. Diese Änderungen an der Größe der Datei werden in regelmäßigen Abständen an den Server übertragen, um sicherzustellen, daß die Größenangabe der Datei, die der Server hat, nie zu überholt ist. Wenn irgendein Prozeß im Netzwerk an der Dateigröße interessiert ist, sendet der Prozeß eine get_ attr-Nachricht an den Server, der dann den Knoten, der das Schreibtoken hat, fragt und dies mit den Informationen verknüpft, die der Server von Clients hat, die Prozesse haben, welche die Datei durch Abbildung der Datei erweitert haben. Der Server gibt die Dateigröße an den anfordernden Client zurück, welche die besten verfügbaren Informationen über die aktuelle Größe der Datei widerspiegelt.
Die Verwaltung des Änderungszeitpunkts und des Zugriffszeitpunkts wird auf eine Weise vorgenommen, die ähnlich der Verwaltung des Attributs Dateigröße ist, wie bereits beschrieben wurde. Diese Attribute werden in den Schreib- und Lesetoken festgehalten.
Hinsichtlich des Attributs Änderungszeitpunkt wird das Schreibtoken dazu verwendet, dieses Attribut nach den folgenden Regeln zu verwalten. Der Server protokolliert den Änderungszählstand für die Datei. Wenn der Client das Schreibtoken erhält, erhält er auch den Änderungszählstand. Wenn ein Client die Datei ändert, erhöht der Client den Änderungszählstand. Wenn ein Server feststellen möchte, ob eine Datei geändert wurde, sendet der Server eine besondere Token-widerrufen-Nachricht, die den Client veranlaßt, den Änderungszählstand an den Server zurückzusenden. Der Server vergleicht den Änderungszählstand vom Client (der vielleicht erhöht worden ist) mit dem Änderungszählstand am Server, um festzustellen, ob die Datei geändert worden ist, während der Client das Schreibtoken hatte. Wenn der Server feststellt, daß die Datei geändert worden ist, setzt der Server den Änderungszeitpunkt auf den aktuellen Zeitpunkt.
Es ist weniger kritisch, daß ein Client weiß, wann das letzte Mal auf eine Datei zugegriffen wurde. Da viele Clients das Lesetoken haben können, wäre es zu mühsam, jeden Client, der das Lesetoken hat, nach dem Zeitpunkt seines letzten Zugriffs zu fragen. Statt dessen fragt der anfordernde Client nur den Server nach dem Zeitpunkt des letzten Zugriffs durch einen Client ab. Der Server kann den Zeitpunkt des letzten Zugriffs feststellen, weil die Clients, die das Lesetoken haben, den Server in regelmäßigen Abständen über jeden Zugriff auf die Datei informieren müssen.
Die vorliegende Erfindung wird anhand eines Beispiels mit Bezug auf ein Umgebungsverarbeitungssystem und die Einzelheiten der Regelungen nach dem Stand der Technik und anhand einer bestimmten Ausführungsform der Erfindung, wie sie in den Begleitzeichnungen veranschaulicht ist, weiter beschrieben, in denen:
Fig. 1 ein Blockdiagramm des verteilten Umgebungsdatenverarbeitungssystems ist, auf das Bezug genommen wird;
Fig. 2A ein Blockdiagram ist, das ein eigenständiges, in der Technik bekanntes Datenverarbeitungssystem zeigt, um durch Systemaufrufe auf eine Datei zuzugreifen;
Fig. 2B ein Blockdiagramm ist, das ein eigenständiges, in der Technik bekanntes Datenverarbeitungssystem und den Zugriff auf eine abgebildete Datei zeigt;
Fig. 3 ein Flußdiagramm des Datenverarbeitungssystems von Fig. 2A ist, das über einen Systemaufruf auf eine Datei zugreift;
Fig. 4A die Datenstruktur einer f_sync-Nachricht ist, um die Dateiinformationen am Server mit den Dateiinformationen am Client zu synchronisieren;
Fig. 4B die Datenstruktur einer get_attr-Nachricht ist, um die Attribute einer Datei anzufordern;
Fig. 4C eine Datenstruktur einer get_bytes-Nachricht ist, um Datenbytes von einer Datei anzufordern;
Fig. 4D eine Datenstruktur einer get_tkn-Nachricht ist, um eine Berechtigung, die Datei zu lesen oder die Datei zu lesen und in sie zu schreiben, anzufordern;
Fig. 4E eine Datenstruktur der put_bytes-Nachricht ist, um geänderte Bytes vom Client-Datenverarbeitungssystem an das Server-Datenverarbeitungssystem zurückzusenden;
Fig. 4F eine Datenstruktur der revoke_bytes-Nachricht ist, um die Bytes, die zuvor in der Antwort auf eine get_ bytes-Nachricht gesandt wurden, zu widerrufen;
Fig. 4G eine Datenstruktur der revoke_tkn-Nachricht ist, um das Token, das eine Berechtigung zum Lesen der Datei erteilt, zu widerrufen oder um das Token, das eine Berechtigung, die Datei zu lesen und in sie zu schreiben erteilt, zu widerrufen;
Fig. 4H eine Datenstruktur der sync_attr-Nachricht ist, um die Attribute der Datei in regelmäßigen Abständen während einer an den Attributen der Datei ausgeführten Synchronisationsoperation vom Client an den Server zurückzusenden;
Fig. 4I eine Datenstruktur der Abschlußnachricht ist, um den Server über eine Abschlußoperation an der Datei zu informieren;
Fig. 5 ein Client-Datenverarbeitungssystem und ein Server- Datenverarbeitungssystem in dem verteilten Datenverarbeitungssystem zeigt;
Fig. 6A ein Flußdiagramm der Reihenfolge der Zwischenknotennachrichten ist, wenn zwei Clients die Schreibberechtigung für dieselben Daten anfordern;
Fig. 6B ein Flußdiagramm ist, wenn ein Client die Attribute einer Datei anfordert, in der ein anderer Client Änderungen vornimmt;
Fig. 6C ein Flußdiagramm ist, das den Server zeigt, der die neuesten Dateiattribute verwaltet, wenn ein Client die Lese- oder die Schreib-/Leseberechtigung für die Datei und ein anderer Client die Attribute der Datei anfordert;
Fig. 6D ein Flußdiagramm ist, das die Operationen am Server zeigt, die bewirken, daß die am Server gespeicherte Dateigröße in Übereinstimmung mit der äußersten rechten Seite des virtuellen Speichermanagers gebracht wird, wobei die neuesten Dateiattribute am Server verwaltet werden, wenn Clients entweder durch Systemaufrufe oder durch einen abgebildeten Zugriff in die Datei schreiben;
Fig. 7A ein Flußdiagramm ist, das die Ereignisse zeigt, die den Server veranlassen, den Änderungszeitpunkt der Datei zu aktualisieren; und
Fig. 7B ein Flußdiagramm ist, das den Server zeigt, der den neuesten Änderungszeitpunkt der Datei verwaltet, wenn ein Client in die Datei schreibt.
Figur 4A zeigt die f_sync-Nachricht 420, die dazu dient, den Kenntnisstand des Servers über die Datei mit dem des Clients zu synchronisieren. Als Antwort auf eine f_sync-Nachricht von einem Client führt der Server eine f_sync-Operation aus. Die f_sync-Operation veranlaßt den Server, alle geänderten, aber ungeschriebenen Daten auf die Platte am Server zu schreiben. Dazu widerruft der Server jedes ausstehende Dateitoken, widerruft die zu der Datei gehörenden Datenbytes auf allen Client- Maschinen und führt dann die lokale f_sync-Operation an dem Server aus, der die Übertragung der geänderten Datenbytes auf die Platte erzwingt. Der Server führt die f_sync-Operation nur aus, wenn der Client die Datei zuvor zum Schreiben geöffnet und noch nicht geschlossen hat. Der Operationscode 421, 423 gibt die Operation an, die ausgeführt wird. Der Wert des Operationscodes hängt bei jeder einzelnen Operation von der Nachricht ab. Die Dateikennung 422 ist ein Wert, der eine Datei, die sich auf der Server-Maschine befindet, eindeutig kennzeichnet. Der Rückkehrcode 424 ist ein Wert, der den Erfolg oder das Scheitern der angeforderten Operation angibt.
Figur 4B zeigt die get_attr-Nachricht 430, welche die Attribute einer Datei abruft. Die Dateiattribute 435 enthalten die Informationen über die Datei einschließlich des Zugriffszeitpunkts 436, des Änderungszeitpunkts 437 und der Dateigröße 438.
Fig. 4C zeigt die get_bytes-Nachricht 440, die Datenbytes von einer Datei anfordert. Der Offset 441 ist der Offset in der Datei, der den Beginn der angeforderten Daten markiert. Die Länge 442 ist die Anzahl der angeforderten Bytes. Das Schreib-/Lesemarkierungszeichen (rw_flag) 443 dient zur Anzeige, daß der Client eine Nur-Lese-Kopie der Daten oder eine beschreibbare Kopie der Daten anfordert. Die zulässigen Werte von rw_flag sind 0x0000, wenn der Client nur vom Bytebereich liest, und 0x0001, wenn der Client die Bytes ändern kann. Der Server führt die get_bytes-Operation nur aus, wenn der Client-Knoten die Datei zuvor in einem kompatiblen Modus geöffnet und noch nicht geschlossen hat. Wenn das rw_flag 443 den Nur-Lese-Modus anzeigt, muß der Client die Datei geöffnet haben. Wenn das rw_flag 443 den Schreib-/Lesemodus anzeigt, muß der Client die Datei zum Schreiben geöffnet haben.
In der Antwort auf die get_bytes-Nachricht 440 ist der FN&submin;Offset 444 der Offset in der Datei, für welche die Bytes angefordert wurden, für den es freiwerdende Nullen gibt. Freiwerdende Nullen sind in der ebenfalls anhängigen Anmeldung S.N. (IBM-interne Verzeichnisnummer AT9-89-029) beschrieben. Dieses Feld ist nur dann von Bedeutung, wenn das Feld FN_Länge größer null ist. Das Feld FN Länge 445 ist die Byte-Zahl der freiwerdenden Nullen, die beim Offset FN&submin;Offset 444 beginnen, den der Server zur Rückgabe an den Anfordernden auswählt. Der Server kann sich immer dafür entscheiden, keine freiwerdenden Nullen zu verarbeiten und zeigt dies an, indem er in diesem Feld null zurückgibt. Die Länge 446 ist die Länge der zurückgegebenen Daten. Die Daten 447 sind die aktuell angeforderten Datenbytes.
Fig. 4D zeigt die get_tkn-Nachricht 450, die von einem Client verwendet wird, um ein Token vom Server anzufordern. Token_Typ 451 gibt die Token-Art an, die angefordert wird. Zulässige Werte sind 0x0001, wenn ein Nur-Lese-Token angefordert wird; und 0x0002, wenn ein Schreib-/Lesetoken angefordert wird. Der Server führt die get_tkn-Operation nur aus, wenn der Client-Knoten die Datei zuvor in einem kompatiblen Modus geöffnet und noch nicht geschlossen hat. Die Dateigröße 452 ist die Größe der Datei. Der Änderungszählstand 453 ist ein vom Server verwalteter Wert, der an einer Datei vorgenommene Änderungen widerspiegelt. Der Zugriffszählstand 454 ist ein vom Server verwalteter Wert, der die Zugriffe auf die Datei widerspiegelt.
Fig. 4E zeigt die put_bytes-Nachricht 460. Mit der put_bytes- Nachricht 460 sendet der Client geänderte Daten an den Server zurück. Der Server führt die put_bytes-Operation nur aus, wenn der Client die Datei zuvor zum Schreiben geöffnet und noch nicht geschlossen hat. Der Offset 461 ist der Offset in der Datei, an den die Datenbytes 463 der Länge 462 gestellt werden sollten.
Fig. 4F zeigt die revoke_bytes-Nachricht 470. Diese Nachricht wird vom Server einer Datei an einen Client gesandt, um die Bytes zu widerrufen, die dem Client zuvor in der Antwort auf eine get_bytes-Nachricht 440 gegeben wurden. Der Client sendet die Antwort erst, nachdem er für den vom Offset 471 und der Länge 472 angegebenen Bytebereich alle unveränderten, zwischengespeicherten Daten und freiwerdenden Nullen gelöscht und alle geänderten Daten auf den Server geschrieben und Antworten erhalten hat. Wenn der Client die Antwort sendet, darf er keine zwischengespeicherten Daten für den widerrufenen Bytebereich haben. Diese Nachricht entzieht dem Client das Recht, zuvor zurückgegebene, freiwerdende Nullen, die in den Widerrufsbereich fallen, zu verwenden. Jedwede Daten oder freiwerdende Nullen innerhalb des widerrufenen Bytebereichs, die von get_bytes- Anforderungen zurückgegeben wurden, welche ausstanden, als eine revoke_bytes-Nachricht verarbeitet wurde, müssen bei ihrer Ankunft gelöscht werden. Der Client kann sich dafür entscheiden, einen größeren Bytebereich als angefordert zu widerrufen, oder er kann bestimmen, daß er in einem größeren als dem angeforderten Bereich nichts zu widerrufen hat. In solchen Fällen zeigen Offset_beantworten 473 und Länge_beantworten 474 einen Bereich an, für den der Client keine zwischengespeicherten Seiten hat. Offset_beantworten 473 und Länge_beantworten 474 müssen mindestens den vom Offset 471 und der Länge 472 angegebenen Bereich enthalten.
Fig. 4G zeigt die revoke_tkn-Nachricht 480. Diese Nachricht wird von einem Server an einen Client gesandt, um das Token zu widerrufen, das der Client als Antwort auf die get_token- Nachricht 450 empfangen hat. Zurückbleibender_Token_Typ 481 gibt die Art des Tokens an, das beim Client zurückgelassen werden soll. Zulässige Werte sind:
read_tkn 0x0001: Der Client behält ein Nur-Lese-Token; write_tkn 0x0002: Der Client behält ein Schreib-/Lesetoken; no_tkn 0x0000: Der Client behält kein Token. Die Dateigröße 482 ist die Größe der Datei aus der Sicht des Clients nach vorgenommenen Änderungen an den Daten.
Um zwischen dem Server und dem Client Irritationen über den Zustand des Systems zu vermeiden, muß folgende Regel befolgt werden. Die Verarbeitung der revoke_tkn-Nachricht 480 für eine Datei am Client wird solange verzögert, bis die Antwort auf eine aus-stehende get_tkn-Nachricht 450 für diese Datei verarbeitet worden ist.
Fig. 4H zeigt die sync_attr-Nachricht 490. Diese Nachricht führt die Synchronisationsoperation an den Attributen einer Datei aus. Token_Typ 491 gibt die Art des Tokens an, das der Client besitzt. Die folgenden sind zulässige Werte:
read_tkn 0x0001: Der Client behält ein Nur-Lese-Token.
write_tkn 0x0002: Der Client behält ein Schreib-/Lesetoken.
Dateigröße anfordern 493 ist die Dateigröße am Client. Dateigröße beantworten 494 ist die Dateigröße am Server. Änderungszählstand beantworten 495 gibt die am Server aufgezeichneten Änderungen wieder. Zugriffszählstand beantworten 496 gibt die am Server aufgezeichneten Zugriffe wieder. Um zwischen dem Server und dem Client Irritationen über den Zustand des Systems zu vermeiden, muß folgende Regel befolgt werden. Get_ tkn-Operationen und sync_attr-Operationen werden am Client parallel-seriell umgesetzt. Eine get_tkn-Anforderung für eine bestimmte Datei kann nicht ausgegeben werden, solange eine sync_attr für diese Datei aussteht.
Fig. 4I zeigt die Abschlußnachricht 410, die von Clients verwendet wird, um den Server über Abschlußoperationen zu informieren. Der Änderungszählstand 411 ist ein Wert, der Änderungen am Client widerspiegelt. Der Zugriffszählstand 412 ist ein Wert, der Zugriffe am Client widerspiegelt.
Bei der in Fig. 5 gezeigten Anordnung wird anstelle der herkömmlichen Kernel-Puffer 12, wie in Fig. 2A gezeigt, ein virtueller Speichermanager 33 zur Verwaltung von zwischengespeicherten Dateidaten verwendet. Außerdem ermöglicht er es, daß Dateien in die virtuellen Speichersegmente 35 einer Anwendung 34 abgebildet werden. Diese bevorzugte Ausführungsform vermeidet jedoch eine starke Verflechtung der Dateisystemlogik 36 mit der virtuellen Speichermanager-Logik 33. Während Synchronisations und f_Synchronisationsoperationen, der periodischen Synchronisation des Dateisystems (bei denen es sich um Systemaufrufe des AIX-Betriebssystems handelt, wie in AIX Operating System Technical Reference, Bestellnummer SV21-8009 und Teilenummer 74X9990, September 1986, beschrieben ist, das durch Bezugnahme Bestandteil hiervon ist, die aber auch für Systemaufrufe anderer Betriebssysteme gelten, die bewirken, daß alle Informationen im Speicher, die sich auf Platte oder im permanenten Speicher befinden sollten, ausgeschrieben werden), und dem letzten Schließen einer Datei wird die Dateigröße in der Dateiindex- Datenstruktur 26 gemäß der folgenden Regel festgelegt:
Wenn die Dateiindex-Dateigröße in der äußersten rechten Seite enthalten ist, bleibt die Dateiindex-Dateigröße, wie sie ist. Ändernfalls wird die Dateiindex-Dateigröße auf das Ende der äußersten rechten Seite gesetzt.
Die Attribute Dateiindex-Zugriffszeit und -Änderungszeitpunkt sind ähnlich lose mit der jüngsten Aktivität des virtuellen Speichers verbunden.
Mit Bezug auf die Figuren 5 und 6A können Clients 30 die Datei 25 erweitern, indem sie Daten über das Dateiende hinaus speichern. Wenn am Client am Speicherplatz keine Seite in der Datei vorhanden ist, ist der Client gezwungen, die Däten für die Seite abzurufen, indem er eine get_bytes-Anforderung 440 an den Server ausgibt. Die get_bytes-Anforderung 440 gibt einen Datenblock zurück, der in die Seite eingefügt wird, und die Speicheroperation geht in den Seiteninhalt. Clients können auch hinter dem Dateiende einen reservierten Speicherbereich haben. Speicheroperationen in diesen reservierten Speicherbereich machen es nicht erforderlich, daß eine get_bytes-Anforderung an den Server ausgegeben wird. Wenn ein Client am Ende einer Datei eine get_bytes-Anforderung 440 ausgibt, Schritte 601, 602, kann der Server eine Meldung 444, 445 (Fig. 4C), Schritt 603, zurückgeben, daß der Client hinter dem Dateiende Speicherbereich reservieren kann, Schritte 604, 605. Dieser reservierte Speicherbereich wird als freiwerdende Nullen bezeichnet. Wenn der Client eine Speicheroperation in diese freiwerdenden Nullen ausführt, nimmt die Größe der Datei zu, Schritt 606. Der Server 20 merkt das Wachstum der Datei erst, wenn der Client eine put_bytes-Nachricht 460 (Fig. 4E) ausgibt, um die Daten auf den Server zurückzuschreiben, Schritte 610, 611. Es sei erwähnt, daß der Client einseitig beschließen kann, die Daten zurückzuschreiben, oder er kann durch eine revoke_bytes-Nachricht 470 (Fig. 4F), die der Client 30 vom Server 20 erhält, Schritte 608, 609, dazu angewiesen werden, weil ein anderer Prozeß dieselben Daten angefordert hat, Schritt 607. Dieser andere Prozeß darf diese Daten benutzen, nachdem die Antwort auf die revoke_bytes-Anforderung 470 am Server angekommen ist, Schritte 614, 615. Der Client 30 sendet die revoke_bytes-Antwort 470 im Schritt 614 erst, nachdem er die put_bytes-Antwort 460 in den Schritten 612, 613 empfangen hat.
Bezug nehmend auf Fig. 6B, wenn ein Client eine stat-Operation ausführt, um die Attribute einer Datei abzufragen, bewirkt die stat-Operation, daß eine get_attr-Anforderung 430 an den Server der Datei gesandt wird. Eines der Elemente in der Struktur, die von get_attr zurückgesandt wird, ist die Dateigröße 436 (Fig. 4B). Betrachten wir das folgende Szenario:
1. Client A hat eine get_bytes-Antwort 440 empfangen und am Ende der Datei eine Speicheroperation in freiwerdende Nullen ausgeführt, Schritte 616, 617, 618. Der Client hat die neuen Dateidaten nicht an den Server zurückgesandt.
2. Client B gibt eine get_attr-Anforderung 430 für die Datei aus, Schritte 619, 620.
Wenn äußerste Korrektheit gefordert wäre, müßte der Server eine revoke_bytes-Anforderung 470 an den Client A ausgeben, Schritte 621, 622, um festzustellen, ob eine Speicheroperation in freiwerdende Dateiende-Nullen ausgeführt wurde, bevor er auf die get_attr-Anforderung 430 des Clients A antwortet, Schritte 629, 630. Da man die Dateigröße 436 (Fig. 4B), die in der get_attr- Antwort 430 zurückgesandt wird, benötigt, um die jüngsten Speicheroperationen des Client, wie vorstehend beschrieben wurde, präzise widerzuspiegeln, bringt dies eine doppelte Leistungseinbuße mit sich:
1. Eine get_attr-Anforderung kann in den Schritten 629, 630 erst beantwortet werden, nachdem in den Schritten 621, 622 eine revoke_bytes-Anforderung 470 ausgegeben und in den Schritten 627, 628 beantwortet worden ist.
2. In Beantwortung einer revoke_bytes-Anforderung muß ein Client gegebenenfalls eine oder mehrere put_bytes-Nachrichten 460 zurück an den Server ausgeben, Schritte 623, 624, und auf ihre Beantwortung warten, Schritte 625, 626.
Um diese Leistungseinbuße zu vermeiden und angesichts der Tatsache, daß sich die Größe einer Datei, die zum Schreiben geöffnet ist, wahrscheinlich sowieso ändert, erfordert es das Protokoll nicht, daß die Dateigröße 436, die von get_attr 430 zurückgegeben wird, die jüngsten Speicheroperationen des Clients widerspiegelt. Ein Server könnte realisiert werden, der eine revoke_bytes-Anforderung 470 ausgibt, bevor er auf get_attr 430 antwortet, aber Clients können sich nicht darauf verlassen, daß Server dies tun.
In Anbetracht der gelockerten Regeln für Clients, und um Serverausführungsoptionen zu ermöglichen, erfordert es das Protokoll nicht, daß die Dateigröße 436, die von get_attr 430 zurückgegeben wird, die jüngsten Speicheroperationen von Serverprozessen widerspiegelt. Und da ein Server Bytes, die von put_bytes 460 eingesandt wurden, und Bytes, die von lokalen Prozessen geschrieben wurden, wahrscheinlich ähnlich behandelt, erfordert es das Protokoll nicht, daß die Dateigröße 436, die von get_attr 430 zurückgegeben wird, die zuletzt empfangenen put_bytes widerspiegelt.
Das Protokoll erfordert folgendes:
1. Von Clients wird erwartet, daß sie in regelmäßigen Abständen über put_bytes 460 alle geänderten oder erstellten (d.h. freiwerdende Nullen, die eingespeichert wurden) Dateidaten einsenden. Von Clients wird auch erwartet, daß sie geänderte oder erstellte Daten einsenden, bevor sie die letzte Abschlußnachricht 410 für eine Datei senden.
2. Von Servern wird erwartet, daß sie die Dateigröße in der Dateiindex-Datenstruktur 26 (Fig. 5) in regelmäßigen Abständen aktualisieren, um neueste Aktivitäten von Serverprozessen und kürzlich empfangene put_bytes-Nachrichten 460 widerzuspiegeln.
3. Als Teil der Verarbeitung einer fsync-Anforderung wird von Servern erwartet, daß sie Daten von allen Clients widerrufen und die Dateigröße 436, die von get_attr 430 zurückgegeben wird, aktualisieren, um die zurückgesandten Daten und auch alle vorherigen Aktivitäten von Serverprozessen widerzuspiegeln.
Somit besteht ein Teil einer periodischen Synchronisationsoperation eines Client darin, geänderte Daten auf den Server zu schreiben, und ein Teil einer periodischen Synchronisationsoperation eines Servers besteht darin, lokale Änderungen und empfangene Client-Änderungen auf Platte zu schreiben. Sofern nicht ein anderes Ereignis eintritt, wie beispielsweise eine f_Synchronisationsoperation oder das letzte Schließen einer Datei, zeigt sich die von einem Client vorgenommene Änderung erst in der von get_attr 430 zurückgesandten Dateigröße 436, nachdem auf die periodische Synchronisationsoperation des Clients eine periodische Synchronisationsoperation des Servers gefolgt ist.
Ein Client organisiert seinen Dateidaten-Cache wahrscheinlich in Blöcken fester Größe. Betrachten wir das folgende Szenario:
1. Ein Client führt eine Speicheroperation in eine freiwerdende Dateiende-Null aus, wodurch die Dateigröße zunimmt.
2. Eine periodische Synchronisationsoperation am Client bewirkt, daß eine put_bytes-Nachricht an den Server gesandt wird.
In einer typischen Client-Ausführung wird der in der put_bytes- Nachricht 460 durch einen Offset 461 und die Länge 462 angegebene Bytebereich auf eine Client-Seite ausgerichtet. Der Bytebereich enthält das letzte Byte in der Datei, erstreckt sich in den meisten Fällen jedoch über dieses letzte Byte hinaus. Außerdem stimmt die Seitengröße des Servers gegebenenfalls nicht mit der des Clients überein. Wenn die put_bytes-Daten am Server ankommen, können sie daher in eine Serverseite gestellt werden, die über das letzte, in der Nachricht gesandte Datenbyte hinausgeht. Aufgrund dieser Quantisierung der Seitengröße kann der Server nicht genau wissen, welches Byte das Dateiende darstellt. Er kennt nur die Seite, die das letzte Byte enthält. Aus diesen Gründen macht es das Protokoll nur erforderlich, daß der Server die Dateigröße in der Dateiindex-Datenstruktur 26 in regelmäßigen Abständen aktualisiert, so daß sie die äußerste rechte Seite des Servers enthält. Das letzte Byte in der Datei kann zuvor über put_bytes 460 eingesandt oder von einem Serverprozeß erzeugt worden sein.
Wie vorstehend beschrieben wurde, können Clients die Größe einer Datei ändern, indem sie put_bytes-Nachrichten an den Server der Datei senden. Ein Client kann beim Ändern der Größe einer Datei eine genauere Kontrolle ausüben, indem er das Schreibtoken der Datei erwirbt.
Bezug nehmend auf Fig. 6C, wenn ein Client A eine get_tkn- Nachricht 450 zur Anforderung des Schreibtokens sendet, Schritte 631, 632, überträgt die Antwort, Schritte 633, 634, die Dateigröße 452 (Fig. 4D). Dies ist derselbe Größenwert 436, der in einer get_attr-Anforderung 430 zurückgesandt würde. Während der Client das Schreibtoken einer Datei besitzt, kann er die Größe der Datei ändern, Schritt 635. Die geänderte Größe wird in der Antwort auf eine revoke_tkn-Nachricht 480 oder in einer sync_attr-Nachricht 490 an den Server zurückgesandt. Die Regeln, welche die Dateigröße bestimmen, werden wie folgt beschrieben.
Wenn ein Server eine get_attr-Anforderung 430 empfängt, Schritte 636, 637, sendet er eine revoke_tkn-Nachricht 480, Schritte 638, 639, an den Client, der das Schreibtoken der Datei besitzt, sofern es einen solchen Client gibt. Diese revoke_tkn- Nachricht 480 weist den Client an, die aktuelle Größe der Datei in der Antwort zurückzusenden, Schritte 640, 641, aber sie bewirkt nicht, daß der Client das Eigentum am Token verliert (d.h. sie ist als ein nicht entziehender Widerruf markiert) Die zurückgegebene Dateigröße wird in den Dateiindex 26 (Fig. 5) gestellt, Schritt 642, und in der get_attr-Antwort zurückgesandt, Schritte 643, 644.
Mit Bezug auf Fig. 6D bewirken mehrere Operationen am Server, daß die im Dateiindex einer Datei gespeicherte Dateigröße in Übereinstimmung mit der Position der äußersten rechten Seite der Datei gebracht wird, die vom virtuellen Speichermananger verwaltet wird, Schritt 656. Die Dateigröße stimmt überein, wenn das resultierende Dateiende in die äußerste rechte Seite fällt. Zu diesen Synchronisationsereignissen gehören:
1. Der Server führt eine periodische Synchronisationsoperation der Datei aus, Schritt 651.
2. Der Server führt das letzte Schließen einer Datei aus, Schritt 652.
3. Der Server empfängt beliebige von mehreren Nachrichten, wie beispielsweise fsync, die ihn dazu veranlassen, den Kenntnisstand des Clients und des Servers über die Datei zu synchronisieren, Schritt 653.
4. Ein Serverprozeß führt beliebige von mehreren Operationen aus, wie beispielsweise fsync, die ihn dazu veranlassen, den Kenntnisstand des Clients und des Servers über die Datei zu synchronisieren, Schritt 654.
Wenn eines der vorstehenden Synchronisationsereignisse eintritt und wenn die Dateiindex-Dateigröße in der äußersten rechten Dateiseite des Servers enthalten ist oder sich rechts von der äußersten rechten Dateiseite befindet, Schritt 655, wird der Dateiindex-Wert so gelassen, wie er ist, Schritt 658. Ändernfalls wird die Dateiindex-Größe so angepaßt, daß das Dateiende am letzten Byte in der äußersten rechten Seite plaziert wird, Schritt 656.
Der Client könnte zwischengespeicherte Seiten, die er noch nicht an den Server gesandt hat, geändert haben. Folglich könnte sich die in der revoke_tkn-Nachricht 480 (Fig. 4E) zurückgesandte Dateigröße rechts von der äußerten rechten Seite des Servers befinden.
Ein Server aktualisiert die Dateigröße des Dateiindex, wenn er eine sync_attr-Nachricht (die von der periodischen Synchronisationsoperation eines Client ausgegeben wird) empfängt, Schritt 653, oder wenn er die Antwort auf eine revoke_tkn-Nachricht empfängt, Schritt 659.
Ein Client, der das Schreibtoken hat und mit Hilfe einer Schreiboperation eine Datei ändert, kann aufgrund eines Cache- Überlaufs die äußerste rechte Seite der Datei einsenden. Wenn der Server diese empfängt und dann eine periodische Synchronisationsoperation ausführt, Schritt 651, überträgt er die Dateigröße an das Ende dieser Seite, Schritt 656, wenn diese Seite über die aktuelle Aufzeichnung der Dateigröße des Servers hinausgeht, was im Schritt 655 festgestellt wird. Wenn der Client die Dateigröße aufgrund einer revoke_token-Anforderung, Schritt 659, einer sync-_attr- Anforderung oder einer fsync-Anforderung, Schritt 653, anschließend einsendet, wird gegebenenfalls festgestellt, daß sich die Dateigröße des Dateiindex innerhalb der äußersten rechten Seite, die dem Server bekannt ist, befindet, Schritt 655, und wird deshalb dort gelassen, Schritt 658. Man beachte, daß diese Operation dazu führen kann, daß sich die Dateigröße von ihrem Wert "Ende der äußersten rechten Seite" verringert.
In der bevorzugten Ausführungsform wird davon ausgegangen, daß ein Client-Prozeß, der mit herkömmlichen Schreibsystemaufrufen Operationen an einer Datei ausführt, das Schreibtoken erwirbt und die Dateigröße während der Verarbeitung der Schreiboperationen aktualisiert. Wenn er dies macht, ist die Dateigröße, die von get_attr zurückgegeben wird, immer auf dem neuesten Stand. Ein Client kann über einen abgebildeten Zugriff Operationen ausführen, indem er nur get_bytes und put_bytes ausgibt, ohne das Schreibtoken der Datei zu erwerben. In diesem Fall befindet sich die Dateigröße, die von get_attr zurückgegeben wird, am Ende der Seite des virtuellen Speichers des Servers, die das äußerste rechte Byte enthält, und nur die Client-Daten, die vor der jüngsten periodischen Synchronisationsoperation des Servers auf den Server geschrieben wurden, schlagen sich in der Größe nieder.
Obwohl ein Client, der das Schreibtoken besitzt, der einzige Knoten ist, der die Größe der Datei durch Systemaufrufe ändern darf, erlaubt ein abgebildeter Zugriff auf die Datei anderen Clients oder dem Server, die Größe der Datei durch direkte Speicherreferenzen zu ändern. Um alle Clients, welche die Datei benutzen, hinsichtlich der Dateigröße einigermaßen auf dem aktuellen Stand zu halten, senden alle Clients, welche die Datei benutzen, mit der sync-attr-Nachricht 490 in regelmäßigen Abständen Attributinformationen über die Datei an den Server. Die aktuell berechnete Dateigröße vom Server wird in der Antwort auf die sync_attr-Nachricht 490 zurückgesandt. Somit wird eine Änderung der Größe der Datei an einem Client an den Server weitergegeben, wenn dieser Client seine sync_attr-Nachricht ausführt, und sie wird an die anderen Clients, welche die Datei benutzen, weitergegeben, wenn jeder von ihnen eine nachfolgende sync_attr-Nachricht 490 für die Datei ausführt.
Die Verwaltung des Änderungszeitpunkts einer Datei, wie er durch einen Systemaufruf zur Abfrage der Attribute der Datei, z.B. einen Systemaufruf "stat", zurückgesandt wird, ist im großen und ganzen analog zur Verwaltung der Größe der Datei. Wenn ein Client ausschließlich durch put_bytes Operationen ausführt, ohne das Schreibtoken der Datei zu erwerben, werden seine Dateiänderungen schließlich, aber nicht sofort, im Änderungszeitpunkt widergespiegelt, der durch Systemaufrufe, die am Server oder an anderen Clients ausgeführt werden, zurückgegeben wird.
Einem Client, der das Schreibtoken der Datei erwirbt und ordnungsgemäß verwaltet, kann jedoch zugesichert werden, daß der durch Systemaufrufe am Server oder an anderen Clients zurückgegebene Änderungszeitpunkt Änderungen an der Datei, die von diesem Client vorgenommen wurden, korrekt widerspiegelt.
Bezug nehmend auf Fig. 7A, veranlassen mehrere Ereignisse den Server zur Durchführung einer Prüfung, um festzustellen, ob Dateländerungen im Dateiänderungszeitpunkt widergespiegelt werden müssen. Zu diesen Synchronisationsereignissen gehören die folgenden:
1. Der Server führt eine periodische Synchronisationsoperation der Datei aus, Schritt 701.
2. Der Server führt das letzte Schließen einer Datei aus, Schritt 702.
3. Der Server empfängt beliebige von mehreren Nachrichten, wie beispielsweise _fsync, die ihn dazu veranlassen, den Kenntnisstand des Clients und des Servers über die Datei zu synchronisieren, Schritt 703.
4. Ein Serverprozeß führt beliebige von mehreren Operationen aus, wie beispielsweise _fsync, die ihn dazu veranlassen, den Kenntnisstand des Clients und des Servers über die Datei zu synchronisieren, Schritt 704.
Wenn eines der Synchronisationsereignisse eintritt, führt der Server eine Prüfung durch, um festzustellen, ob er eine put_bytes-Nachricht empfangen hat oder seit dem letzten Synchronisationsereignis einen lokalen Prozeß Daten in die Datei speichern ließ, Schritte 705, 709. Wenn ja, wird der Änderungszeitpunkt der Datei auf den aktuellen Zeitpunkt des Servers aktualisiert, Schritt 706.
Wenn sich ein Client dafür entscheidet, eine Datei über put_bytes zu ändern, ohne auch das Schreibtoken der Datei zu besitzen, kann es zu folgendem Szenario kommen:
1. Client A öffnet eine Datei und ruft über get_bytes einige Daten ab.
2. Prozesse am Client A führen eine Speicheroperation in die abgerufenen Daten aus.
3. Ein Prozeß am Client B gibt eine get_attr-Anforderung für die Datei aus.
4. Da der Client A das Schreibtoken nicht angefordert hat, werden keine Nachrichten vom Server an den Client A gesandt.
5. Der Server weiß nicht, daß der Client A die Datei geändert hat und sendet folglich in get_attr den Änderungszeitpunkt vor dem Öffnen zurück.
Um die vorstehende Möglichkeit zu vermeiden, können Clients das Schreibtoken der Datei verwenden, um zu bewirken, daß alle ihre Änderungen in dem Änderungszeitpunkt widergespiegelt werden, der von get_attr zurückgegeben wird, wie in Fig. 7B gezeigt ist. Das Schreibtoken Client zur Verwaltung des Änderungszeitpunkts gemäß den folgenden Regeln:
1. Der Server merkt sich einen Änderungszählstand für die Datei, Schritt 710.
2. Wenn ein Client über get_tkn ein Schreibtoken anfordert, Schritt 711, wird der Änderungszählstand in der Antwort zurückgegeben, Schritt 712.
3. Wenn ein Client sicher sein möchte, daß eine Dateiänderung im Änderungszeitpunkt einer beliebigen, nachfolgenden get_attr-Anforderung widergespiegelt wird, erhöht der Client den Änderungszählstand, wenn er die Änderung vornimmt, Schritt 713. Ein Schreib(2)-Systemaufruf würde den Änderungszählstand beispielsweise erhöhen.
4. Der Änderungszählstand wird in einer sync_attr-Antwort, einer _close-Antwort und in der Antwort auf eine revoke_tkn-Nachricht an den Server zurückgegeben, Schritt 716. Wie zuvor beschrieben wurde, sendet der Server, wenn er eine get_attr-Nachricht verarbeitet, ein non-purging revoke_tkn an den Client, der das Schreibtoken besitzt, Schritt 715.
5. Wenn der Server einen Änderungszählstand von einem Knoten empfängt, der das Schreibtoken der Datei besitzt, vergleicht er es ungeachtet dessen, wie es ankam, mit dem im Gedächtnis behaltenen Zähistand, Schritt 718. Wenn der empfangene Zählstand größer als der im Gedächtnis behaltene Zählstand ist, Schritt 719, wird der empfangene Zählstand der im Gedächtnis behaltene Zählstand, und der Änderungszeitpunkt wird auf den aktuellen Zeitpunkt des Servers gesetzt, Schritt 720, ansonsten wird der empfangene Zählstand gelöscht, Schritt 721.
Das vorherige Szenario sieht dann wie folgt aus:
1. Client A öffnet eine Datei, gibt eine get_tkn-Anforderung aus, um das Schreibtoken zu bekommen, Schritt 711, und ruft über get_bytes einige Daten ab.
2. Ein Prozeß am Client A gibt einen Schreib(2)-Systemaufruf aus. Dieser bewirkt, daß der Änderungszählstand des Schreibtokens erhöht wird, Schritt 713.
3. Ein Prozeß am Client B gibt eine get_attr-Anforderung für die Datei aus, Schritt 714.
4. Der Server gibt ein non-purging revoke_tkn an den Client A aus, Schritt 715. Der zurückgegebene Änderungszählstand ist größer als der vom Server im Gedächtnis behaltene Zählstand, so daß der im Gedächtnis behaltene Zählstand aktualisiert wird, und der aktuelle Zeitpunkt des Servers wird in der get_attr-Antwort als der Änderungszeitpunkt zurückgegeben, Schritte 722, 723.
In diesem Szenario veranlaßte die Verwendung des Schreibtokens durch den Client A, daß seine Änderung durch get_attr gemeldet wurde.
Von ein paar Ausnahmen abgesehen, ist die Verwaltung des Zeitpunkts des Zugriffs auf eine Datei analog zur Verwaltung des Änderungszeitpunkts. Diese Ausnahmen werden nachstehend erläutert. Gegebenenfalls gibt es nur ein Schreibtoken, und deshalb muß sich der Server nur einen Änderungszählstand merken. Es kann jedoch mehrere Client-Knoten geben, von denen jeder ein Lesetoken besitzt. Der Server muß sich deshalb einen Zugriffszählstand für jedes Lesetoken merken.
Wenn der Server eine get_attr-Nachricht empfängt, gibt er an den Besitzer des Schreibtokens ein non-purging revoke_tkn aus. Dadurch kann er alle von einem Client an der Datei vorgenommene Änderungen in Erfahrung bringen. Eine analoge Operation hinsichtlich des Zugriffszeitpunktes würde es erforderlich machen, daß der Server an Besitzer von Lesetoken ein non-purging revoke_tkn ausgibt. Jedoch gibt es zwischen den beiden Fällen Unterschiede. Erstens könnte es viele Client-Knoten geben, die Lesetoken besitzen. Jedem dieser Clients revoke_tkn-Nchrichten zu senden, könnte kostspielig sein. Zweitens ist die Information, ob eine Datei geändert worden ist oder nicht, von größerer Bedeutung als die Information, ob auf die Datei zugegriffen worden ist oder nicht.
Aus diesen Gründen und in Anbetracht der Tatsache, daß get_attr eine verhältnismäßig häufige Anforderung ist, macht es das Protokoll nicht erforderlich, daß Besitzer von Lesetoken als Teil der Antwort des Servers auf eine get_attr-Anforderung abgefragt werden. Vom Client und vom Server durchgeführte periodische Synchronisationsoperationen bewirken, daß sich Zugriffe über Systemaufrufe schließlich (in Abhängigkeit von der periodischen Synchronisationsfrequenz vom Client und vom Server) im Attribut Zugriffszeitpunkt niederschlagen. Zugriffe über get_bytes, ohne den Vorteil des Lesetokens der Datei, werden im Attribut Zugriffszeitpunkt nicht widergespiegelt.
Wie vorstehend beschrieben, werden die Dateiattribute in den Lese- und Schreibtoken festgehalten. Die Attribute Dateigröße und Änderungszeitpunkt werden im Schreibtoken festgehalten, und das Attribut zugriffszeitpunkt wird in den Lesetoken festgehalten. Das Festhalten der Dateiattribute in den Lese- und Schreibtoken ist für diejenigen Prozesse nützlich, die Lese- und Schreiboperationen ausführen. Da Prozesse nicht das Schreibtoken erwerben müssen, um die Datei durch einen abgebildeten Zugriff zu erweitern, und dadurch das Attribut Dateigröße und das Attribut Änderungszeitpunkt ändern, werden die Dateigrößenattribute nicht nur in den Token, sondern auch in der äußersten rechten Seite der Datei gespeichert. Die äußerste rechte Seite einer Datei kann sich von der Größe der Datei unterscheiden. Die äußerste rechte Seite der Datei ist dem virtuellen Speichermanager bekannt. Obwohl der virtuelle Speichermananger die genaue Größe der Datei nicht kennt, kennt er die äußerste rechte Seite der Datei. Deshalb kann ein Prozeß eine Datei durch den virtuellen Speichermanager erweitern, der die äußerste rechte Seite der Datei erweitert, oder ein Prozeß kann in die Datei schreiben und die Datei durch das Schreibtoken erweitern.
Der Server verknüpft diese Informationen von der äußersten rechten Seite und die in einem Schreibtoken an einem Client enthaltenen Informationen, um als Antwort auf Anforderungen von anderen Clients, die diese Dateiattribute anfordern, zur aktuellen Größe der Datei zu gelangen.
Ein Prozeß, der eine Datei durch einen abgebildeten Zugriff erweitert, gibt die Größe der Datei durch die äußerste rechte Seite, wenn die Datei von diesem Prozeß geschlossen wird oder zusammen mit einer periodischen Synchronisationsoperation, an den Server zurück.
Alle Clients müssen jedwede geänderten Daten mit den put_bytes- Nachrichten in regelmäßigen Abständen an den Server senden. Dadurch weiß ein Server, wenn ein Client eine Datei erweitert hat. Mit diesen Informationen aktualisiert der Server dann die Dateiindex-Datenstruktur für die Datei.
Wenn ein Client die neuesten Attribute vom Server anfordert, sendet der Server eine Anforderung an den Client mit dem Token für die aktuellen Informationen für die Werte der Attribute, die in dem Token gespeichert sind. In Beantwortung einer Attribute-Abrufen-Anforderung von einem Client sendet der Server eine Token-Widerrufen-Nachricht an den Client, der das Schreibtoken besitzt. Diese Token-Widerrufen-Nachricht ist eine spezielle Token-Widerrufen-Nachricht, die nicht dazu führt, daß dieser Client das Schreibtoken verliert. Statt dessen sendet der Client eine Kopie des Schreibtokens, -das die Dateiattribute hat, an den Server zurück, während der Client das Schreibtoken behält. Der Server verwendet dann diese Informationen von dem Schreibtoken und der äußersten rechten Seite, um die Attribute- Abrufen-Anforderung von einem anderen Client zu beantworten.
Wenn irgendeines der folgenden Ereignisse eintritt, wird das Attribut Dateigröße am Server angepaßt. Wenn der Server eine periodische Synchronisationsoperation der Datei, ein letztes Schließen der Datei oder eine f_sync-Anforderung ausführt, paßt der Server das Attribut Dateigröße so an, daß es der äußersten rechten Seite entspricht.

Claims

1. Verfahren zur Verwaltung von Dateiattributdaten in einem Datenverarbeitungssystem, das mehrere, über ein Übertragungsmedium (3) miteinander verbundene Prozessoren (10) umfaßt, wobei jeder Prozessor einen Dateispeicher hat und in bezug auf eine Datei Server und in bezug auf eine andere Datei Client sein kann, wobei das Verfahren folgendes umfaßt:

Erfassen eines Bestands einer ersten Dateigröße einer Datei (5A) an ihrem Server (10A);

Verwalten eines Bestands einer zweiten Datelgröße der Datei an einem Client (10C), der zur Änderung der Datei berechtigt ist;

in bezug auf die Datei (5A) Verwalten eines Bestands an zusätzlichen Attributen einschließlich des Zeitpunkts der letzten Dateländerung und des Zeitpunkts des letzten Dateizugriffs am Server (10A); und

Ändern des Bestands der zweiten Dateigröße am und durch den Client (10C) als Antwort auf die vom Client (10C) durchgeführte Änderung der Größe der Datei (5A);

dadurch gekennzeichnet, daß das Verfahren folgendes umfaßt:

am Server (10A) Verknüpfen des Bestands der zweiten Dateigröße und des Bestands der ersten Dateigröße, um die neueste Dateigröße der Datei (5A) zu ermitteln;

wobei der Änderungszeitpunkt der Datei (5A) verwaltet wird, indem der Server (10A) einen Änderungszählstand und einen entsprechenden Änderungszeitpunkt für die Datei (5A) protokolliert, der Client (10C) den Änderungszählstand erhöht, wenn der Client (10C) die Datei (5A) ändert, der Client (10C) den Änderungszählstand an den Server (10A) sendet, der Server (10A) den übermittelten Änderungszählstand mit dem protokollierten Änderungszählstand vergleicht, um festzustellen, ob die Datei (5A) geändert wurde, während der Client (10C) die Schreibberechtigung hatte, und der Server (10A) den entsprechenden protokollierten Änderungszeitpunkt auf den übermittelten Änderungszeitpunkt aktualisiert, wenn der Server (10A) anhand des Vergleichs feststellt, daß die Datei (5A) geändert wurde; und

wobei die Zugriffszeit auf die Datei (5A) verwaltet wird, indem eine Client-Zugriffszeit in Verbindung mit einer dem Client (10C) vom Server (10A) erteilten Berechtigung zum Lesen der Datei (5A) verwaltet wird, der Client (10C) die Client-Zugriffszeit erhöht, wenn der Client (10C) auf die Datei (5A) zugreift, der Client (10C) die entsprechende Client-Zugriffszeit in regelmäßigen Abständen an den Server (10A) übermittelt, der Server (10A) die übermittelte Client-Zugriffszeit mit einer aufgezeichneten Zugriffszeit, die vom Server (10A) verwaltet wird, vergleicht, um festzustellen, ob auf die Datei (5A) zugegriffen wurde, während der Client die Leseberechtigung hatte, und der Server (10A) die aufgezeichnete Zugriffszeil mit der übermittelten Client-Zugriffszeit aktualisiert, wenn der Server (10A) anhand des Vergleichs feststellt, daß auf die Datei (5A) zugegriffen wurde.

2. Verfahren wie in Anspruch 1 beansprucht, welches das Abrufen von Informationen über die zweite Dateigröße durch den Server (10A) umfaßt, indem er die zweite Dateigröße vom Client (10C), der für das Ändern der Größe der Datei (5A) verantwortlich ist, empfängt, bevor er die neueste Dateigröße ermittelt.

3. Verfahren wie in Anspruch 2 beansprucht, das den Empfang der zweiten Dateigröße als Antwort auf eine vom Server (10A) an den Client (10C) und/oder vom Client (10C) gesandte Anfrage umfaßt, wenn er die am Client (10C) geänderten Daten in regelmäßigen Abständen auf den Server (10A) schreibt.

4. Verfahren wie in Anspruch 2 oder Anspruch 3 beansprucht, das den Empfang der zweiten Dateigröße vom Client (10C) umfaßt, wenn der Client (10C) eine periodische Synchronisationsoperation ausführt.

5. Verfahren wie in einem vorhergehenden Anspruch beansprucht, das den Schritt der Veranlassung des Servers (10A), die zweite Dateigröße vom Client (10C) anzufordern, bevqr er den neuesten Wert der Dateigröße ermittelt, um-

6. Verfahren wie in Anspruch 5 beansprucht, das die Verwendung eines Tokens umfaßt, um darauf hinzuweisen, daß der Client (10C) die Anfrage empfangen sollte, wobei der Client (10C) das Token vom Server (10A) anfordert, wenn er die Berechtigung zum Schreiben in die Datei (5A) benötigt.

7. Verfahren wie in einem vorhergehenden Anspruch beansprucht, welches das Verwalten der zweiten Dateigröße in Verbindung mit der Fähigkeit, die Dateigröße am Client (10C) durch den Zugriff eines virtuellen Speichers auf die Datei (5A) und durch einen Systemaufrufzugriff auf die Datei (5A) zu ändern, umfaßt.

8. Verfahren wie in Anspruch 7 beansprucht, wobei der neueste Wert der Dateigröße durch ein Dateiende ermittelt wird, das in der äußersten rechten Seite des virtuellen Speichers enthalten ist.

9. Verfahren wie in einem vorhergehenden Anspruch beansprucht, wobei die in bezug auf eine Datei an ihrem Server (10A) verwalteten Bestände getrennt verwaltet werden.

10. Verfahren wie in einem vorhergehenden Anspruch beansprucht, wobei Attribute vom Client (10C) an den Server (10A) übertragen werden, wenn er einen abgebildeten Zugriff auf die Datei (5A) vornimmt.

11. Verfahren wie in einem vorhergehenden Anspruch beansprucht, wobei die Attribute so angepaßt werden, daß sie, wenn der Server (10A) eine periodische Synchronisationsoder f_-Synchronisationsoperation der Datei (5A) ausführt und/oder nach einem letzten Schließen der Datei (5A) und/oder während einer Speicheranforderung, alle Änderungen von Clients einschließlich der neuesten Dateigröße, die der äußersten rechten Seite der Datei (5A) entspricht, am Server (10A) widerspiegeln.

12. Verfahren wie in Anspruch 1 beansprucht, wobei der Änderungszählstand während einer periodischen Synchronisationsoperation vom Client (10C) an den Server (10A) gesandt wird.

13. Verfahren wie in Anspruch 1 beansprucht, wobei der Änderungszählstand als Antwort auf eine Anfrage vom Server an den Server (10A) gesandt wird.