DE69703463T2

DE69703463T2 - Verfahren zum Einrichten eines nicht flüchtigen Cache-Systems für Netzwerke und CD-Roms

Info

Publication number: DE69703463T2
Application number: DE69703463T
Authority: DE
Inventors: Brian Berliner
Original assignee: Sun Microsystems Inc
Current assignee: Sun Microsystems Inc
Priority date: 1996-05-01
Filing date: 1997-04-11
Publication date: 2001-06-13
Anticipated expiration: 2017-04-12
Also published as: EP0805397A3; DE69703463D1; US6125403A; JPH10124395A; EP0805397A2; EP0805397B1

Description

GEBIET DER ERFINDUNG

Diese Erfindung betrifft ein Verfahren zum Implementieren eines virtuellen Cachevorrichtungs-Treibers, wie er im Anspruch 1 definiert ist, und ein Computerspeichermedium, das ein Programm von Befehlen codiert, die dasselbe erreichen, wie es im unabhängigen Anspruch 7 definiert ist. Weiterentwicklungen sind durch die Unteransprüche zur Verfügung gestellt.

BESCHREIBUNG DES ZUGEHÖRIGEN STANDES DER TECHNIK

Eine Cachespeicherung ist lange Zeit zum Erhöhen der Leistungsfähigkeit eines relativ langsamen Computer-Speicherbetriebsmittels verwendet worden, wenn ein schnelleres Speicherbetriebsmittet, das typischerweise höhere Kosten pro gespeichertem Bit hat, verfügbar ist. Typischerweise ist ein temporärer Speicherblock innerhalb des schnelleren Speicherbetriebsmittels (d. h. eines Caches) zum Speichern von nur einem Teil der innerhalb des langsameren Speicherbetriebsmittels gespeicherten Informationen ausgebildet. Eher als ein gesamtes Anwenderprogramm oder eine gesamte Datendatei, die auf den langsameren Speicherbetriebsmittel resident sein können, innerhalb des schnelleren Speicherbetriebsmittels gespeichert wird, werden bestimmte Algorithmen dazu verwendet, zu bestimmen, auf welche Teile des Programms oder der Datendatei am wahrscheinlichsten zugegriffen wird. Wenn die Zentralverarbeitungseinheit (CPU) des Systems eine Speicherstelle aufruft, die nicht im Cache gespeichert ist, muß der Cache (wenn er vollständig gefüllt ist) wenigstens teilweise mit den erforderlichen Daten aus dem langsameren Speicherbetriebsmittel überschrieben werden. Gleichermaßen müssen dann, wenn permanente Änderungen an Daten durchgeführt werden, Daten in sowohl dem Cache als auch dem langsameren Speicherbetriebsmittel einem Updaten unterzogen werden, um diese Änderung zu berücksichtigen.
Zu der Zeit, zu welcher diese Anmeldung geschrieben wird, gibt es ungefähr 150 Millionen Computer auf der ganzen Welt, die allgemeine geschäftsbezogene Aufgaben durchführen können. Als die schnelle Verbreitung von Personalcomputern in den frühen 1980-ern begann, wurden nahezu alle von ihnen als alleinstehende Einheiten verwendet. Jedoch wurden bald Mehrplatzsysteme entwickelt. Auf diesen frühen Mehrplatzsystemen lief für das CP/M-Platten- Betriebssystem geschriebene Software, die von Gary Kildall geschrieben worden war und durch seine Firma Digital Research, Inc. vermarktet wurde. Das von Digital Research, Inc. angebotene Mehrplatz-Platten-Betriebssystem MP/M verband mehrere "nicht programmierbare" Datensichtgeräte bzw. "Einfach"-Terminals mit einem einzigen Mikroprozessor und einem gemeinsam genutzten Plattenlaufwerk, während TurboDOS -- ein viel weiter entwickeltes Produkt, das von einer unbekannten bzw. ungenannten Firma angeboten wird - eine Master/Slave- Anordnung verwendete, die den Lokalbereichsnetzwerken (LANs) sehr ähnlich ist, die heutzutage verwendet werden.
Sowohl das MP/M- als auch das TurboDOS-Platten-Betriebssystem liefen auf Computersystemen, die auf entweder dem Mikroprozessor Intel 8080 oder dem Mikroprozessor Zilog Z-80 basierten. Keiner dieser frühen Mikroprozessoren konnte mehr als 65.536 Bytes eines Direktzugrtffsspeichers direkt adressieren. Als Folge von MP/M und TurboDOS, die ein Minimum von etwa 50.000 Bytes für einen Direktzugriffsspeicher benötigen, blieben nur etwa 15.000 Bytes eines adressierbaren Speichers für Anwenderprogramme. Da wenige Anwenderprogramme, anders als einfache Wortprozessoren, 15.000 Bytes oder weniger benötigten, waren die frühen Mehrplatzsysteme zum größten Teil mehr intellektuelle Kuriositäten, alls daß sie praktische, allgemein verwendete Mehrplatz- Datenverarbeitungssysteme waren.
Eine verteilte Datenverarbeitung (d. h. mehrere LANs, die über eine Datenfernverbindung miteinander verbunden sind) unter Verwendung von entweder MP/M oder TurboDOS wurde sogar noch hoffnungsloser, da sie zusätzlich zum Betriebssystem ein Laden eines Kommunikationsprogramms in einen Speicher erforderlich machen würde, bevor eine Anwendersoftware geladen werden könnte. Jedoch wurde mit der Einführung von IBM-kompatiblen Computern basierend auf dem Mikroprozessor Intel 80286, der aufgebaut war, um mehrere Megabytes eines Direktzugriffsspeichers zu adressieren, die Entwicklung von praktischen LANs und verteilten Datenverarbeitungssystemen möglich. Obwohl Novell Corporation anfangs einen mehrheitlichen Anteil des LAN-Markts eroberte, ist die Anzahl von Netzwerken angestiegen, die LAN-Software von Microsoft Corp. verwenden.
Heutige LANs verwenden allgemein ein verdrilltes Drahtpaar oder ein Koaxialkabel zum Verbinden von Einzelplatz-Computersystemen mit einem Serversystem. Die Verbindung von LANs wird über Telefonleitungen, speziell zugeordnete Datenleitungen, Mikrowelle oder Satellitenverbindungen erreicht. Akustische Verbindungen können unter Verwendung von elektrisch leitenden oder von optischen Faserkabeln hergestellt werden. Für akustische Verbindungen benötigt jedes Ende der Verbindung allgemein ein Modem. Die anderen Verbindungen verwenden typischerweise eine "Brücke" und einen "Router" an jedem Ende. Verteilte Datenverarbeitungsnetzwerke und die LANs innerhalb dieser verteilten Netzwerke können oft einen Vorteil aus einer Cachespeicherung erzielen.
Typischerweise sind Verbindungen zwischen LANs eines verteilten Verarbeitungsnetzwerks langsamer als die Verbindungen zwischen den Knoten (d. h. den einzelnen Computern) eines LAN. Weiterhin können, obwohl ein entferntes Speicherbetriebsmittel (z. B. ein Plattenlaufwerk auf einem entfernten Serversystem) so schnell wie oder sogar schneller als lokale Speicherbetriebsmittel sein kann, Fernverbindungen über eine Datenverbindung eine Zugriffszeit auf jenes entfernte Betriebsmittel drastisch verlangsamen. Ungeachtet des Typs einer Verbindung zwischen den LANs eines verteilten Verarbeitungsnetzwerks oder zwischen den Knoten (d. h. den einzelnen Systemen) eines LAN, hat jede Datenverbindung eine gegebene Bandbreite, die nur zulassen wird, daß eine endliche Menge von Daten gleichzeitig über die Verbindung übertragen wird. Wenn die Bandbreite einmal überschritten wird, wie zum Beispiel dann, wenn mehr als eine bestimmte Anzahl von Anwendern versuchen, über dieselbe Verbindung zu kommunizieren (gleichgültig, ob zwischen LANs oder innerhalb eines LAN), verschlechtert sich eine Antwortzeit über jene Verbindung typischerweise, da eine Anforderung jedes Anwenders verzögert wird, um alle konkurrierenden Anforderungen gleichmäßig unterzubringen. Folglich kann eine Cachespeicherung von Daten, die über ein Netzwerk gelesen werden, eine Systemleistung sowohl durch Reduzieren einer Datenverbindungsauslastung als auch durch Ausstatten des Endbenutzers mit einem Cache für Daten, auf die schnell zugegriffen werden kann, allgemein erhöhen.
Innerhalb der letzten paar Jahre sind Compact Disk-Nurlesespeichervorrichtungen (CD-ROMs) aufgrund der Verfügbarkeit von billigen Compact Disk-Speichermedien hoher Kapazität und relativ billigen CD-ROM-Leseeinheiten (Laufwerken) äußerst populär geworden. Tatsächlich enthalten nahezu alle neuen Personalcomputer, die in den Vereinigten Staaten verkauft werden, ein eingebautes CD-ROM-Laufwerk. Obwohl gegenwärtige CD-ROM-Medien nahezu 450-500 Megabytes Daten speichern können, ist ein Zugriff auf diese Daten merklich langsamer als auf Daten, die auf einem modernen Festplattenlaufwerk gespeichert sind. Beispielsweise kann der aktuelle Standard für ein Hochleistungs-CD-ROM-Laufwerk, das als "6X"- Laufwerk bekannt ist, höchstens etwa 600 Kilobytes Daten pro Sekunde lesen. Ein modernes Hochgeschwindigkeits-IDE-Festplattenlaufwerk kann andererseits etwa sechs Megabytes pro Sekunde lesen -- ungefähr das Zehnfache der Geschwindigkeit eines EiX-CD-ROM-Laufwerks. Somit kann durch eine Cachespeicherung auch eine CD-ROM-Laufwerk-Leistungsfähigkeit stark erhöht werden.
Es sind im Laufe der Jahre viele graphische Benutzeroberflächen-(GUI)- Umgebungen entwickelt worden, wie beispielsweise Microsoft® WindowsTM Version 3X, Microsoft Windows 95, Windows NT®, OS/2® von IBM Corporation und Geoworks®. Von den vorgenannten Produkten sind nur Windows NT Und OS/2 wahre Betriebssysteme, da Geoworks und Windows 3.X geladen werden müssen und unter dem ehrwürdigen Betriebssystem Microsoft MS-DOS laufen. Windows 95 ist etwas von einem Hybrid bzw. ist irgendwie ein Zwitter, da es auch Teile von MS-DOS für seinen Betrieb erfordert. Der Einfachheit halber werden hierin nachfolgend dennoch sowohl Windows 3.X als auch Windows 95 Betriebssysteme genannt.
Zu der Zeit, zu welcher diese Anmeldung geschrieben wird, ist Microsoft Windows Version 3.X das bei weitem am meisten benutzte Betriebssystem, das mit nahezu jedem zwischen 1989 und Mitte 1995 verkauften Personalcomputer gebündelt worden ist. Jedoch ist seit dem Tag seiner Herausgabe 1995 das Betriebssystem Microsoft Windows 95 von Microsoft Corporation mit den meisten neuen Hochleistungs-Personalcomputern gebündelt worden. In weniger als einem Jahr ist es das für die meisten Geschäftsanwendungen gewählte Betriebssystem geworden, und es wird erwartet, daß es Windows 3.X als das am meisten benutzte Betriebssystem für Personalcomputer schnell verdrängt. Durch Cachespeicherung existiert das Potential für ein signifikantes Erhöhen der Leistungsfähigkeit von sowohl CD-ROM-Laufwerken als auch verteilten Verarbeitungsnetzwerken, die unter den Betriebssystemen Windows 3.X und Windows 95 arbeiten.

