PatentDe  


Dokumentenidentifikation DE60125989T2 31.10.2007
EP-Veröffentlichungsnummer 0001407379
Titel VERFAHREN UND APPARAT FÜR EINE VERBESSERTE DATEIVERWALTUNG
Anmelder Intel Corp., Santa Clara, Calif., US
Erfinder DAKE, Steven, Chandler, AZ 85248, US
Vertreter Hauck Patent- und Rechtsanwälte, 20354 Hamburg
DE-Aktenzeichen 60125989
Vertragsstaaten AT, BE, CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LI, LU, MC, NL, PT, SE, TR
Sprache des Dokument EN
EP-Anmeldetag 20.11.2001
EP-Aktenzeichen 012730313
WO-Anmeldetag 20.11.2001
PCT-Aktenzeichen PCT/US01/44883
WO-Veröffentlichungsnummer 2002054286
WO-Veröffentlichungsdatum 11.07.2002
EP-Offenlegungsdatum 14.04.2004
EP date of grant 10.01.2007
Veröffentlichungstag im Patentblatt 31.10.2007
IPC-Hauptklasse G06F 17/30(2006.01)A, F, I, 20051017, B, H, EP

Beschreibung[de]
GEBIET DER ERFINDUNG

Die vorliegende Offenbarung betrifft Computer- und Kommunikationssysteme. Im Besonderen betrifft sie Verfahren und Vorrichtungen zur Verbesserung der Dateiverwaltung in einem Computer- und Kommunikationssystem.

STAND DER TECHNIK

Computer- und Kommunikationssysteme weisen häufig eine ähnliche Architektur auf. Jedes System kann eine Mehrzahl separater Komponenten umfassen, die jeweils für die Ausführung bestimmter Funktionen gestaltet sind. Die Komponenten können Informationen über ein Zwischenverbindungssystem an andere Komponenten kommunizieren. Ein Zwischenverbindungssystem arbeitet so, dass es die Übertragung von Informationen über ein Kommunikations- bzw. Übertragungsmedium verwaltet, wie zum Beispiel metallische Zuleitungen, verdrillte Leitungsdrähte, Koaxialkabel, Lichtwellenleiter, Funkfrequenzen, etc. Die Kommunikationen zwischen Komponenten unterstützen für gewöhnlich die Koordination von Operationen der einzelnen Komponenten, so dass sie als ein zusammenhängendes System arbeiten können. Diese Art der verteilten Systemarchitektur kann bestimmte Vorteile in Bezug auf Leistung, Redundanz, Skalierbarkeit und Effizienz bereitstellen.

Dieser Art des Systemaufbaus sind aber auch Nachteile zugeordnet. Ein Nachteil ist es, dass eine Komponente unter Umständen im Ruhezustand bleiben muss, während sie auf Informationen von einer anderen Komponente warte. Die Leerlaufzeit kann eine ineffiziente Nutzung der Systemressourcen darstellen. Ein weiterer Nachteil ist es, dass die Funktionalität Komponenten so zugewiesen werden kann, dass die zwischen Komponenten übertragene Informationsmenge erhöht wird. Diese Erhöhung der Kommunikationen erhöht die Anforderungen an die endlichen Ressourcen des Zwischenverbindungssystems.

"The NFS Version 4 Protocol" von B. Pawlowski et al., Proceedings of 2nd International Sane Conference [online], 22.–25. Mai 2000, Seiten 1–20, XP00226978, Maastricht, offenbart den Einsatz öffentlicher Dateibehandlungen, die eindeutige Bezeichner an einem Server für ein Dateisystemobjekt darstellen, das für den Client opak ist. Der Client muss einen Bezeichner für eine Datei von einem Server anfordern. Dies ist mit Nachteilen verbunden.

"RFC 2054 – WebNFS Client Specification" von B. Callaghan, IETF, Oktober 1996 (1996-10), XP002242530, offenbart den Einsatz öffentlicher Dateibehandlungen als eine erste Dateibehandlung, die von einem Client für eine erste Dateioperation eingesetzt wird.

ZUSAMMENFASSUNG DER ERFINDUNG

Vorgesehen ist gemäß einem ersten Aspekt der vorliegenden Erfindung ein Verfahren gemäß dem gegenständlichen Anspruch 1.

Vorgesehen ist gemäß einem zweiten Aspekt der vorliegenden Erfindung eine Vorrichtung gemäß dem gegenständlichen Anspruch 5.

Bevorzugte Merkmale der Erfindung sind durch die Unteransprüche definiert.

KURZE BESCHREIBUNG DER ZEICHNUNGEN

Der als Ausführungsbeispiele der Erfindung bezeichnete Gegenstand wird in dem abschließenden Abschnitt der Patentschrift speziell ausgeführt und eindeutig beansprucht. Die Ausführungsbeispiele der Erfindung werden sowohl in Bezug auf deren Aufbau und ihre Funktionsweise in Verbindung mit den Aufgaben, Merkmalen und Vorteilen der Erfindung am besten verständlich in Bezug auf die folgende genaue Beschreibung, wenn diese in Verbindung mit den beigefügten Zeichnungen gelesen wird. In den Zeichnungen zeigen:

1 ein geeignetes System für die Ausführung eines Ausführungsbeispiels der vorliegenden Erfindung;

2 ein Blockdiagramm eines Client-Systems gemäß einem Ausführungsbeispiel der Erfindung;

3 ein Blockdiagramm eines Server-Systems gemäß einem Ausführungsbeispiel der Erfindung;

4 ein Blockablaufdiagramm der von einem Client-System gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführten Operationen;

5 ein Blockablaufdiagramm der von einem Server-System gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführten Operationen; und

6 eine Softwarearchitektur gemäß einem Ausführungsbeispiel der vorliegenden Erfindung.

GENAUE BESCHREIBUNG

In der folgenden genauen Beschreibung sind zahlreiche besondere Einzelheiten ausgeführt, um ein umfassendes Verständnis der Ausführungsbeispiele der Erfindung zu vermitteln. Der Fachmann auf dem Gebiet erkennt jedoch, dass die Ausführungsbeispiele der Erfindung auch ohne diese besonderen Einzelheiten ausgeführt werden können. In anderen Fällen wurde auf die nähere Beschreibung allgemein bekannter Verfahren, Prozeduren, Komponenten und Schaltungen verzichtet, um die Ausführungsbeispiele der Erfindung nicht unnötig zu verschleiern.

Die Ausführungsbeispiele der Erfindung können die Leistung bzw. Performance eines verteilten Systems verbessern, indem die Leerlauf- bzw. Stillstandszeit für verteilte Komponenten ebenso reduziert wird wie die Bandbreitenanforderungen für das Zwischenverbindungssystem. Im Besonderen kann ein Ausführungsbeispiel der Erfindung die Leistung eines verteilten Systems verbessern, das für die Dateiverwaltung eingesetzt wird. Als Resultat kann dies die Verzögerungen reduzieren, die den Dateioperationen zugeordnet sind. Folglich kann ein Benutzer in Form von besser ansprechenden Anwendungen und Diensten profitieren.

Ein Dateimanagementsystem bzw. Dateiverwaltungssystem umfasst für gewöhnlich einen Client und einen Server. Der Client kann sich in diesem Kontext auf einen Anforderer von Diensten beziehen. Ein Server kann sich in diesem Kontext auf einen Anbieter bzw. Provider von Diensten beziehen. Der Client sendet für gewöhnlich über ein Zwischenverbindungssystem eine Dateianforderung an einen Server. Die Dateianforderung kann in Form einer Nachricht gegeben sein, und sie kann eine Funktionsanforderung und einen Dateinamen aufweisen. Eine Nachricht kann in diesem Kontext ein oder mehrere alphanumerische Zeichen, Symbole oder logische Ausdrücke umfassen, die in Kombination zum Beispiel Steuerwörter, Befehle, Anweisungen, Informationen oder Daten darstellen. Die Nachricht kann in Bezug auf ihre Zusammensetzung zum Beispiel von einem einzelnen Bit bis zu ganzen Phrasen. variieren. Der Server ordnet einen eindeutigen Bezeichner dem Dateinamen zu, identifiziert Positionsinformationen für die Datei und speichert diese in Verbindung mit dem eindeutigen Bezeichner. Der Server sendet danach den eindeutigen Bezeichner zurück zu dem Client. Der Client empfängt den eindeutigen Bezeichner und verwendet diesen an Stelle des Dateinamens für folgende Dateianforderungen.