ZUSAMMENFASSUNG DER ERFINDUNG

Kurz nach der Herausgabe von Windows 95 machte sich Sun Microsystems, Inc. (hierin nachfolgend auch "Sun" genannt) daran, ein Netzwerk und ein CD-ROM- Cacheprodukt zu schaffen, das unter sowohl Windows 3.X als auch Windows 95 läuft, gegenüber Endbenutzern völlig transparent ist und mit einer breiten Vielfalt von Dateiensystemen arbeitet, die unter sowohl Windows 3.X als auch Windows 95 laufen. Der zum Erfüllen dieser Anforderungen verwendete Ansatz ist gewesen, die Dienste zu verwenden, die durch ein Software-Programmodul innerhalb von Windows 95 zur Verfügung gestellt werden, das als Installable File System Managers (IFSMGR) bekannt ist. Plattformen der Betriebssysteme Microsoft Windows 3.X und Windows 95 enthalten 92-Bit-Komponenten, von welchen jede bei Ring-0 läuft und die virtueller Vorrichtungstreiber oder kurz VxD genannt wird. Das Programmodul IFSMGR ist ein solcher virtueller Vorrichtungstreiber. Windows 95 ist so aufgebaut, daß alle Dateiensystem-Eingabe/Ausgabe-(I/O)- Anforderungen mit dem IFSMGR VxD "verhakt" bzw. gekoppelt sind. Dies ist beispielsweise in Dr. Dobbs Journal, Vol. 20, No. 12, Dezember 1995, S. 60-70, 108, 110, von Russinovich, M. und Gogswell B. beschrieben. Dieses Dokument beschreibt das geschichtete Dateiensystem Microsoft Windows 95, von welchem die Komponente IFSMGR I/O-Anforderungen einer hohen Ebene von Anwendungen managt, indem ein auf ein spezifisches logisches Laufwerk gerichteter Aufruf genommen wird und er auf dem Weg zur aktuellen Hardwareschicht durch den richtigen Aufruf durch eine Kette (hinunter) in 32 reservierten logischen Schichten zu anderen Treibern und Steuerungen geführt wird. Wenigstens eine der Schichten ist für einen auf den Kundenbedarf zuschneidbaren "von einem Verkäufer ausgestatteten Treiber" (VSD) für eine hinzugefügte Funktion reserviert. Eine VSD-Schicht kann für eine Cache-Bildung verwendet werden, wobei ein angegebenes Beispiel für einen sekundären Plattencache niedriger Ebene beispielsweise eine Cachespeicherung in einem Flash-Speicher ist. Es ist angegeben, daß virtuelle Vorrichtungstreiber (VxDs) an der Kette Anforderungen selbst bedienen können und sie nicht zu niedrigeren Ebenen führen, oder daß sie selbst Anforderungen erzeugen können. Die virtuelle Vorrichtung einer virtuellen Dateienzuteilungstabelle (VFAT) behandelt viele Anforderungen durch Lesern oder Schreiben zu einem Speichercache über die virtuelle Vorrichtung VCACHE. Jedoch lehrt dieser Artikel nicht die Verwendung eines VSD oder eines Cacheschemas auf hoher Ebene, welches eine Steuerung vom IFSMGR-Dienst von allen I/O-Anforderungen annehmen kann. Gleichzeitig werden sich Fachleute auf dem Gebiet bewußt sein, daß die vorliegende Erfindung bei der VSD-Schicht auf dem Betriebssystem Microsoft Windows 95 implementiert werden kann.
Das von Sun MicroSystems, Inc. entwickelte Cacheprodukt wird "Solstice-PC- CacheFS" (hierin nachfolgend "PC-CacheFS" genannt). Das Cacheprodukt PC- CacheFS, das auch zu der Definition eines virtuellen Vorrichtungstreibers paßt, ist effektiv zwischen dem IFSMGR VxD und dem ursprünglichen Dateiensystem von Windows 95 "angesiedelt".
Anstatt separate Cacheprodukte für Windows 3.X und Windows 95 zu schaffen, ist das Cacheprodukt PC-CacheFS so aufgebaut, daß es unter beiden Betriebssystemen laufen wird. Jedoch hat das Betriebssystem Windows 3.X keinen virtuellen IFSMGR-Vorrichtungstreiber. Somit sind Teile des IFSMGR VxD von Windows 95 neu geschrieben worden, um unter Windows 3.X zu laufen. Das Neuschreiben basiert auf der von Microsoft Corporation gelieferten IFSMGR- Spezifukation. Somit müssen weder das Cacheprodukt PC-CacheFS (VxD) noch die Windows-Betriebssysteme selbst der Kompatibilität halber neu geschrieben werden.

Kurze Beschreibung der Zeichnungen

Fig. 1 stellt ein Rechensystem zum Durchführen der computerimplementierten Schritte des Verfahrens gemäß der Erfindung dar; und
Fig. 2 ist ein Ablaufdiagramm, das die logische Operation des virtuellen Cachevorrichtungs-Treibers zeigt.

Detaillierte Beschreibung bevorzugter Ausführungsbeispiele

Die Ausführungsbeispiele der hierin beschriebenen Erfindung können als logische Operationen in einem verteilten Verarbeitungssystem mit Client- und Server- Rechensystemen implementiert werden. Die logischen Operationen der vorliegenden Erfindung werden implementiert (1) als eine Sequenz von computerimplementierten Schritten, die auf dem Rechensystem laufen, und (2) als miteinander verbundene Maschinenmodule innerhalb des Rechensystems. Die Implementierung ist eine Sache einer Auswahl, die von den Leistungserfordernissen des Rechensystems abhängt, das die Erfindung implementiert. Demgemäß werden die logischen Operationen, die die Ausführungsbeispiele der hierin beschriebenen Erfindung bilden, auf verschiedene Weise Operationen, Schritte oder Module genannt.
Die Betriebsumgebung, in welcher die vorliegende Erfindung verwendet wird, umfaßt das allgemeine verteilte Rechensystem, wobei Computer für allgemeine Zwecke, Workstations bzw. Arbeitsplatzrechner oder Personalcomputer (hierin nachfolgend lokale Knoten) über Kommunikationsverbindungen von verschiedenen Typen in einer Client-Server-Anordnung verbunden sind, wobei Programme und Daten, viele in der Form von Objekten, von verschiedenen Teilnehmern des Systems verfügbar gemacht werden. Einige der Elemente eines Workstation- Computers für allgemeine Zwecke sind in Fig. 1 gezeigt, wobei ein Prozessor 1 gezeigt ist, wobei der Prozessor einen Eingabe/Ausgabe-(I/O)-Abschnitt, eine Zentralverarbeitungseinheit (CPU) 3 und einen Speicherabschnitt 4 hat. Der I/O- Abschnitt 2 ist mit einer Tastatur 5, einer Anzeigeeinheit 6, einer Plattenspeichereinheit 9 und einer CD-ROM-Laufwerkseinheit 7 verbunden. Die CD-ROM-Einheit 7 kann ein CD-ROM-Medium 8 lesen, das typischerweise Programme 10 und Daten enthält. Die Computerprogrammprodukte, die Mechanismen zum Verwirklichen der Vorrichtung und der Verfahren der vorliegenden Erfindung enthalten, können im Speicherabschnitt 4 oder auf einer Plattenspeichereinheit 9 oder auf der CD-ROM 8 eines solchen Systems resident sein. Beispiele für solche Systeme enthalten SPARC-Systeme, die von Sun MicroSystems, Inc. angeboten werden, Personalcomputer, die von IBM Corporation und von anderen Herstellern von LBM-kompatiblen Personalcomputern angeboten werden, und Systeme, auf denen das Betriebssystem UNIX läuft.
Das bevorzugte Ausführungsbeispiel der vorliegenden Erfindung stellt eine Cachespeicherung für Informationen zur Verfügung, die auf lokalen CD-ROM- Laufwerken gespeichert sind, und für Informationen, die bei nichtlokalen Netzwerkbetriebsmitteln gespeichert sind, die sowohl lokale als auch entfernte Serversystem-Plattenlaufwerke und ähnliches enthalten können. Solche Cachefunktionen sind in einem einzigen Cacheprodukt vorgesehen, das unter entweder Windows 3.X oder Windows 95 geladen werden kann. Das Cacheprodukt funktioniert so, daß es Endbenutzern vollständig transparent ist, und es arbeitet mit einer breiten Vielfalt von Dateiensystemen, die unter sowohl Windows 3.X als auch Windows 95 laufen.
Die bisher aufgezählten Funktionen des bevorzugten Ausführungsbeispiels sind in der Form von dem vorgesehen, was Microsoft Corporation einen virtuellen Vorrichtungstreiber oder kurz VxD nennt. Dieser Cache-VxD bildet eine Schnittstelle zu einem anderen virtuellen Vorrichtungstreiber, der Installable File System Managers (kurz IFSMGR) genannt wird, der mit Windows 95 zur Verfügung gestellt wird. Windows 95 ist so aufgebaut, daß alle Dateiensystem-Eingabe/Ausgabe-(I/O)-Anforderungen mit dem IFSMGR VxD-Dienst "verhakt" bzw. gekoppelt sind. Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist der Cache-VxD zwischen dem IFSMGR VxD-Dienst und dem generischen Dateiensystem von Windows 95 geschichtet. Bei einem bevorzugten Ausführungsbeispiel der Erfindung empfängt das Cacheprodukt alle Dateiensystem-I/O-Anfordenungen vom IFSMGR VxD und implementiert ein Cacheschema gemäß Einstellbefehlen, die durch den Benutzer eines lokalen Knotens vorprogrammiert worden sind. Anders ausgedrückt teilt der Benutzer dem Cacheprodukt mit, welches Netzwerk oder welches CD-ROM-Laufwerk oder welche CD-ROM-Laufwerke in einem Cache zu speichern sind.
Anstatt separate Cacheprodukte für Windows 3.X und Windows 95 zu schaffen, ist das Cacheprodukt PC-CacheFS so aufgebaut worden, daß es unter beiden Betriebssystemen laufen wird. Da jedoch das Betriebssystem Windows 3.X weder einen virtuellen Vorrichtungstreiber vom IFSMGR-Dienst noch ein funktionales Äquivalent hat, ist ein spezieller virtueller Vorrichtungstreiber IFSMGR im Cache- VxD eingebaut worden. Somit wird dann, wenn das bevorzugte Ausführungsbeispiel des Cacheprodukts unter Windows 3.X geladen wird, dieser spezielle IFSMGR VxD aufgerufen, wann immer eine System-I/O-Anforderung von der System-CPU ausgegeben wird, um einen IFSMGR-Dienst zu liefern. Der spezielle IFSMGR-VxD, der großenteils auf der von Microsoft Corporation zur Verfügung gestellten IFSMGR-Spezifikation Windows 95 basiert, enthält Modifikationen, die ihm erlauben, unter Windows 3.X zu arbeiten. Durch Verwenden dieses Ansatzes müssen weder der Cache-VxD noch die Windows- Betriebssysteme selbst der Kompatibilität halber neu geschrieben werden.
Die Schnittstelle des Cache-VxD zum IFSMGR VxD-Dienst ist durch die folgende beispielhafte Pseudocode-Routine implementiert:
1. Ist dies eine Windows-Bootzeit-Initialisierung?
Ja: Gehe zu Schritt 2.
Nein: Gehe zu Schritt 3.
2. "Verhaken" bzw. Koppeln des IFSMGR VxD-Diensts durch Aufrufen der Routine IFSMgr_InstallFileSystemApiHook, Spezifizieren einer Cache- Koppelung als den Rückrufnamen für die Koppelung zum Cacheprodukt.
3. Der IFSMGR-Dienst ruft eine Cache-Koppelung zu einer Dateien-I/O- Anforderung auf.
4. Enthält diese Anforderung ein Netzwerklaufwerk oder ein CD-ROM- Laufwerk, das für eine Cachespeicherung konfiguriert worden ist?
Ja: Gehe zu Schritt 6.
Nein: Gehe zu Schritt S,
da die Anforderung nicht weiter interessant ist.
5. Die Steuerung sprang zurück zum IFSMGR VxD-Dienst und die Dateien- I/O-Anforderung wird mit der nächsten IFSMGR-Koppelung oder mit dem IFSMGR selbst verkettet.
6. Hat der lokale Festplattencache gültige Daten zum Erfüllen dieser Anforderung in sich?
Ja: Gehe zu Schritt 9.
Nein: Gehe zu Schritt 7.
7. Aufrufen nach unten zum bzw. durch das Netzwerk oder zum CD-ROM- Dateiensystem und Auslesen von wenigstens genügend Daten zum Erfüllen der Anforderung, Beibehalten der Steuerung vom IFSMGR- Dienst.
8. Speichern der ausgelesenen Daten im Cache durch Sichern von ihnen entweder im Direktzugriffsspeicher oder auf der lokalen Festplatte für ein darauffolgendes Auslesen.
9. Liefern von Daten vom Cache, die die I/O-Anforderung auflösen, und Gehen zum Schritt 5.
Zum weiteren Klären des Betriebsablaufs des Cache-VxD ist die vorangehende Pseudocode-Routine im Ablaufdiagramm von Fig. 2 formatiert worden.
Jeder virtuelle Gerätetreiber kann alle Systemdatei-I/O-Anforderungen durch Aufbauen einer Koppelung zum IFSMGR-VxD-Dienst überwachen. Dies wird durch Aufrufen einer Routine innerhalb des IFSMGR VxD erreicht, die "IFSMgr_InstallFileSystemApiHook" genannt wird, und durch Versehen von ihr mit einem eindeutigen Rückrufnamen. In diesem Fall ist der Name "CacheHook" bzw. "Gache-Koppelung" willkürlich als der Rückrufname für den Cache-VxD gewählt worden.
Der IFSMGR VxD hält eine Tabelle von allen Koppelungs-Anforderungen, die von verschiedenen virtuellen Vorrichtungs-Treibern durchgeführt werden. Beispielsweise kann zusätzlich zum Cache-VxD ein Virusscan-VxD auch eine Koppelung zum IFSMGR VxD haben. Ein solcher Virusscan-VxD kann verantwortlich sein für ein Abtasten aller ausführbaren Dateien nach Viren beim Lesen von ihnen. Alle IFSMGR-Koppelungen sind miteinander verkettet. Zum Initiieren der Verkettungssequenz führt der IFSMGR VxD eine ankommende Dateien-I/O-Anforderung zur ersten Koppelung zusammen mit Informationen, die sequentiell alte anderen anfordernden Koppelungen identifizieren. Jede Koppelung analysiert die ankommende Dateien-I/O-Anforderung und entscheidet auf der Basis des Typs von Anforderung, ob eine Handlung durchzuführen ist oder nicht. Wenn eine jeweilige Koppelung mit der ankommenden Dateien-I/O-Anforderung endet, führt ("verkettet") sie die Anforderung zur nächsten Verhakung in der Sequenz. Die End-Koppelung in der Sequenz bringt eine Steuerung der Dateien-I/O-Anforderung zum IFSMGR VxD zurück.
Der Gache kann in entweder dem Direktzugriffsspeicher von lokalen Systemen oder auf dem lokalen Festplattenlaufwerk ausgebildet sein. Alternativ dazu kann ein zweirangiges Cachesystem so implementiert sein, daß ein großer Block von nichtflüchtigen im Cache gespeicherten Daten auf dem lokalen Festplattenlaufwerk resident ist, während ein kleinerer Block von flüchtigen im Gache gespeicherten Daten innerhalb eines Teils des Direktzugriffsspeichers resident ist. Solche Cacheschemen sind im Stand der Technik bereits wohlbekannt und werden hierin nicht detaillierter diskutiert werden.
Während die Erfindung insbesondere unter Bezugnahme auf ihr bevorzugtes Ausführungsbeispiel gezeigt und beschrieben worden ist, wird es von Fachleuten auf dem Gebiet verstanden werden, daß verschiedene andere Änderungen in bezug auf die Form und Details dabei durchgeführt werden können, ohne vom Schutzumfang der Erfindung abzuweichen.