Ein eindeutiger Bezeichner wird einem Dateinamen zugewiesen, um die Bandbreitenanforderungen der Zwischenverbindungssysteme zu reduzieren. Ein Dateiname kann zum Beispiel eine Reihe alphanumerischer Zeichen oder Symbole ("Zeichenfolge") umfassen. Jedes Zeichen oder Symbol wird in ein oder mehrere Bits umgewandelt, wie gewöhnlich mit 8 Bits (z.B. 1 Byte) je Zeichen. Da ein Dateiname viele Zeichen umfassen kann, kann es sein, dass das Zwischenverbindungssystem eine verhältnismäßig große Anzahl von Bits transportieren muss. Zur Reduzierung dieses Problems kann der Server jedem Dateinamen einen eindeutigen Bezeichner zuweisen und den eindeutigen Bezeichner an den Client senden. Der eindeutige Bezeichner weist für gewöhnlich eine kleinere Länge als der Dateiname auf. Zum Beispiel kann ein eindeutiger Bezeichner eine Länge von 32 oder 64 Bits aufweisen. Der Client kann den eindeutigen Bezeichner in der Folge für spätere Dateianforderungen einsetzen.

Mit der Zuweisung eines eindeutigen Bezeichners durch einen Server an einen Dateinamen sind jedoch Nachteile verbunden. Ein Nachteil ist es, dass der Client unter Umständen im Ruhezustand verbleiben muss, während er auf den eindeutigen Bezeichner wartet vor der Verarbeitung der folgenden Dateianforderung. Ein weiterer Nachteil ist es, dass der Client und der Server unter Umständen mehr Informationen kommunizieren müssen als wie dies erforderlich ist, wodurch die Anforderungen an das Zwischenverbindungssystem erhöht werden.

In Bezug auf den ersten Nachteil kann es sein, dass der Client im Ruhezustand bleiben muss, während er auf den eindeutigen Bezeichner von dem Server wartet. Zur Einleitung des Zuweisungsprozesses sendet der Client eine Nachricht an den Server, in der er die Zuweisung eines eindeutigen Bezeichners an einen Dateinamen anfordert. Der Server ordnet einem eindeutigen Bezeichner dem Dateinamen zu, identifiziert Positionsinformationen für die Datei und speichert sie in Verbindung mit dem eindeutigen Bezeichner. Der Server sendet danach eine Nachricht mit dem eindeutigen Bezeichner zurück zu dem Client. Während dem Warten auf dem Empfang des eindeutigen Bezeichners von dem Server, kann der Client folgende Dateianforderungen mit dem gleichen Dateinamen empfangen. Der Client kann unter Umständen nicht in der Lage sein, mit der Verarbeitung dieser Dateianforderunger zu beginnen, bevor der ganze Zuweisungsprozess abgeschlossen ist. Folglich kann der Client dazu gezwungen sein, während diesem Zeitraum im Leerlauf bzw. im Ruhezustand zu bleiben.

In Bezug auf den zweiten Nachteil ist es möglich, dass der Client und der Server nicht benötigte Informationen kommunizieren müssen, um die Zuweisungsfunktion auszuführen, wodurch die Anforderungen an das Zwischenverbindungssystem erhöht werden. Ein Dateimanagementsystem gemäß der vorstehenden Beschreibung erfordert mindestens zwei Nachrichten. Der Client sendet eine erste Nachricht an den Server, in der die Zuweisung eines eindeutigen Bezeichners an einen Dateinamen angefordert wird. Der Server sendet eine zweite Nachricht mit dem eindeutigen Bezeichner an den Client. Jede Nachricht erfordert die Nutzung einer bestimmten Bandbreitengröße von dem Zwischenverbindungssystem. In diesem Kontext kann sich die Bandbreite auf die Geschwindigkeit beziehen, mit der Informationen über ein Zwischenverbindungssystem übertragen werden können, und wobei sie für gewöhnlich in Kilobit pro Sekunde (kbps) gemessen wird. Im Gegensatz dazu kann ein Ausführungsbeispiel der Erfindung den Zuweisungsprozess unter Verwendung nur einer Nachricht ausführen, wodurch die Bandbreitenanforderungen an das Zwischenverbindungssystem potenziell um bis zu 50% reduziert werden können.

Ausführungsbeispiele der Erfindung können die Leistung eines verteilten Systems verbessern, indem die Ruhezeit für einen Client ebenso reduziert wird wie die Bandbreitenanforderungen für das Zwischenverbindungssystem. Ein Ausführungsbeispiel der Erfindung weist einen eindeutigen Bezeichner einem Dateinamen an dem Client zu und sendet den eindeutigen Bezeichner an den Server. Dies kann die Client-Leerlaufzeit reduzieren, da der Client mit der Verarbeitung folgender Dateianforderungen beginnen kann, ohne dass er auf eine Nachricht von dem Server warten muss. Dies kann ferner die Bandbreitenanforderungen reduzieren, da der Server keine Nachricht zurück an den Server senden muss, um den Zuweisungsprozess abzuschließen, oder wobei alternativ eine Nachricht gesendet werden kann, die kürzer ist als die von früheren Dateimanagementsystemen vorausgesetzten Nachrichten.

Hiermit soll festgestellt werden, dass jeder Verweis in der Beschreibung auf "ein Ausführungsbeispiel" hierin bedeutet, dass ein bestimmtes Merkmal, eine Struktur oder eine Eigenschaft, die in Verbindung mit dem Ausführungsbeispiel beschrieben werden, in mindestens einem Ausführungsbeispiel der vorliegenden Erfindung enthalten sein können. Das Auftreten des Ausdrucks "in einem Ausführungsbeispiel" an verschiedenen Stellen in der Beschreibung bezieht sich nicht unbedingt in allen Fällen auf das gleiche Ausführungsbeispiel.

In folgendem näheren Bezug auf die Zeichnungen, in denen die gleichen Bauteile durchgängig mit den gleichen bzw. ähnlichen Bezugsziffern bezeichnet sind, veranschaulicht die Abbildung aus 1 ein System 100, das sich zur Ausführung eines Ausführungsbeispiels der Erfindung eignet. Gemäß der Abbildung aus 1 umfasst das System 100 einen Client 102 und eine Server 104, die über ein Zwischenverbindungssystem 104 miteinander verbunden sind. Der Begriff "Client" kann sich in dessen Verwendung hierin auf jedes Informationen anfordernde Subjekt beziehen. Der Begriff "Server" kann sich in der Verwendung hierin auf jeden Provider bzw. Anbieter von Informationen beziehen.

Die Abbildung aus 2 zeigt ein Blockdiagramm eines Client-Systems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Abbildung aus 2 veranschaulicht einen Client 200, der den Client 102 darstellen kann. Gemäß der Abbildung aus 2 umfasst der Client 200 einen Prozessor 202, einen Speicher 204 und eine Schnittstelle 208, die alle über die Verbindung 210 verbunden sind. Der Speicher 204 kann Programmanweisungen und Daten speichern. Der Begriff "Programmanweisungen" oder "Programmbefehle" umfasst Computercodesegmente, die Wörter, Werte und Symbole einer vordefinierten Computersprache umfassen, die wenn sie auf vorbestimmte Weise oder Syntax kombiniert werden, bewirken, dass ein Prozessor eine bestimmte Funktion ausführt. Zu Beispielen für eine Computersprache zählen C, C++ und Assembliersprache. Der Prozessor 202 führt die Programmanweisungen aus und verarbeitet die in dem Speicher 204 gespeicherten Daten. Die Schnittstelle 208 koordiniert den Transport von Daten von dem Client 200 zu einer anderen Vorrichtung. Die Verbindung 210 transportiert bzw. überträgt die Daten zwischen dem Prozessor 202, dem Speicher 204 und der Schnittstelle 208.

Bei dem Prozessor 202 kann es sich um jeden Prozessortyp handeln, der in der Lage ist, die für verschiedene Ausführungsbeispiele der Erfindung wünschenswerte Geschwindigkeit und Funktionalität bereitzustellen. Zum Beispiel kann es sich bei dem Prozessor 202 um einen Prozessor aus einer Prozessorfamilie der Hersteller Intel Corporation, Motorola, Compaq oder Sun Microsystems handeln. In einem Ausführungsbeispiel der Erfindung kann es sich bei dem Prozessor 202 um einen dedizierten Prozessor zur Verwaltung von Ein-Ausgabevorrichtungen (E/A-Vorrichtungen) handeln, wie zum Beispiel von Festplattenlaufwerken, Tastaturen, Druckern, Netzwerkschnittstellenkarten, etc. Dieser Prozessor wird für gewöhnlich als ein E/A-Prozessor (EAP) bezeichnet.