Claims

1. Verfahren zum Implementieren eines virtuellen Cachevorrichtungs- Treibers (VxD), der auf alle Dateieingabe-/-ausgabe(I/O)-Anforderungen innerhalb eines Computerbetriebssystems anspricht, wobei das Betriebssystem oder der virtuelle Cachevorrichtungs-Treiber (VxD) mit einem virtuellen Gerätetreiberdienst eines Microsoft Windows (T. M.) Installable File System Managers (IFSMGR) oder seinem funktionalen Äquivalent, (IFSMGR VxD), versehen ist, wobei das Verfahren auf einem Datenverarbeitungssystem implementiert ist, das eine lokale Zentralverarbeitungseinheit (CPU) (3), einen lokalen Direktzugriffsspeicher (4), einen lokalen Datenbus und eine fokale Massenspeichervorrichtung (9) aufweist, und wobei das Datenverarbeitungssystem mit mindestens einer lokalen Festwertspeichervorrichtung (7), aus der Daten zwischengespeichert (gecachet) werden können, oder mit mindestens einer nicht lokalen Massenspeichervorrichtung gekoppelt ist, die Daten enthält, die eventuell benötigt werden, um eine Datei-I/O-Anforderung von der lokalen CPU auszuführen, wobei das Verfahren folgende Schritte umfaßt:

zwecks Vorprogrammierung Bereitstellen des virtuellen Cachevorrichtungs-Treibers (VxD) durch den Benutzer des Datenverarbeitungssystems mittels Installationsbefehlen in Bezug darauf, welche lokale Festwertspeichervorrichtung (7) oder nicht lokale Massenspeichervorrichtung gecachet werden soll,

Schaffen eines Cache innerhalb des lokalen Direktzugriffsspeichers (4) und/oder der lokalen Massenspeichervorrichtung (9),

Herstellen einer Koppelung (120) zum virtuellen Cachevorrichtungs- Treiber (VxD) vom IFSMGR-Dienst (IFSMGR VxD) zur Bootzeit-Initialisierung des Betriebssystems,

Empfangen einer Datei-I/O-Anforderung (130) von der lokalen CPU immer dann, wenn das Betriebssystem eine Datei-I/O-Anforderung verarbeitet,

in Reaktion auf die Datei-I/O-Anforderung Erzeugen (130) eines Aufrufs an den virtuellen Cachevorrichtungs-Treiber (VxD) vom IFSMGR-Dienst (IFSMGR VxD),

Steuerungsübernahme (130) der Datei-I/O-Anforderung durch den virtuellen Cachevorrichtungs-Treiber (VxD),

Ermitteln (140), ob die Datei-I/O-Anforderung Daten auf einer Vorrichtung, die vom Benutzer zum Zwischenspeichern konfiguriert worden ist, erfordert oder nicht,