In einem Ausführungsbeispiel der Erfindung umfasst der Speicher 204 ein maschinenlesbares Medium und kann jedes Medium einschließen, das Anweisungen bzw. Befehle speichern kann, die von einem Prozessor ausgeführt werden können. Einige Beispiele für derartige Medien sind unter anderem und ohne einzuschränken Nur-Lesespeicher (ROM), Direktzugriffsspeicher (RAM), programmierbare ROM, löschbare programmierbare ROM, elektronisch löschbare, programmierbare ROM, dynamische RAM, Magnetplatten (z.B. Floppy-Disks und Festplattenlaufwerke), optische Plattenspeicher (z.B. CD-ROM) und andere Medien, die digitale Informationen speichern können. In einem Ausführungsbeispiel der Erfindung werden die Anweisungen in einem komprimierten und/oder verschlüsselten Format auf dem Medium gespeichert. Die hierin verwendete Phrase "zur Ausführung durch einen Prozessor geeignet" oder ähnliche Formulierungen schließen in einem komprimierten und/oder verschlüsselten Format gespeicherte Anweisungen ebenso ein wie Anweisungen, die kompiliert oder durch eine Installationsroutine installiert werden müssen, bevor sie durch den Prozessor ausgeführt werden. Ferner kann der Client 200 verschiedene Kombinationen von maschinenlesbaren Speichervorrichtungen bis zu verschiedenen E/A-Steuereinheiten aufweisen, auf welche der Prozessor 202 zugreifen kann, und die in der Lage sind eine Kombination von Anweisungen und Daten von Computerprogrammen zu speichern.

Der Speicher 204 kann Programmanweisungen und Daten speichern und deren Ausführung durch den Prozessor 202 ermöglichen, um die Funktionen eines Client zu implementieren, wie etwa des Client 106 und des Client 200. In einem Ausführungsbeispiel der Erfindung weist der Speicher 204 eine Gruppe von Programmanweisungen auf, die gemeinsam hierin als Dateisystemschnittstelle 206 bezeichnet werden.

Bei der Dateisystemschnittstelle 206 kann es sich um eine Schnittstelle handeln, die so arbeitet, dass sie einen Zugriff auf eine oder mehrere Dateien für das System 100 bereitstellt. Eine Schnittstelle kann sich in diesem Kontext auf ein definiertes Protokoll beziehen, durch das ein Softwaremodul auf Funktionen eines anderen Softwaremoduls zugreifen kann. Eine Datei bezieht sich in diesem Kontext auf eine diskrete Gruppe von in einem Speicher gespeicherten Daten, wie etwa in dem Speicher 204 oder auf einem Festplattenlaufwerk. Die Dateisystemschnittstelle 206 kann eine Anforderung zur Ausführung bestimmter Operationen für eine Datei empfangen, wie etwa Erzeugen, Öffnen, Suchen, Lesen, Schreiben, Umbenennen, Löschen, Kopieren, Verschieben, etc. Die Anforderung kann ihren Ursprung zum Beispiel in einem Host-Betriebssystem oder einem Anwendungsprogramm haben. Ein Host-Betriebssystem kann ein Betriebssystem für ein System umfassen. Wenn ein Ausführungsbeispiel eines Anwendungsprogramms zum Beispiel als Teil eines Personalcomputers implementiert wird, kann das Host-Betriebssystem ein Betriebssystem umfassen, das von der Microsoft Corporation vertrieben wird, wie zum Beispiel Microsoft Windows® 95, 98, 2000 oder NT.

In einem Ausführungsbeispiel der Erfindung arbeitet die Dateisystemschnittstelle 206 als ein Betriebssystem-Servicemodul (OSM als englische Abkürzung von Operating System Service Module) gemäß der Intelligent I/O Specification (I2O), entwickelt von der I2O Special Interest Group (SIG) (I2O SIG), Version 1.5, vereinbart im April 1997 und erhältlich unter "www.i20sig.org" ("I2O Spezifikation"), wobei der Umfang der vorliegenden Erfindung jedoch nicht diesbezüglich beschränkt ist.

Als Hintergrundinformation sei erwähnt, dass die I2O Spezifikation eine Standardarchitektur definiert für die intelligente Ein-Ausgabe, die unabhängig ist sowohl von der jeweils gesteuerten Vorrichtung als auch dem Host-Betriebssystem (OS). Intelligente E/A bezieht sich in diesem Kontext auf die Verschiebung der Funktion der Verarbeitung von Low-Level-Unterbrechungen von einer Zentraleinheit (CPU) oder einem anderen Prozessor zu E/A-Prozessoren (EAPs), die speziell entwickelt worden sind, um die Verarbeitung von E/A-Funktionen bereitzustellen. Dies kann sowohl die E/A-Leistung verbessern als auch es ermöglichen, dass die CPU oder ein anderer Prozessor eine Verarbeitungsfunktionalität für andere Aufgaben bereitstellt. Eine Unterbrechung bezeichnet in diesem Kontext eine Anforderung für einen Zugriff auf eine E/A-Vorrichtung, wie etwa ein Festplattenlaufwerk, ein Floppy-Disk-Laufwerk, einen Drucker, einen Monitor, eine Tastatur, eine Netzwerkschnittstellenkarte (NIC), etc.

Die I2O Spezifikation beschreibt ein OSM, ein Intermediate Service Module (ISM) (intermediäres Dienstmodul) und ein Hardware Device Module (HDM) (Hardware-Vorrichtungsmodul). Das OSM kann einen Treiber darstellen, der als eine Schnittstelle zwischen einem Host-OS und einem ISM arbeitet. Ein Treiber bezieht sich in diesem Kontext auf eine Gruppe von Programmanweisungen, die Operationen einer bestimmten Komponente, Vorrichtung oder eines Softwaremoduls verwalten. Das ISM kann als eine Schnittstelle zwischen dem OSM und einem Hardware Device Module (HDM) arbeiten. Das ISM kann eine bestimmte Funktionalität für die E/A-Managementfunktionen, Netzwerkprotokolle oder Peer-to-Peer-Funktionen ausführen, wie etwa die Archivierung im Hintergrund. Das HDM kann ein Treiber bzw. eine Steuereinrichtung sein, der bzw. die zur Steuerung einer bestimmten E/A-Vorrichtung fungiert.

Die I2O Spezifikation definiert ein Kommunikationsmodell, das ein Nachrichtenübertragungssystem umfasst. Das OSM, das ISM und das HDM kommunizieren und koordinieren Operationen, indem Informationen in Form von Nachrichten über eine Nachrichtenschicht übertragen werden. Eine Nachrichtenschicht kann in diesem Kontext Anforderungen verwalten und ausgeben, eine Gruppe von Application Programming Interfaces (APIs) für die Zustellung von Nachrichten bereitstellen und eine Reihe von unterstützenden Routinen für die Verarbeitung von Nachrichten bereitstellen.

In einem Ausführungsbeispiel der Erfindung arbeitet die Dateisystemschnittstelle 206 als ein OSM gemäß der I2O Spezifikation. In einem Ausführungsbeispiel der Erfindung empfängt die Dateisystemschnittstelle 206 Dateianforderungen von einem Anwendungsprogramm über das Host-OS, setzt die Anforderung gemäß der I2O Spezifikation in eine Nachricht um und sendet sie an einen Dateisystemmanager (nachstehend beschrieben) zur Verarbeitung. Ein Anwendungsprogramm bezieht sich in diesem Kontext auf ein Programm, das eine vorbestimmte Gruppe von Funktionen für spezielle Aufgaben bereitstellt, für gewöhnlich mit einer Benutzeroberfläche bzw. Benutzerschnittstelle zur Erleichterung der Verarbeitung von Befehlen und Anweisungen zwischen einem Benutzer und dem Computersystem. Zu Beispielen für Anwendungsprogramme können ein Textverarbeitungsprogramm, ein Tabellenkalkulationsprogramm, ein Datenbankprogramm oder ein Internet Browser zählen.

Die Schnittstelle 208 kann jede geeignete Technik umfassen, um Kommunikationssignale zwischen Computer- und Netzwerkvorrichtungen zu übertragen, wie zum Beispiel unter Verwendung einer gewünschten Reihe von Kommunikationsprotokollen, Diensten und funktionalen Prozeduren. In einem Ausführungsbeispiel der Erfindung kann die Schnittstelle 208 zum Beispiel gemäß der PCI Spezifikation und der I2O Spezifikation arbeiten. In einem anderen Ausführungsbeispiel kann die Schnittstelle 208 gemäß dem TCP-Protokoll (Transmission Control Protocol) arbeiten, gemäß der Definition durch den Standard 7 der Internet Engineering Task Force (IETF), Request For Comment (RFC) 793, vereinbart im September 1981, und gemäß dem IP-Protokoll (Internet Protocol), gemäß der Definition durch den IETF-Standard 5, RFC 791, vereinbart im September 1981, beide abrufbar bzw. verfügbar unter "www.ietf.org". Die Schnittstelle 208 kann zwar gemäß den vorstehend beschriebenen Protokollen arbeiten, wobei aber auch festgestellt wird, dass die Schnittstelle 208 mit jeder geeigneten Technik zur Steuerung von Kommunikationssignalen zwischen Computer- oder Netzwerkvorrichtungen zum Beispiel unter Verwendung einer gewünschten Gruppe von Kommunikationsprotokollen, Diensten und funktionalen Prozeduren gemäß dem Umfang der vorliegenden Erfindung arbeiten kann.

Die Schnittstelle 208 weist ferner Verbindungseinrichtungen bzw. Konnektoren für die Verbindung der Schnittstelle 208 mit einem geeigneten Kommunikationsmedium auf. Die Schnittstelle 208 kann Kommunikationssignale über jedes geeignete Medium empfangen, wie zum Beispiel Kupferzuleitungen, verdrillte Leitungsdrähte, Koaxialkabel, Lichtwellenleiter, Funkfrequenzen, etc. In einem Ausführungsbeispiel der Erfindung eignen sich die Verbindungseinrichtungen für einen Einsatz in Verbindung mit einem Bus zum Führen von Signalen, die der PCI-Spezifikation entsprechen.

Die Abbildung aus 3 zeigt ein Blockdiagramm eines Serversystems gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Abbildung aus 3 veranschaulicht einen Server 300, der einen Server 106 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt. Gemäß der Abbildung aus 3 umfasst der Server 300 einen Prozessor 302, einen Speicher 304 und eine Schnittstelle 308, die alle über die Verbindung 310 miteinander verbunden sind. Die Elemente 302, 304, 308 und 310 aus 3 weisen einen ähnlichen Aufbau und eine ähnliche Funktionsweise auf wie die entsprechenden Elemente 202, 204, 208 und 210, die in Bezug auf die Abbildung aus 2 beschrieben worden sind. Der Server 300 ist zwar mit einem Prozessor 302 abgebildet, wobei ersichtlich ist, dass der Server 300 auch ohne Prozessor 302 funktionsfähig sein kann, indem ein anderer Prozessor eingesetzt wird, der dem Server 300 zur Verfügung steht (z.B. der Prozessor 202), und wobei dies auch dem Umfang der vorliegenden Erfindung entspricht. Eine derartige Konfiguration kann zum Beispiel auftreten, wenn die Ausführungsbeispiele der Erfindung in einen Personalcomputer integriert werden, wobei der Client und der Server über einen PCI-Bus miteinander verbunden sind, und wobei beide einen einzigen Prozessor gemeinsam nutzen.

In einem Ausführungsbeispiel der Erfindung weist der Speicher 304 Programmanweisungen für einen Dateisystemmanager 306 auf. Der Dateisystemmanager 306 führt eine Dateiverwaltung aus und stellt den Zugriff auf ein Speichermedium (nicht abgebildet) bereit, das eine Mehrzahl von Dateien aufweist. Das Dateisystem 306 führt Dateioperationen aus, wie zum Beispiel Erzeugen, Öffnen, Suchen, Lesen, Schreiben, Umbenennen, Löschen, Kopieren, Verschieben, etc, und zwar als Reaktion auf den Empfang von Dateianforderungen von der Dateisystemschnittstelle 206. Ein Beispiel für eine Dateisystemschnittstelle 206 umfasst ein ISM, das gemäß der I2O Spezifikation arbeitet, wobei der Umfang der vorliegenden Erfindung diesbezüglich jedoch nicht beschränkt ist.

Die Funktionsweise der Systeme 100, 200 und 300 wird nachstehend im text in Bezug auf die Abbildungen der 4 und 5 näher beschrieben. Die hierin vorgesehenen 4 und 5 weisen zwar eine bestimmte Operationsfolge auf, wobei hiermit jedoch festgestellt wird, dass die Operationsfolge nur ein Beispiel dafür ist, wie die hierin beschriebene allgemeine Funktionalität implementiert werden kann. Ferner muss die Operationsfolge nicht unbedingt in der dargestellten Reihenfolge ausgeführt werden, sofern keine anderen Angaben gemacht werden.

Die Abbildung aus 4 zeigt ein Blockablaufdiagramm der von einem Client gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführten Operationen. In dem vorliegenden Ausführungsbeispiel der Erfindung arbeitet die Dateisystemschnittstelle 206 als Teil des Client 106. Hiermit wird festgestellt, dass gemäß dem Umfang der vorliegenden Erfindung die Dateisystemschnittstelle 206 aber auch durch jede Vorrichtung oder Kombination von Vorrichtungen implementiert werden kann, die an beliebiger Stelle in einem Computer oder Netzwerksystem angeordnet sind.

Wie dies in der Abbildung aus 4 dargestellt ist, empfängt ein Client eine Anforderung für den Zugriff auf eine Datei mit einem Dateinamen in dem Block 402. Der Client ordnet den Dateinamen in dem Block 404 einen Bezeichner zu. Der Client sendet den zugeordneten Bezeichner und den Dateinahmen in dem Block 406 zu einem Server. Der Client stellt den zugeordneten Bezeichner und Dateinamen in dem Block 408 in dem Speicher wieder her. Der Client empfängt in dem Block 410 eine Bestätigungsnachricht von dem Server.

Nachdem der Client einer Datei einen Bezeichner zugewiesen hat, wir der Bezeichner für zukünftige Anforderungen der Datei eingesetzt. Der Client empfängt eine zweite Anforderung an dem Client für einen Zugriff auf die Datei. Der Client ruft den dem Dateinamen zugeordneten Bezeichner aus dem Speicher ab. Der Client sendet die zweite Anforderung unter Verwendung des zugeordneten Bezeichners an den Server.

Die Abbildung aus 5 zeigt ein Blockablaufdiagramm der von einem Server gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführten Operationen. In dem vorliegenden Ausführungsbeispiel der Erfindung arbeitet der Dateisystemmanager 306 als Teil des Client 106. Hiermit wird festgestellt, dass gemäß dem Umfang der vorliegenden Erfindung diese Funktionalität aber auch durch jede Vorrichtung oder Kombination von Vorrichtungen implementiert werden kann, die sich an einer beliebigen Stelle in einem Computer oder Netzwerksystem befindet.

Wie dies in der Abbildung aus 5 dargestellt ist, empfängt ein Server einen Dateinamen und einen zugeordneten Bezeichner für eine Datei in dem Block 502. Der Server sendet in dem Block 504 eine Bestätigungsnachricht an den Client. Der Server sucht in dem Block 506 nach Positionsinformationen für die Datei. In dem Block 508 ordnet der Server Positionsinformationen dem Bezeichner zu. Der Server speichert die zugeordneten Positionsinformationen und den Bezeichner im Speicher.

Nachdem der Server die Positionsinformationen für eine Datei unter Verwendung des Bezeichners indiziert, kann der Server den Bezeichner einsetzen, um auf die Positionsinformationen für folgende Dateianforderungen zuzugreifen. Der Server empfängt eine zweite Anforderung für einen Zugriff auf die Datei mit dem Bezeichner. Der Server ruft die Positionsinformationen unter Verwendung des Bezeichners aus dem Speicher ab.

Die Funktionsweise der Systeme 100, 200 und 300 und der Ablaufdiagramme aus den Abbildungen der 4 und 5 wird durch ein Beispiel besser verständlich. Ein Anwendungsprogramm sendet eine Anforderung zum Lesen von Informationen aus einer Datei mit einem Dateinamen "Test File One" ("Testdatei eins") an das Host-OS des Systems 100. Ein eindeutiger Bezeichner bezeichnet in diesem Kontext eine Reihe von alphanumerischen Zeichen, die kombiniert ein eindeutiges Wort, einen Wert oder eine binäre Zeichenfolge an den Client, Server und/oder das System in Bezug auf andere Wörter, Werte oder binäre Zeichenfolgen bereitstellen, die von dem Client, dem Server und/oder System verwendet werden. Das Host-OS leitet die Dateianforderung an die Dateisystemschnittstelle 206. Die Dateisystemschnittstelle 206 erzeugt einen eindeutigen Bezeichner "A123" und weist diesen dem Dateinamen "Testdatei eins" zu. In dem vorliegenden Ausführungsbeispiel der Erfindung kann es sich bei dem eindeutigen Bezeichner "A123" zum Beispiel um eine hexadezimale 32-Bit-Ziffer handeln. Die Dateisystemschnittstelle 206 erzeugt eine Nachricht "Identifizieren (Testdatei Eins, A123)" und platziert diese in einer abgehenden Nachrichtenwarteschlange für eine Übertragung über die Verbindung 104 zu dem Dateisystemmanager 306. Die abgehende Nachrichtenwarteschlange bezeichnet in diesem Kontext eine Warteschlange, wie etwa First-in-First-out (FIFO), die eingesetzt wird, um Nachrichten zu speichern, bis das Zwischenverbindungssystem die Nachricht transportieren kann. Die Dateisystemschnittstelle 206 speichert "Testdatei eins" mit "A123" in einer Verweistabelle in dem Speicher 204.