wenn die Datei-I/O-Anforderung diese Daten nicht erfordert, Zurückgeben der Steuerung (150) der Datei-I/O-Anforderung an den IFSMGR- Dienst (IFSMGR VxD),

wenn die Datei-I/O Anforderung diese Daten erfordert, Ermitteln (160), ob innerhalb des Cache Daten, die die Datei-I/O-Anforderung erfüllen, vorhanden sind oder nicht,

wenn Daten, die die Datei-I/O-Anforderung erfüllen, innerhalb des Cache vorhanden sind, Zuführen (190) der Daten, die die Datei-I/O-Anforderung erfüllen, zu dem Datenbus, und Zurückgeben der Steuerung (150) an den IFSMGR-Dienst (IFSMGR VxD),

wenn Daten, die die Datei-I/O-Anforderung erfüllen, nicht innerhalb des Cache vorhanden sind, Auslesen (170) von Daten, die die Datei-I/O-Anforderung erfüllen, aus dem lokalen Festwertspeicher (7) oder der nicht lokalen Massenspeichervorrichtung, die vom Benutzer zum Zwischenspeichern konfiguriert worden sind, Speichern (180) der ausgelesenen Daten im Cache, Zuführen der ausgelesenen Daten zum Datenbus, und Zurückgeben der Steuerung (150) an den IFSMGR-Dienst (IFSMGR VxD).