Der Dateisystemmanager 306 empfängt die Nachricht über die Verbindung 104. Der Dateisystemmanager 306 analysiert die Nachricht und ruft die Funktion "Identifizieren (Testdatei eins, A123)" auf. Der Begriff "analysieren" bezieht sich in dem Kontext auf das Separieren einzelner Zeichen oder Teilgruppen von Zeichen aus der Nachricht, die zum Beispiel Befehle, Steuerwörter, Dateinamen, Daten, Funktionsaufrufe, Subroutinenbezeichnungen, Flaggen, etc. darstellen. Der Begriff "aufrufen" bezieht sich in diesem Kontext auf einen Befehl, der zu dem Prozessor gesendet wird, um die Ausführung von Programmanweisungen zu beginnen, die einer bestimmten Funktion der Subroutine bzw. Unterroutine zugeordnet sind. Die Eingaben der Funktion sind "Testdatei eins" und "A123", und sie informiert den Systemmanager 306, dass der Dateiname "Testdatei eins" in den folgenden Dateianforderungen als "A123" referenziert wird. Dies kann erreicht werden durch Aktualisieren der Verweistabelle in dem Speicher durch Speichern des Dateinamens und des eindeutigen Bezeichners gemeinsam als entsprechende oder verknüpfte Begriffe, das heißt, eine der Begriffe kann durch Suchen nach dem anderen Begriff gefunden werden. Der Dateisystemmanager 306 sucht nach Positionsinformationen für die Datei "A123", die sich für gewöhnlich in einer Speichervorrichtung wie etwa einer Festplatte befindet. Zu den Beispielen für Positionsinformationen können Adressierungsinformationen, Vorrichtungs-, Zylindernummer und Track-Nummer zählen, wobei der Umfang der vorliegenden Erfindung diesbezüglich jedoch nicht begrenzt ist. Der Dateisystemmanager 306 ordnet die Positionsinformationen dem Bezeichner "A123" zu und speichert die Positionsinfonnationen mit dem Bezeichner "A123" in einer Verweistabelle in dem Speicher 304. Der Dateisystemmanager 306 sendet eine Bestätigungsnachricht an die Dateisystemschnittstelle 206, dass der Dateinamensbezeichner und Positionsinformationen empfangen worden sind. Eine Bestätigungsnachricht bezieht sich in diesem Kontext auf eine kurze Nachricht, welche anzeigt, dass eine vorherige Nachricht empfangen worden ist. Die Bestätigungsnachricht kann ein einzelnes Bit, Zeichen, Wort oder eine Phrase umfassen, ganz wie dies von dem jeweiligen System verlangt wird.

Folgende Dateianforderungen, die von dem Dateisystemmanager 306 empfangen werden, verwenden dann den Bezeichner "A123" bei der Anforderung von Operationen für den Dateinamen "Testdatei eins". Zum Beispiel empfängt die Dateisystemschnittstelle 206 eine zweite Anforderung für die Ausführung einer Operation "Löschen" ("Delete") für "Testdatei eins". Die Dateisystemschnittstelle 206 ruft den bereits vorher zugeordneten Bezeichner "A123" für "Testdatei eins" aus dem Speicher ab. Die Dateisystemschnittstelle 206 sendet eine Nachricht "Löschen('A123')" an den Dateisystemmanager 306. Der Dateisystemmanager 306 empfängt die Nachricht "Löschen('A123')" und ruft die Positionsinformationen für den Dateinamen "Testdatei eins" aus dem Speicher ab. Der Dateisystemmanager 306 führt danach die angeforderte Dateioperation unter Verwendung der abgerufenen Dateiinformationen aus.

In einem Ausführungsbeispiel der vorliegenden Erfindung kann die Systemschnittstelle 206 als ein OSM gemäß der I2O Spezifikation und einem bestimmten Host-OS wie etwa Linux OS Version 2.3.99 Pre-3 Kernel, erhältlich von "www.kernel.org" ("Linux Kernel") implementiert werden. In dem vorliegenden Ausführungsbeispiel der Erfindung kann das OSM ferner ein Stream Forest-OSM, ein Stream Tree-OSM und eine Klassenspezifikation umfassen. Eine Klasse kann sich in diesem Kontext auf eine bestimmte Schnittstellendefinition beziehen. Ein Baum bzw. Tree kann sich in diesem Kontext auf eine Sammlung von Speicherobjekten beziehen, die als Kegel (Cones) bezeichnet werden. Ein Objekt kann sich in diesem Kontext auf eine Instanz einer Klasse beziehen. Ein Kegel kann sich in diesem Kontext auf ein Speicherobjekt beziehen, das zum Beispiel die Lese-, Schreib- und Sperrfunktionen unterstützt. Ein Forest bzw. Baum kann sich in diesem Kontext auf eine Reihe von Bäumen beziehen.

In dem vorliegenden Ausführungsbeispiel kann ein Stream Forest-OSM eingesetzt werden, um eine Ansammlung von Dateisystemen zu modellieren. Das Stream Forest-OSM kann Dateibenennungsoperationen bereitstellen, wie zum Beispiel das Erzeugen eines Namens, das Löschen eines Namens oder das Umbenennen eines bestimmten Forests bzw. Walds. Ferner können auch Operationen zum Öffnen und Schließen unterstützt werden. Das Tree-OSM kann zur Modellabbildung eines bestimmten Dateisystems eingesetzt werden. Eine Datei kann als ein Kegel modelliert werden. Das Stream Forest-OSm kann auch so arbeiten, dass es Dateioperationen unterstützt, wie zum Beispiel die Benennung einer Datei, die Umbenennung einer Datei, das Löschen einer Datei, das Sperren bzw. Schützen einer Datei vor Veränderungen, das Lesen einer Datei oder das Beschreiben einer Datei.

Das OSm kann so gestaltet sein, dass es mit einem ISM kommuniziert. Das ISM kann ferner ein Stream Forest-ISM und ein Stream Tree-ISm umfassen. Das Stream Forest-ISM kann die Benennungsfunktionalität des Dateisystems des OSM unterstützen. In einem Ausführungsbeispiel der Erfindung kann das Stream Tree ISM Stream-Kegel-Bezeichner mit Längen von 28 Zeichen unterstützen. Das Stream Tree-ISM kann ferner 215 offene Stream-Kegel sowie 232 mögliche Stream-Kegel unterstützen. Das Tree-ISM kann 262 Bytes für alle enthaltenen Stream-Kegel unterstützen. Hiermit wird festgestellt, dass diese Werte den Umfang der vorliegenden Erfindung diesbezüglich nicht einschränken.

Im Betrieb können das Stream Tree-OSM, das Stream Forest-OSM, das Stream Tree-ISM und das Stream Forest-ISM alle unter Verwendung eines Messaging-Modells gemäß einer Klassenspezifikation gemäß der nachstehenden Beschreibung kommunizieren. Dieses Messaging-Modell bzw. Nachrichtenmodell wird als Streaming Messaging-Modell bezeichnet und wird nachstehend im Text näher beschrieben. Ein Host-OS kann die durch das Stream Forest-OSM und das Stream Tree-OSM bereitgestellte Funktionalität einsetzen bzw. nutzen. Das Host-OS kann das Stream Forest-OSM einsetzen, um die Gruppierung von Dateisystemen zu modellieren, und das Stream Tree-OSM um zum Beispiel ein bestimmtes Dateisystem zu modellieren. Das Stream Forest-OSM kann das Stream Forest-ISM einsetzen, um die Gruppierungen der Dateisysteme in einer IRTOS-Umgebung zu verwalten. Das Stream Tree-OSM kann das Stream Tree-ISM einsetzen, um ein Dateisystem in einer I2O Echtzeit-Betriebssystemumgebung (IRTOS) zu verwalten. Das Stream Forest-OSM und das Stream Tree-OSM können entsprechend mit dem Stream Forest-ISM und dem Stream Tree-ISM unter Verwendung des Stream-Messaging-Modells kommunizieren. Das vorliegende Ausführungsbeispiel der Erfindung wird in Bezug auf die Abbildung aus 7 näher beschrieben.