2. Verfahren nach Anspruch 1, bei dem das Computerbetriebssystem ein auf Fenstern basierendes Betriebssystem ist.

3. Verfahren nach Anspruch 2, bei dem das Computersystem ein Microsoft Windows (T. M.) Betriebssystem, Version 3.X oder Windows 95 ist.

4. Verfahren nach einem der Ansprüche 1 bis 3, bei dem die lokale Festwertspeichervorrichtung ein CD-ROM-Laufwerk (7) ist.

5. Verfahren nach einem der Ansprüche 1 bis 3, bei dem sich die nicht lokale Massenspeicheivorrichtung auf einem Servercomputer in einem Client- Server-Computersystem befindet, mit dem das Datenverarbeitungssystem über eine Netzwerkverbindung gekoppelt ist.

6. Verfahren nach Anspruch 5, bei dem der virtuelle Cachevorrichtungs-Treiber (VxD) zwischen einem Dateihandhabungssystem und der Dateisystemmanager-Routine (IFSMGR VxD) angeordnet ist, wobei das Dateihandhabungssystem ein Bestandteil des Betriebssystems ist, wenn es auf einem lokalen Knoten des Client-Server-Computersystems läuft, wobei die Bateisystemmanager-Routine (IFSMGR Vxß) weitere virtuelle Gerätetreiber zur Verfügung stellt, um auf Anfrage Bingabe-/Ausgabe(I/O)-Anforderungen vorübergehend zuzugreifen und sie zu steuern.