Die Abbildung aus 6 veranschaulicht eine Softwarearchitektur gemäß einem Ausführungsbeispiel der Erfindung. Wie dies in der Abbildung aus 6 dargestellt ist, kann ein System 600 eine Dateisystemschnittstelle umfassen, die ein Stream Forest-OSM 602, ein Linux OS 604, ein Linux Virtual File System (VFS) 606, ein Stream Tree-OSM 608 und einen oder mehrere Linux I2O-Treiber 610 aufweist. Die Linux I2O-Treiber 610 können gemäß dem Linux Kernel und der I2O Spezifikation arbeiten. Die Linux I2O-Treiber 610 können PCI I2O Treiber 612 aufweisen. Die PCI I2O Treiber 612 können gemäß der PCI Spezifikation und der I2O Spezifikation arbeiten.

Die Dateisystemschnittstelle kommuniziert mit einem Dateisystemmanager über einen Bus 614, der Signale gemäß der PCI Spezifikation kommuniziert. Der Dateisystemmanager kann ein Stream Forest-ISM 616, ein Stream Tree-ISM 618, ein Redundant Array of Inexpensive Disks (RAID) ISM 620, ein Small Computer System Interface (SCSI) HDM 622 und ein IRTOS 624 umfassen.

In dem vorliegenden Ausführungsbeispiel der Erfindung können die in dem System 600 dargestellten Module unter Verwendung der Programmiersprache implementiert wird, wobei der Umfang der vorliegenden Erfindung jedoch diesbezüglich nicht beschränkt ist. In dem vorliegenden Ausführungsbeispiel der Erfindung unterstützen die in dem System 600 dargestellten Module ferner Bezeichner mit einer Länge von 256 Zeichen.

Das Stream Tree-OSM 608 kann so konfiguriert werden, dass es Zugriff auf ein kennzeichnendes Dateisystem bereitstellt. Das Stream Tree-OSM 608 kann so konfiguriert werden, dass es eine oder mehrere erforderliche Funktionen von Linux VFS unterstützt, wie dies in der Linux Spezifikation definiert ist. Das Stream Tree-OSM 608 kann so konfiguriert werden, dass es Stream Tree-Klassennachrichten unterstützt, wie dies nachstehend im Text näher beschrieben wird. Das Stream Tree-OSM 608 kann so konfiguriert werden, dass es mit dem Linux OS 604 arbeitet, zum Beispiel unter Verwendung des Linux Kernel. Das Stream Tree-OSM 608 kann ein Stream Tree-ISM unterstützen, wie zum Beispiel das Stream Tree-ISM 618.

Das Stream Forest-OSM 602 kann die Funktion loct() kernel Interface bereitstellen. Das Stream Forest-OSM 602 kann so arbeiten, dass es einen Stream Tree in einem Stream Forest erzeugt, unter Verwendung eines Funktionsnamen wie etwa "IOCTL_SF_TREECREATE". Diese Funktion kann als Eingaben zum Beispiel einen Eingangspuffer akzeptieren, wie dieser in der Programmiersprache C wie folgt definiert ist:

Ferner kann das Stream Forest-OSM 602 so arbeiten, dass es einen bestehenden Stream Tree umbenennt unter Verwendung eines Funktionsnamen wie etwa "IOCTL_SF_TREERENAME". Diese Funktion akzeptiert als Eingaben zum Beispiel einen Eingangspuffer, der in der Programmiersprache C wie folgt definiert ist:

Ferner kann das Stream Forest-OSM 602 so arbeiten, dass es einen bestehenden Stream Tree löscht unter Verwendung eines Funktionsnamen wie etwa "IOCTL_SP_TREEERASE". Diese Funktion akzeptiert als Eingaben zum Beispiel einen Eingangspuffer, der in der Programmiersprache C wie folgt definiert ist:

Das Stream Forest-OSM 602 kann eine oder mehrere der folgenden Datenstrukturen einsetzen. Eine hierin als "Superblock" bezeichnete Datenstruktur kann eingesetzt werden, um den ersten "inode" eines Dateisystems darzustellen. Ein "inode" kann sich in diesem Kontext auf einen Dateiknoten des Dateisystems beziehen. Eine Superblock-Operationsliste kann eine Gruppierung von Funktionen sein, die zum Manipulieren des Superblocks verwendet werden. Eine inode-Datensatz-Datenstruktur kann eingesetzt werden, um jeden Dateiknoten des Dateisystems darzustellen. Eine inode-Operationsliste kann eine Gruppierung von Funktionen darstellen, die eingesetzt werden, um einen inode zu manipulieren. Eine Dateidatensatz-Datenstruktur kann eingesetzt werden, um eine Zusammenfassungsdatei in einem Dateisystem darzustellen. Eine Dateioperationsliste kann zur Unterstützung von Dateioperationen eingesetzt werden. Alle diese Datenstrukturen in Kombination mit den Operationen der Operationsliste können zur Darstellung eines Dateisystems eingesetzt werden.

Stream Tree-Klassennachrichten können für verschiedene der Datenstrukturen ausgegeben werden. Eine Stream Tree-Klassennachricht kann zum Beispiel für die inode-Operationen Erzeugen; Verweisen, Verzeichnis erstellen ("mkdir"), Verzeichnis entfernen ("rmdir") und Verzeichnis umbenennen ausgegeben werden. Eine Stream Tree-Klassennachricht kann für verschiedene Dateioperationen ausgegeben werden, wie zum Beispiel Öffnen, Lesen, Schreiben, Suchen und Schließen.

Das Stream Forest-OSM 602 kann das enthaltene Dateisystem zum Beispiel mit dem Bezeichner "i2ofs" in dem Linux Kernel registrieren. Das Stream Forest-OSM 602 kann den NULL-Bezeichner zum Beispiel für den Root Tree Cone Container (Stamm-Baum-Kegel-Container) verwenden. Das Stream Forest-OSm 602 kann den Bezeichner "_" für den aktuellen Tree Cone Container verwenden. Das Stream Forest-OSM 602 kann den Bezeichner ".." zum Beispiel für den Parent Tree Cone Container verwenden.

Das System 600 kann Systembeschreibungen für eines oder mehrere der folgenden Module aufweisen:

  • 1. Eine Beschreibung MODULE_AUTHOR für den Kernel;
  • 2. Eine MODULE_DESCRIPTION von "I20 Filesystem Offload Driver"
  • 3. module_init 0, wodurch das Dateisystem registriert werden kann;
  • 4. module_exit 0, wodurch die Registrierung für das Dateisystem aufgehoben werden kann;
  • 5. Ein Modul DECLARE_FSTYPE, das die Parameter des i2ofs i2ofs_type, Read Super Operation und 0 aufweisen kann;
  • 6. Ein OSM-Behandlungsmanagermodul, das ein erstes Handle von Null aufweist, das sich je Handle um 1 erhöht;
  • a. eine interne Softwareschnittstelle AcquireHandle(), die ein ungenutztes Handle abrufen kann; und
  • b. eine interne Softwareschnittstelle ReleaseHandle(int), die ein aktuell genutztes Handle in den freien Pool freigeben kann.

Das System 600 kann ferner die Funktion VFS i2ofs_read_super (struct super_block_*sb, void*options, int silent) bereitstellen. Diese Funktion kann die Eingaben gemäß der Definition in Tabelle 1 akzeptieren.

TABELLE 1

Diese Funktion legt die Werte in der Superblock-Struktur auf 0 fest. Die folgenden Variablen können wie folgt festgelegt werden:

sb->s_blocksize = 512.

sb->s blocksize_bits = 10.

sb->S s magic = F20FS_SUPER_MAGIC

sb->s_op = die in dem OSM definierte Struktur Super_Operationen.

Die Funktion kann einen neuen inode erzeugen unter Verwendung eines Moduls mit der Bezeichnung get_empty_inode(). Der inode kann auf Null gesetzt werden, wobei die verschiedenen zugeordneten Variablen die folgenden Einstellungen aufweisen:

i-node i_uid = 20.

i-node i_gid = 20.

inode-Operationen können auf den Zeiger gesetzt werden, der die inode-Operationsliste beschreibt.

i-node i_fop kann auf den Zeiger gesetzt werden, der die Dateioperationsliste beschreibt.

i-node I_mode kann auf S_IFDIR|S_IRUGO|S_IXUGO gesetzt werden.

i-node kann in die inode Hash-Tabelle eingefühgt werden.

Sb->s_root kann auf d_alloc_root() des Stamm-inode gesetzt werden.

Jedes Dateisystem in VFS 606 kann mindestens einen Superblock aufweisen, der ausreichend Informationen über das Dateisystem enthält, um Aktivität des Dateisystems einzuleiten. Dieser Superblock kann in einer C-Struktur struct super_block wie folgt implementiert werden:

Die Variable super_block->s_op kann die folgenden C-Funktionen aufweisen und Zugriff auf den Superblock bereitstellen.

Ein Beispiel für eine inode-Schnittstelle kann wie folgt gegeben sein:

Die Variable i-node->i_op kann die folgenden C-Funktionen aufweisen und Verfahrenszugriff auf den Superblock wie folgt bereitstellen:

Das System 600 stellt ferner eine Funktion Erzeugen (Create) (struct inode *, const char *, int, int, struct inode **) bereit. Diese Funktion kann die in Tabelle 2 ausgeführten Eingaben akzeptieren.

TABELLE 2

Diese Funktion kann einen neuen inode unter Verwendung von get_empty_inode() erzeugen. Die Funktion kann den neuen inode initialisieren, indem die Variable const char* über eine Dentry-Beziehung angehängt wird. Die Funktion kann die neue inode-Struktur mit der spezifizierten Größe initialisieren. Die Funktion kann die neue inode-Struktur mit dem spezifizierten Modus initialisieren. Die Funktion kann eine Nachricht StreamConeCreate an das Stream Tree-ISM senden. Die Nachricht kann wie folgt konfiguriert sein:

  • 1. HANDLE kann von dem OSM Handle Manager abgerufen werden;
  • 2. TYPE kann auf 1 gesetzt werden, was eine Datei anzeigt; und
  • 3. SGL kann auf NewName gesetzt werden.

Die Dereferenzierung von NewInode kann mit der neuen inode-Struktur festgelegt werden.

Das System kann ferner eine Funktion struct dentry *lookup (struct inode*, struct dentry*) bereitstellen. Diese Funktion kann die in Tabelle 3 aufgeführten Eingaben akzeptieren.

TABELLE 3

Diese Funktion kann eine Nachricht StreamConeIdentify an das Stream Tree-ISM 818 senden. Die Nachricht kann wie. folgt konfiguriert werden:

  • 1. PARENTHANDLE kann auf das Handle gesetzt werden, das in den lokalen inode-Daten ParentDirectory identifiziert ist;
  • 2. CHILDHANDLE kann auf das von dem OSM Handle Manager abgerufene Handle gesetzt werden;
  • 3. ATTRIBUTES kann auf STREAMCONECREATE_QUERY gesetzt werden; und
  • 4. SGL kann auf Name gesetzt werden.

Die Funktion kann einen neuen inode unter Verwendung von get_empty_inode erzeugen. Die Funktion kann den neuen inode initialisieren, indem die Variable const char* über eine Dentry-Beziehung angehängt wird. Die Funktion kann eine Nachricht StreamConeGetInformation an das Stream Tree-ISM senden. Die Nachricht kann wie folgt konfiguriert sein:

  • 1. HANDLE kann auf CHILDHANDLE oben gesetzt werden;
  • 2. SGL kann auf eine lokale Datenstruktur vom Typ Information Result Block gesetzt werden. Die Funktion kann die inode-Werte aus dem Information Result Block setzen. Die Funktion kann die Dereferenzierung der Variable NewInode auf den inode setzen, der erzeugt worden ist.

Das System 600 kann die Funktion mkdir (struct inode *, struct dentry *, int) bereitstellen. Die Funktion kann die in Tabelle 4 aufgeführten Eingaben akzeptieren.

TABELLE 4

Die Funktion kann eine Nachricht StreamConeDirectory zur Erzeugung eines Verzeichnisses senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann auf das Handle gesetzt werden, das in der inode-Struktureingabe ParentDirectory identifiziert ist;
  • 2. TYPE kann auf 2 gesetzt werden; und
  • 3. SGL kann auf den eingegebenen Namen gesetzt werden, der den tatsächlichen Namen aufweist.

Das System 600 kann die Funktion rmdir (struct inode*, struct dentry *) bereitstellen. Die Funktion kann die in Tabelle 5 aufgeführten Eingaben akzeptieren.

TABELLE 5

Die Funktion kann eine Nachricht StreamConeErase zum Entfernen eines Verzeichnisses senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann auf das Handle gesetzt werden, das in der inode-Struktureingabe ParentDirectory identifiziert ist; und
  • 2. SGL kann auf den eingegebenen Namen gesetzt werden.

Das System 600 kann ferner die Funktion rename (struct inode *, struct dentry *, struct inode *, struct dentry *) bereitstellen. Die Funktion kann die in Tabelle 6 aufgeführten Eingaben akzeptieren.

TABELLE 6

Diese Funktion kann eine Nachricht StreamConeIdentity an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. PARENTHANDLE über den OldDir internen inode-Speicher für OSM Handles gesetzt werden;
  • 2. CHILDHANDLE kann auf ein neues Handle gesetzt werden, das von dem OSM Handle Manager abgerufen wird;
  • 3. ATTRIBUTES kann auf STREAMCONECREAT_QUERY gesetzt werden; und
  • 4. SGL kann auf OldName gesetzt werden.

Die Funktion kann eine Nachricht StreamConeRename an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann auf CHILDHANDLE von StreamConeIdentity gesetzt werden;
  • 2. NEWPARENT kann auf NewDir inode interner Speicher der OSM Handles gesetzt werden; und
  • 3. SGL kann auf NewName gesetzt werden.

Die Funktion kann eine Nachricht StreamConeClose an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden: HANDLE kann auf das vorherige HANDLE aus der Nachricht StreamConeRename gesetzt werden.

Das System 600 kann ferner die Funktion truncate (struct inode *) bereitstellen. Die Funktion kann die in Tabelle 7 aufgeführten Eingaben akzeptieren.

TABELLE 7

Die Funktion kann eine Nachricht StreamConeResize an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann von dem internen inode OSM Handle Speicher abgerufen werden; und
  • 2. SIZE kann aus der inode-Variable i_size abgerufen werden.

Jede Datei in VFS 606 kann mindestens einen Superblock aufweisen, der ausreichend Informationen über das Dateisystem aufweisen kann, um die Aktivität des Systems einzuleiten. Der Superblock ist in der C-Struktur struct super_block ausgeführt, wie diese bereits vorstehend im Text beschrieben worden ist. Die Verfahrensvariable f_op kann Zugriff auf Dateioperationen bereitstellen. Die Funktion struct super_operations *s_op kann Zugriff auf den Stamm-inode bereitstellen, was für das OSM wünschenswert sein kann.

Das System 600 kann eine oder mehrere der nachstehend beschriebenen Dateioperationen bereitstellen. Die Variable f->s_op kann die folgenden C-Funktionen aufweisen und Zugriff auf den Superblock bereitstellen.

Das System 600 kann die Funktion Ilseek (struct file *, off_t, int) bereitstellen. Die Funktion kann die in Tabelle 8 aufgeführten Eingaben akzeptieren.

TABELLE 8

Die Funktion kann eine Nachricht StreamConeSeek an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann über den internen inode Speicher für OSM Handles gesetzt werden; und
  • 2. NEWPOSITION kann auf die durch Berechnung von Versatz und Ursprung erhaltene Position gesetzt werden.

Das System 600 kann die Funktion read (struct fi1e *, char *, size_t, ioff_t) bereitstellen. Die Funktion kann die in Tabelle 9 aufgeführten Eingaben akzeptieren.

TABELLE 9

Die Funktion kann eine Nachricht StreamConeRead an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann über den internen inode Speicher für OSM Handles gesetzt werden; und
  • 2. SGL kann auf Puffer und Größe gesetzt werden.

Das System 600 kann die Funktion write (struct file *, const char *, size_t, ioff_t) bereitstellen. Die Funktion kann die in Tabelle 10 aufgeführten Eingaben akzeptieren.

TABELLE 10

Die Funktion kann eine Nachricht StreamConeWrite an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann über den internen inode Speicher für OSM Handles gesetzt werden; und
  • 2. SGL kann auf Puffer und Größe gesetzt werden.

Das System 600 kann die Funktion readdir (struct file *, void *, filldir_t) bereitstellen. Die Funktion kann die in Tabelle 11 aufgeführten Eingaben akzeptieren.

TABELLE 11

Die Funktion kann eine Nachricht StreamConeEnumerate an das ISM senden. Die Nachricht kann wie folgt konfiguriert werden:

  • 1. HANDLE kann über den internen inode Speicher für OSM Handles gesetzt werden; und
  • 2. ENUMERATOR wird auf Count gesetzt.
  • 3. SLG kann auf den Dateinamenspuffer des Eintrags gesetzt werden.
  • 4. SGLs Größe kann auf 255 gesetzt werden.

Das System 600 kann ferner wie folgt eine Dentry-Schnittstelle bereitstellen:

Das Stream Tree-ISM 618 kann eine oder mehrere Stream Tree-Klassennachrichten gemäß der Definition hierin unterstützen. Der Stream Tree 618 kann so arbeiten und Nachrichten von einem Stream Tree-OSM unterstützen, wie etwa dem Stream Tree-OSM 608. Das Stream Forest-ISM 616 kann Stream Forest-Klassennachrichten gemäß der Definition hierin unterstützen. Das Stream Forest-ISM 616 kann so arbeiten und Nachrichten von einem Stream Forest-OSM unterstützen, wie etwa dem Stream Forest-OSM 602.

Das Stream Forest-ISM 616 kann eine Benutzeroberfläche bzw. Benutzerschnittstelle aufweisen. Die Benutzerschnittstelle kann einen Benutzerschirm aufweisen, der eine oder mehrere Stream Trees bei der Initialisierung anzeigen kann. Ein Benutzer kann in der Läge sein, neue Stream Trees zu erzeugen. Bei der Erzeugung neuer Stream Trees kann dem Benutzer ein Bildschirm angezeigt werden, der nach Größe und Identifikation fragt. Wenn ein Stream Tree erzeugt wird, kann ein Stream Tree-Klassenobjekt erzeugt werden. Der Benutzer kann auch in de Lage sein, Stream Trees zu löschen. Die Benutzerschnittstelle kann eine Bestätigung des Löschens von Stream Trees bereitstellen. Stream Forest-Nachrichten können auf angemessene Weise behandelt und Tree Objekte erzeugt werden.

Das System 600 kann die Nachricht StreamConeCreate bereitstellen. Die Nachricht kann zur Erzeugung eines neuen Stream Cones verwendet werden, der Informationen speichert und kann Eingaben gemäß den Ausführungen in Tabelle 12 akzeptieren.

TABELLE 12

Das System 600 kann die Nachricht StreamConeEnumerate bereitstellen. Die Nachricht kann zum Aufführen von einem oder mehreren Stream Cones in einem Stream Cone-Container verwendet werden und kann Eingaben gemäß den Ausführungen in Tabelle 13 akzeptieren.

TABELLE 13

Das System 600 kann den inode in Bezug auf HANDLE von dem Handle Manager abrufen. Wenn ein Enumerator auf 0 gesetzt wird, kann der Bibliotheksaufruf "ext2fs dir_iterat() mit dem inode in Bezug auf die Behandlung als Parent verwendet werden, um eine Liste von Stream Cone-Bezeichnern an dem "ext2" Dateisystem zu erzeugen. Ein dem ENUMERATOR-Index entsprechender Listeneintrag kann in SGL kopiert werden.

Das System 600 kann die Nachricht StreamConeErase bereitstellen. Die Nachricht wird zum Löschen eines Stream Cone-Bezeichners verwendet und kann die Eingaben gemäß den Ausführungen in Tabelle 14 akzeptieren.

TABELLE 14

Das System 600 kann die Nachricht StreamConeGetInformation bereitstellen. Die Nachricht kann zum Abrufen von Informationen über den Stream Cone verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 15 akzeptieren.

TABELLE 15

Das System 600 kann die Nachricht StreamConeIdentity bereitstellen. Die Nachricht kann zum Abbilden eines Handle-Bezeichners auf einen Zeichenfolge-Bezeichner verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 16 akzeptieren.

TABELLE 16

Das System 600 kann die Nachricht StreamConeLock bereitstellen. Die Nachricht kann zum Sperren eines Byte-Bereichs einer Datei verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 17 akzeptieren.

TABELLE 17

Das System 600 kann die Nachricht StreamConeRead bereitstellen. Die Nachricht kann zum Lesen eines Blocks aus einem Stream Cone verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 18 akzeptieren.

TABELLE 18

Das System 600 kann die Nachricht StreamConeRelease bereitstellen. Die Nachricht kann zum Schließen einer Identifikation des spezifizierten Handle verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 19 akzeptieren.

TABELLE 19

Die Funktion kann HANDLE von dem inode-Bezeichner abkoppeln.

Das System 600 kann die Nachricht StreamConeRename bereitstellen. Die Nachricht kann zum Umbenennen eines Stream Cone verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 20 akzeptieren.

TABELLE 20

Das System 600 kann die Nachricht StreamConeResize bereitstellen. Die Nachricht wird zur neuen Größenfestlegung eines Stream Cone verwendet und kann die Eingaben gemäß den Ausführungen in Tabelle 21 akzeptieren.

TABELLE 21

Das System 600 kann die Nachricht StreamConeSeek bereitstellen. Die Nachricht wird zur Veränderung der Position eines Stream Cone verwendet und kann die Eingaben gemäß den Ausführungen in Tabelle 22 akzeptieren.

TABELLE 22

Das System 600 kann die Nachricht StreamConeSetlnformation bereitstellen. Die Nachricht kann Festlegung von Informationen in Bezug auf den Stream Cone verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 23 akzeptieren.

TABELLE 23

Das System 600 kann die Nachricht StreamConeSetUnlock bereitstellen. Die Nachricht kann zum Entsperren eines vorher festgelegten Byte-Sperrbereichs verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 24 akzeptieren.

TABELLE 24

Das System 600 kann die Nachricht StreamConeSetWrite bereitstellen. Die Nachricht kann zum Schreiben eines Blocks an einen Stream Cone verwendet werden und kann die Eingaben gemäß den Ausführungen in Tabelle 25 akzeptieren.

TABELLE 25


Anspruch[de]
Verfahren zur Verwaltung einer Datei, wobei das Verfahren folgendes umfasst:

das Empfangen einer ersten Anforderung an einem Client für einen Zugriff auf eine Datei mit einem Dateinamen (402);

das Erzeugen eines eindeutigen Bezeichners für den genannten Dateinamen an dem genannten Client (404);

das Speichern (404) des genannten Bezeichners und des Dateinamens in einem Speicher an dem genannten Client;

das Senden der genannten ersten Anforderung an einen Dateiserver mit dem genannten eindeutigen Bezeichner und dem genannten Dateinamen (406); und

das Verwenden des genannten eindeutigen Bezeichners für folgende Dateianforderungen für die genannte Datei, ohne auf eine Nachricht von dem genannten Dateiserver zu warten.
Verfahren nach Anspruch 1, wobei dieses ferner das Empfangen einer Bestätigungsnachricht von dem genannten Server (410) umfasst. Verfahren nach Anspruch 1, wobei dieses ferner folgendes umfasst:

das Empfangen einer zweiten Anforderung an dem genannten Client für einen Zugriff auf die genannte Datei;

das Abrufen des genannten Bezeichners, der dem genannten Dateinamen zugeordnet ist, aus dem genannten Speicher; und

das Senden der genannten zweiten Anforderung an den genannten Server unter Verwendung des genannten zugeordneten Bezeichners.
Verfahren nach Anspruch 3, wobei die genannten ersten und zweiten Anforderungen eine Dateioperation spezifizieren. Vorrichtung zur Ausführung einer Dateiverwaltung, wobei die Vorrichtung folgendes umfasst:

einen Client (102), der so angeordnet ist, dass er die Datei gemäß dem Verfahren aus Anspruch 1 verwaltet, wodurch einem Dateinamen ein eindeutiger Bezeichner zugeordnet wird;

einen Server (106), der so angeordnet ist, dass er Dateiinformationen unter Verwendung des genannten Dateinamens lokalisiert und die genannten Dateiinformationen unter Verwendung des genannten Bezeichners speichert; und

ein Zwischenverbindungssystem (104), das so angeordnet ist, dass es den genannten Dateinamen und den genannten Bezeichner zwischen dem genannten Client und dem genannten Server transportiert.
Vorrichtung nach Anspruch 5, wobei der genannte Client ein Betriebssystem-Behandlungsmodul (206) umfasst. Vorrichtung nach Anspruch 5, wobei der genannte Server ein intermediäres Behandlungsmodul (306) umfasst. Vorrichtung nach Anspruch 5, wobei das genannte Zwischenverbindungssystem gemäß einem Peripheral Component Interconnet-System und einem I2O-System arbeitet.






IPC
A Täglicher Lebensbedarf
B Arbeitsverfahren; Transportieren
C Chemie; Hüttenwesen
D Textilien; Papier
E Bauwesen; Erdbohren; Bergbau
F Maschinenbau; Beleuchtung; Heizung; Waffen; Sprengen
G Physik
H Elektrotechnik

Anmelder
Datum

Patentrecherche

Patent Zeichnungen (PDF)

Copyright © 2008 Patent-De Alle Rechte vorbehalten. eMail: info@patent-de.com