7. Computerprogramm-Speichermedium, das ein Programm von Befehlen für einen Prozess zum Implementieren eines virtuellen Caehevorrichtungs-Treibers (VxD) codiert, der auf alle Dateieingabe-/-ausgabe(I/O)-Anforderungen innerhalb eines Computerbetriebssystems anspricht, wobei das Betriebssystem oder der virtuelle Cachevorrichtungs-Treiber (VxD) mit einem virtuellen Gerätetreiberdienst eines Microsoft Windows (T. M.) Installable File System Managers (IFSMGR) oder seinem funktionalen Äquivalent, (IFSMGR VxD), versehen ist, wobei das Verfahren auf einem Datenverarbeitungssystem implementiert ist, das eine lokale Zentralverarbeitungseinheit (CPU) (3), einen lokalen Direktzugriffsspeicher (4) einen lokalen Datenbus und eine lokale Massenspeichervorrichtung (9) aufweist, und wobei das Datenverarbeitungssystem mit mindestens einer lokalen Festwertspeichervorrichtung (7), aus der Daten zwischengespeichert (gecachet) werden können, oder mit mindestens einer nicht lokalen Massenspeichervorrichtung gekoppelt ist, die Daten enthält, die eventuell benötigt werden, um eine Datei-I/O-Anforderung von der lokalen CPU zu auszuführen, wobei der Prozess folgende Schritte umfaßt:

zwecks Vorprogrammierung Bereitstellen des virtuellen Cachevorrichtungs-Treibers (VxD) durch den Benutzer des Datenverarbeitungssystems mittels Installationsbefehlen in Bezug darauf, welche lokale Festwertspeichervorrichtung (7) oder welche nicht lokale Massenspeichervorrichtung gecachet werden soll,

wenn die Datei-I/O-Anforderung diese Daten erfordert, Ermitteln (160), ob innerhalb des Cache Daten, die die Datei-I/O-Anforderung erfüllen, vorhanden sind oder nicht,

wenn Daten, die die Datei-I/O-Anforderung erfüllen, innerhalb des Cache vorhanden sind, Zuführen (190) der Daten, die die Datei-I/O-Anforderung erfüllen, zu dem Datenbus, und Zurückgeben der Steuerung (150) and den IFSMGR-Dienst (IFSMGR VxD),