DE10085311B3

DE10085311B3 - Verteiltes Dateisystem mit Multicast-Wiedergewinnung

Info

Publication number: DE10085311B3
Application number: DE10085311T
Authority: DE
Inventors: James P. Ketrenos; Charles R. Lynch; Edward R. Rhoads
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 1999-12-17
Filing date: 2000-10-16
Publication date: 2013-10-10
Anticipated expiration: 2020-10-17
Also published as: GB2372357B; US8429248B1; DE10085311T1; CA2392907A1; CA2392907C; HK1046452A1; WO2001044989A3; GB0211570D0; AU1571201A; GB2372357A; TW487857B; HK1046452B; WO2001044989A2

Abstract

Ein Verfahren zum Verarbeiten von Client-Anforderungen in einem Server-Client-Netzwerk, umfassend: Empfangen einer Anforderung eines Clients nach einem Teil eines Dateisystems; Feststellen, ob der angeforderte Teil des Dateisystems in einem ersten Speicher des Clients gespeichert ist, der Teilen des Dateisystems zugeordnet ist und in dem zuvor von dem Client bereits verwendete Teile des Dateisystems gespeichert worden sind; und wenn dies nicht der Fall ist, Feststellen, ob der angeforderte Teil des Dateisystems in einem zweiten Speicher des Clients gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die von einem Server an den Client gestreamt wurden und in dem zweiten Speicher gespeichert wurden.

Description

Hintergrund
Diese Erfindung bezieht sich auf Netzwerke und insbesondere auf die Dateiwiedergewinnung über Netzwerke.
Computernetzwerke werden oftmals unter Verwendung von Modellen beschrieben. Ein Netzwerkmodell, das als Client-Server-Modell bekannt ist, besteht aus Benutzern (den Clients) und Datei-Servern, auf welchen Daten grundsätzlich gespeichert sind. Bei dem Client-Server-Modell macht der Client grundsätzliche eine Anforderung an den Server, der Server bedient die Anforderung, und der Server sendet die Erwiderung zurück zu dem Client. Typischerweise ist das Verhältnis der Zahl der Clients zu den Servern sehr hoch.
Erwartungsgemäß ist der Server typischerweise eine sehr leistungsfähige Maschine hoher Kapazität, die möglicherweise mehrere Prozessoren und eine enorme Speicherkapazität aufweist. Andererseits können, die Clients, welche das Netzwerk belegen, in vielen Konfigurationen daherkommen. Typischerweise jedoch sind die Clients bei ihren Hardwaremerkmalen bescheidener als die Server.
Die Wiedergewinnung (retrieval) von Daten durch einen Client aus einem Server umfaßt eine Verbindung zwischen dem Client und dem Server über das Netzwerk. Diene Verbindung (die manchmal als ”Socket” bezeichnet wird) bleibt während der Dauer der Anforderung lebensfähig (oder geöffnet). Die Verbindung beansprucht Zeit zum Initiieren, was die Netzwerkzugriffe grundsätzlich langsamer macht als lokale Zugriffe, wie beispielsweise die Zugriffe auf eine Festplatte des Clients. Darüber hinaus verbraucht jede Verbindung zwischen einem Client und einem Server Bandbreite. Die auf einem Netzwerk verfügbare Bandbreite ist endlich.
Ein Weg, die erforderliche Netzwerkbandbreite zu verringern, besteht darin, Daten von einem Server auf das Netzwerk im Broadcast auszusenden. Wenn Daten über das Netzwerk im Broadcast ausgesendet worden, wird ein einziger Socket geöffnet. Sämtliche Clients an dem Netzwerk, einschließlich einiger ungewünschter Empfänger, können die Daten empfangen. Eine Multicast-Sendung ist eine weitere Option zum Minimieren der Netzwerkbandbreite. Wie die Broadcast-Sendung ist das Multicasting der Prozeß des Sendens einer Nachricht oder von Daten gleichzeitig an mehr als ein Ziel auf dem Netzwerk. Beim Multicasting jedoch können die gewünschten Clients speziell eingegrenzt werden; unerwünschte Empfänger sind nicht in der Lage, auf die gesendeten Daten zuzugreifen.
Derartige Broadcast- und Multicast-Sendungen sind unter anderem aus dem „Trivial File Transfer Protokoll (TFTP)” (RFC 1350) in Verbindung mit „TFTP Multicast Option” (FFC 2090) und der „Preboot Execution Enviroment (PXE) Specification” bekannt. Hierbei werden Daten von einem Server direkt an mehrere Clients verteilt, wobei ein Client die Kommunikation steuert und die weiteren Clients die Daten nur empfangen.
Aus dem Workshop-Beitrag „Soda: A File System for a Multicomputer”, veröffentlicht in „Proceedings of 1st IEEE Computer Society International Workshop an Cluster Computing” mit der DOI 10.1109/IWCC.1999.810817, ist ein Verfahren zum Verteilen und zwischenspeichern von Daten bekannt. Ein Client, der Daten von einem Datei-Server benötigt, fragt diese bei einem zwischengeschalteten Cache-Server an. Nach Möglichkeit bedient der Cache-Server die Anfrage aus einem lokalen Speicher, ansonsten werden die Daten durch den Cache-Server bei dem Datei-Server angefordert, in dem lokalen Speicher für eventuelle weitere Anfragen eingespeichert sowie an den anfordernden Client ausgeliefert.
Aus dem Workshop-Beitrag „A Multicast-based Ditributed File System for the Internet”, veröffentlicht in ”Proceedings of the 7th workshop on ACM STGOPS European workshop” mit der DOI 10.1145/504450.504469, ist ein Verfahren zum Betrieb eines Clients mit zwei Speichern bekannt. Der erste Speicher wird dabei mit benötigten Daten gefüllt, und der zweite Speicher wird unkorreliert zum Bedarf des Clients mit von einem Netzwerk mitgelesenen Daten gefüllt. Wenn eine Daten-Anforderung des Clients nicht mit Daten des ersten Speicher erfüllt werden kann, wird geprüft, ob diese in dem zweiten vorliegen. In Abhängigkeit dessen wird die Anforderung des Clients auf Basis der im zweiten Speicher vorliegenden Daten bedient, ansonsten werden die Daten von einem Server angefordert.
Bei einigen Clients kann eine lokale Wiedergewinnung (Retrieval) von Server-Dateien oder -Daten gewünscht sein, um sowohl den Zugriff zu beschleunigen als auch die auf dem Netzwerk aufgewendete Bandbreite zu verringern. Jedoch können die benötigten Dateien im vergleich zu der Kapazität des Clients zum lokalen Speichern der Dateien groß sein.
Somit existiert ein Bedürfnis, ein Dateisystem, das auf einem Server angeordnet ist, auf einen oder mehrere Clients in Übereinstimmung mit den speziellen Charakteristika jedes Clients zu verteilen.
Zusammenfassende Darstellung
Im allgemeinen umfaßt gemäß einem Ausführungsbeispiel ein verfahren das Empfangen einer Anforderung für einen Teil eines Dateisystems durch einen Client, das Identifizieren, ob der Teil in einem ersten Ort gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die zuvor von dem Client verwendet worden sind, und wenn dies nicht der Fall ist, das Feststellen, ob der Teil in einem zweiten Ort gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die an den Client von einem Server verströmt (streamed) wurden.
Weitere Aspekte sind in der beigefügten detaillierten Beschreibung, den Zeichnungen und den Ansprüchen angegeben.
Kurzbeschreibung der Zeichnungen
1 ist eine Blockdarstellung einer Konfiguration eines Client-Server-Netzwerks zur Verwendung bei dem verteilten Dateisystem gemäß einem Ausführungsbeispiel der Erfindung;
2 ist eine Blockdarstellung der Aufgaben des Treibers gemäß einem Ausführungsbeispiel der Erfindung;
3 ist ein Ablaufdiagramm der Erzeugung des ersten Speicherorts gemäß einem Ausführungsbeispiel der Erfindung;
4A ist eine Blockdarstellung einer Multicast-Operation gemäß einem Ausführungsbeispiel der Erfindung;
4B ist eine zweite Blockdarstellung einer Multicast-Operation gemäß einem Ausführungsbeispiel der Erfindung; und
5 ist ein Ablaufdiagramm der Wiedergewinnung einer verteilten Datei gemäß einem Ausführungsbeispiel der Erfindung.
Detaillierte Beschreibung
Gemäß einem Ausführungsbeispiel der Erfindung schließt ein verteiltes Dateisystem eine Multicast-Wiedergewinnung (multicast retrieval) für einen oder mehrere an einem Netzwerk angeordnete Clients ein. Ein von dem Client beim Einschalten benötigter Teil des Dateisystems wird einem ersten Speicherplatz auf dem Client zugeteilt. Ein zweiter Abschnitt des Dateisystems wird dann während der Laufzeitoperation des Clients wiedergewonnen (retrieved). Dieser zweite Abschnitt kann aus einem Server an dem Netzwerk als Multicast-Operation wiedergewonnen werden. Die Multicast-Wiedergewinnung erfolgt als Hintergrundoperation. Mit anderen Worten, ein Benutzer an dem Client kann andere Programme ablaufen lassen und andere Operationen ausführen, während die Multicast-Operation auftritt. Das Dateisystem bleibt aus dem Server in Erwiderung auf Anforderungen zugreifbar, welche nicht in dem ersten oder zweiten Speicherort des Clients gespeichert sind.
Wenden wir uns 1 zu; bei einem Ausführungsbeispiel der Erfindung ist ein Dateiserver 10 mit einem Netzwerk 20 gekoppelt. Ein oder mehrere Clients 12 können mit dem Netzwerk 20 ebenfalls gekoppelt sein. Anforderungen durch den Client 12 können an den Server ausgeführt werden, wobei diesen Erwiderungen des Servers 10 an den Client 12 folgen.
Der Client 12 kann ein prozessor-basiertes System, wie beispielsweise ein Desktop-Computersystem, ein Handheld-Computersystem, ein prozessor-basiertes Fernsehsystem, eine Set-Top-Box, ein Gerät, ein dünner Client, ein Mobiltelefon oder dergleichen sein. Das Netzwerk 20 kann ein beliebiges Netzwerk einer Vielzahl von Netzwerken sein, die ein lokales Netzwerk (LAN), ein Stadtbereichsnetzwerk (MAN), ein Weitbereichsnetzwerk (WAN), ein drahtloses Netzwerk, ein Heimnetzwerk oder ein Internetzwerk, wie beispielsweise das Internet, sein.
Ein Dateisystem 22 ist auf dem Dateiserver 10 gespeichert. Das Dateisystem 22 kann auf einem Festplattenlaufwerk 8 gespeichert sein, und es wird auf das Dateisystem durch einen oder mehrere Clients 12 an dem Netzwerk 20 zugegriffen.
Der Client 12 kann sowohl einen ersten Speicherort 24 als auch einen zweiten Speicherort 26 enthalten. Der erste Speicherort 24 kann ein beliebiges Medium aufweisen, welches gespeicherte Informationen einbehält, nachdem die Spannungsversorgung von dem Client 12 weggenommen wird, beispielsweise ein nicht-flüchtiges Medium. Bei einem Ausführungsbeispiel der Erfindung ist der erste Speicherort 24 ein Flash-Speicherbauelement 14. Der erste Speicherort 24 könnte alternativ einen Nur-Lese-Speicher (ROM), einen löschbaren und programmierbaren Nur-Lese-Speicher (EPROM), ein Festplattenlaufwerk, einen Compactdisk-Nur-Lese-Speicher (CDROM) oder ein anderes nicht-flüchtiges Speichermedium enthalten.
Der zweite Speicherort 26 kann ein beliebiges Medium einschließen, welches Daten während des Laufzeitbetriebs des Clients 12 speichern kann. Bei einem Ausführungsbeispiel der Erfindung wird ein Systemspeicher 16 als zweiter Speicherort 26 verwendet. Der Systemspeicher 16 ist flüchtig. D. h., die Daten bleiben nicht in dem Systemspeicher 16, sobald die Spannungsversorgung von dem Client 12 weggenommen wird. Alternativ könnte jedoch ein nicht-flüchtiges Speichermedium, wie beispielsweise eine Festplattenlaufwerk, für den zweiten Speicherort 26 verwendet werden.
Bei einem Ausführungsbeispiel der Erfindung gewinnt der Client 12 einen Teil des Dateisystems 22 oder das gesamte Dateisystem aus dem Server 10. Das wiedergewonnene Dateisystem 22 kann dann in dem ersten Speicherort 24 und dem zweiten Speicherort 26 gespeichert werden. Nachfolgend brauchen Zugriffe auf das Dateisystem 22 durch den Client 12 nicht den Server 10 einzuschließen, wie im folgenden erläutert wird.
Es wird wieder auf 1 Bezug genommen; der Client 12 enthält außerdem ein Festplattenlaufwerk 6, auf welchem ein Betriebssystem 34 gespeichert ist. Das Betriebssystem 34 kann Anforderungen für das Dateisystem 22 aus Anwendungsprogrammen, von dem Benutzer des Clients 12 oder aus anderen Quellen empfangen. Obwohl das Betriebssystem 34 bei einem Ausführungsbeispiel der Erfindung auf dem Festplattenlaufwerk 6 gespeichert ist, könnte das Betriebssystem 34 alternativ in anderen nicht-flüchtigen Medien, wie beispielsweise dem Flash-Speicher 14, gespeichert sein.
Wenden wir uns 2 zu; bei einem Ausführungsbeispiel der Erfindung führt ein Treiber 30 Operationen aus, um sowohl das Dateisystem 22 zu verteilen als auch auf Anforderungen für das Dateisystem 22 zu antworten. Ein Treiber ist eine Hardware-Einrichtung oder ein Programm, das eine andere Einrichtung steuert oder regelt. Der Treiber 30 kann Zugriffe auf das Dateisystem 22 durch den Client 12 steuern. Darüber hinaus kann der Treiber 30 das Speichern eines Teils oder des gesamten Dateisystems 22 auf dem Client 12 steuern.
Bei einem Ausführungsbeispiel der Erfindung kann der Treiber 30 das Dateisystem an den Client 12 verteilen. Die Verteilung des Dateisystems wird an den ersten Speicherort 24 und den zweiten Speicherort 26 des Clients 12 ausgeführt.
Bei einem Ausführungsbeispiel der Erfindung kann der Treiber 30 außerdem auf Anforderungen nach Teilen des Dateisystems 22 antworten. Der Treiber 30 fängt eine Anforderung aus dem Betriebssystem 34 ab und durchsucht den ersten Speicherort 24 des Clients 12 nach dem angeforderten Anteil der Datei. Wenn der angeforderte Teil des Dateisystems 22 nicht gefunden wird, durchsucht der Treiber dann den zweiten Speicherort 26 des Clients 12 nach dem angeforderten Teil. Schließlich gewinnt für den Fall, daß der angeforderte Teil nicht auf dem Client-System 12 gespeichert ist, der Treiber 30 den angeforderten Teil aus dem Server 10, der an dem Netzwerk 20 angeordnet ist.
In 2 sind die Verteilung des Dateisystems 22 und die Antwort auf Anforderungen nach dem Dateisystem 22 als drei verschiedene Operationen gezeigt. Diese drei Operationen können alternativ in Kombination ausgeführt oder gegebenenfalls weiter unterteilt werden. Die Darstellung der 2 dient nur dazu, die verschiedenen Funktionen des Treibers 30 zu veranschaulichen, nicht aber, um dessen Organisation vorzuschlagen.
Eine erste lokale Speicheroperation 40 kann von dem Treiber 30 ausgeführt werden, um einen Teil des Dateisystems 22 in dem ersten Speicherort 24 des Clients 12 zu speichern. Eine zweite lokale Speicheroperation 42 kann von dem Treiber 30 ausgeführt werden, um irgendeinen Teil des Dateisystems 22 in den zweiten Speicherort 26 des Clients 12 zu speichern. Die beiden Operationen 40 und 42 verteilen das Dateisystem 22 auf den Client, wie es oben beschrieben wurde.
Eine Wiedergewinnungsoperation 44 wird von dem Treiber 30 ausgeführt, um auf Anforderungen für das Dateisystem 22 zu antworten. Bei einem Ausführungsbeispiel der Erfindung wird die Wiedergewinnungsoperation 44 ausgeführt, sobald die Inhalte des ersten und des zweiten Speicherort 24 und 26 gesichert worden sind, beispielsweise nachdem die erste lokale Speicheroperation 40 und die zweite lokale Speicheroperation 42 abgeschlossen sind. Sobald das gesamte oder ein Teil des Dateisystems 22 lokal gespeichert ist, ist es weniger wahrscheinlich, daß eine Wiedergewinnung aus dem Dateiserver 10 ausgeführt wird. Der Treiber 30 spricht jedoch auf Anforderungen für das Dateisystem 22 unabhängig davon an, ob irgendein Teil des Dateisystems 22 in dem ersten oder dem zweiten Speicherort 24 und 26 gespeichert ist.
Während der ersten lokalen Speicheroperation 40 bestimmt der Treiber 30 den Teil des Dateisystems 22, der in dem ersten Speicherort 24 des Clients 12 gespeichert werden soll. Bei einem Ausführungsbeispiel der Erfindung wird die erste lokale Speicheroperation 40 ausgeführt, wenn der Client 12 erstmalig mit den Netzwerk 20 verbunden wird. Der erste Speicherort 24 speichert dann einen Teil des Dateisystems 22. Da der erste Speicherort 24 nicht-flüchtig ist, bleiben die Inhalte jedesmal verfügbar, wenn der Client 12 eingeschaltet wird. So wird bei einem Ausführungsbeispiel der Erfindung die erste lokale Speicheroperation 40 nur einmal ausgeführt.
Um die erste lokale Speicheroperation 40 auszuführen, ist bei einem Ausführungsbeispiel der Erfindung der Treiber 30 vor irgendeinem Zugriff auf das Dateisystem 22 durch den Client 12 verfügbar. So wird beispielsweise der Treiber 30 vor einer Verbindung des Clients 12 mit dem Netzwerk 20 geladen. Bei einem Ausführungsbeispiel der Erfindung wird der Treiber 30 in dem Flash-Speicher 14 des Clients 12 gespeichert. Der Treiber 30 kann somit bald nach dem Einschalten des Clients und demzufolge vor irgendeiner Verbindung zu dem Netzwerk 20 durch den Client 12 ablaufen.
Alternativ könnte der Treiber 30 auf dem Festplattenlaufwerk 6 des Clients 12 (1) gespeichert sein. Bei einem Ausführungsbeispiel der Erfindung ist ein Teil des Betriebssystems 34 in dem Flash-Speicher 14 gespeichert, so daß das Betriebssystem 34 den Treiber 30 vor bestimmten Operationen, wie beispielsweise einer Verbindung zu dem Netzwerk 20, laden kann. Beispielsweise könnte das LINUX-Betriebssystem in einer solchen Konfiguration arbeiten.
Als weitere Option braucht der Treiber 30 zum Ausführen der ersten lokalen Speicheroperation 40 nicht auf dem Client 12 gespeichert zu sein. Statt dessen wird bei einem Ausführungsbeispiel der Erfindung der Treiber 30 aus einem zweiten Client heraus abgearbeitet. Wenn der Client 12 sich mit dem Netzwerk 20 verbindet, überwacht der Treiber 30 Zugriffe auf das Dateisystem 22 durch den Client 12. Andere Konfigurationen des Treibers 30 zum Ausführen der ersten lokalen Speicheroperation 40 sind ebenso möglich.
Die zweite lokale Speicheroperation 42 gewinnt oder liest (retrieves) ebenfalls einen Teil des Dateisystems 22, wobei es dieses Mal gewonnen wird, um in dem zweiten Speicherort 26 gespeichert zu werden. Bei einem Ausführungsbeispiel der Erfindung ist die zweite lokale Speicheroperation 42 eine Multicast-Operation zum Wiedergewinnen des Dateisystems 22. Darüber hinaus kann die zweite lokale Speicheroperation 42 eine Hintergrundoperation des Clients 12 sein.
Hintergrundoperationen werden ohne Interaktion oder Involvieren des Benutzers des Clients 12 ausgeführt und können auftreten, während der Benutzer andere Aufgaben ausführt. Durch Wiedergewinnung im Hintergrund können selbst große Dateisysteme wiederhergestellt werden, ohne die Verwendung des Clients 12 ernsthaft zu unterbrechen. Bei einem Ausführungsbeispiel der Erfindung wird die zweite lokale Speicheroperation 42 jedesmal dann ausgeführt, wenn der Client 12 eingeschaltet wird.
Die Wiedergewinnungsoperation 44 ist irgendeine Anforderung nach dem Dateisystem 22 durch einen Benutzer des Clients 12, durch das Betriebssystem 34 des Clients 12 oder durch eine andere Anwendungssoftware. Bei einem Ausführungsbeispiel der Erfindung liest der Treiber 30 die angeforderten Daten, indem er zunächst den ersten Speicherort 24 durchsucht. Wenn Sie nicht gefunden werden, wird der zweite Speicherort 26 nach den angeforderten Daten durchsucht. Wenn schließlich keiner der Speicherorte 24 oder 26 des Clients 12 die angeforderten Daten enthält, liest der Treiber 30 die Daten aus dem Dateiserver 10 an dem Netzwerk 20.
Der Treiber 30 kann Anforderungen des Betriebssystems 34 oder eines Anwendungsprogramms nach dem Dateisystem 22 ”abfangen”. Der Treiber 30 kann somit als Schnittstelle für Dateisystemzugriffe dienen. Auf diese Weise kann die Aufteilung des Dateisystems 22 auf möglicherweise verschiedene Speicherorte für das Betriebssystem 34 bei einem Ausführungsbeispiel der Erfindung transparent sein.
Erste lokale Speicheroperation
Gemäß 3 enthält die erste lokale Speicheroperation 40 des Treibers 30 gemäß einem Ausführungsbeispiel der Erfindung die Überwachung der Zugriffe des Dateisystems 22 durch den Client 12 während einer Zeitperiode, wie beispielsweise während des Einschaltselbsttests (POST) oder einer anderen Startoperation des Clients. Sobald Zugriffe auf das Dateisystem 22 durch den Client 12 festgestellt werden, kann dann der Treiber 30 die Teile, auf die von dem Client 12 zugegriffen wird, in dem ersten Speicherort 24 speichern.
Zunächst umfaßt die erste lokale Speicheroperation 40 das Einschalten des Clients 12 (Block 100). Eine Verbindung des Clients 12 zu dem Netzwerk 20 wird ebenfalls hergestellt. Der Treiber 30 ist bereit, den Zugriff auf das Dateisystem 22 zu überwachen. Gemäß 3 ist das Dateisystem 22, das auf einem Festplattenlaufwerk 8 des Servers 10 gespeichert ist, aus mehreren Sektoren gebildet. Dementsprechend kann bei einem Ausführungsbeispiel der Erfindung das Überwachen des Zugriffs auf das Dateisystem 22 ausgeführt werden, indem Anforderungen nach zu einem Teil des Festplattenlaufwerks 8, in dem das System 22 gespeichert ist, adressierten Sektoren überwacht werden. Alternativ kann das Dateisystem 22 aus einer Vielzahl von Bytes, einer Vielzahl von Dateien oder anderen Einheiten gebildet sein, wobei Zugriffe auf diese Einheiten von dem Treiber 30 überwacht werden.
Wenn das Dateisystem als Mehrzahl von Sektoren ausgebildet ist, wird eine Sektorverwendungstabelle von dem Treiber 30 gehalten, um zu verfolgen, auf welche Sektoren des Dateisystems 22 zugegriffen wird. Jedem Sektor des Dateisystems 22 kann ein Sektorverwendungsflag zugewiesen sein.
Demzufolge werden gemäß 3 sämtliche Sektorverwendungsflags gelöscht oder auf Null gesetzt (Block 102). Der Client 12 greift auf einen Sektor aus dem Dateisystem 22 zu (Block 104). Der Treiber 30 bestimmt, ob der Sektor zuvor durch ein Flag gekennzeichnet worden ist (Rhombus 106). Wenn dies nicht der Fall ist, wird das Sektorverwendungsflag für den gelesenen Sektor durch den Treiber 30 gesetzt (Block 110).
Wenn ein Sektor bereits durch ein Flag gekennzeichnet worden ist (Rhombus 106), wird bestimmt, ob das Einschalten abgeschlossen ist (Rhombus 108). Wenn dies nicht der Fall ist, wird ein nachfolgender Zugriff auf das Dateisystem 22 analysiert (Block 104). Wenn jedoch der Anfangsladeprozeß abgeschlossen ist, wurde eine vollständige Sektorverwendungstabelle, die Zugriffe auf das Dateisystem 22 durch den Client während des POST identifiziert, gesichert (Block 114).
Sobald die Sektorverwendungstabelle aktualisiert worden ist (Block 110), kann die Größe der Sektorverwendungstabelle mit der Kapazität des ersten Speicherorts 24 verglichen werden (Rhombus 112). Beispielsweise speichert ein typisches Festplattenlaufwerk 512 Bytes pro Sektor. So zeigt eine Sektorverwendungstabelle mit 30 Einträgen an, daß auf 30 Sektoren des Dateisystems 22 von dem Client 12 zugegriffen wurde. Somit benötigt der erste Speicherort 24 des Clients 12 zumindest 512 × 30 bzw. 15360 Bytes verfügbaren Speichers.
Kehren wir zu 3 zurück; wenn die Aufnahmefähigkeit des ersten Speicherorts 24 erreicht worden ist, kann die Sektorverwendungstabelle nicht mehr weiterwachsen. Demzufolge ist der Teil des Dateisystems 22, der dem ersten Speicherort 24 zugeteilt werden soll, festgelegt (Block 114). Wenn jedoch die Kapazität des ersten Speicherorts 24 noch nicht erreicht ist, kann der Prozeß des Überwachens der Dateisystemzugriffe durch den Client 12 wiederholt werden (Block 104).
Sobald die Sektorverwendungstabelle vollständig ist, kann der erste Speicherort 24 für den Client 12 durch den Treiber 30 programmiert werden. So liest (retrieves) der Treiber 30 aus dem Dateisystem 22 sämtliche in der Sektorverwendungstabelle identifizierten Sektoren (Block 116). Die Sektoren können dann in dem ersten Speicherort 24 des Clients 12 gespeichert werden. Bei einem Ausführungsbeispiel der Erfindung wird die Flash-Technik für den ersten Speicherort 24 verwendet, und die erste lokale Speicheroperation 40 wird einmal dann ausgeführt, wenn der Client 12 das erste Mal mit den Netzwerk 20 verbunden wird. Die erste lokale Speicheroperation 40 des Treibers 30 ist abgeschlossen (Block 120).
Der Teil des Dateisystems 22, welcher in dem ersten Speicherort 24 gespeichert wird, kann auf die Verwendung des Dateisystems 22 durch den dünnen Client (”thin client”) 12 zugeschnitten sein. Obwohl der Treiber 30 die Benutzung des Dateisystems 22 während des Einschaltens verfolgt (3), kann der Treiber auch Laufzeit- oder andere Zugriffe auf das Dateisystem 22 durch den Client 12 verfolgen, wenn es gewünscht wird.
Einige Clients 12 können mehr auf das Dateisystem 22 zugreifen als andere. Diese Clients 12 können gegebenenfalls einen größeren ersten Speicherort 24 enthalten. Die erste lokale Speicheroperation 40 schneidet somit die Schaffung des ersten Speicherorts 24 für jeden Client 12 in Abhängigkeit von dem speziellen Maß des Benötigens des Dateisystems 22 zu.
Sobald der erste Speicherort 24 erzeugt ist, stellt darüber hinaus jedes nachfolgende Einschalten des Clients 12 einen Zugriff auf das Dateisystem 22 zur Verfügung, ohne eine Netzwerkverbindung zu erfordern. Die erste lokale Speicheroperation 40 des Treibers 30 kann somit die Netzwerkbandbreite verringern, die anderenfalls zum Zugreifen auf das Dateisystem 22 aufgewendet würde.
Zweite lokale Speicheroperation
Es wird wieder auf 2 Bezug genommen; der Treiber 30 kann bei einem Ausführungsbeispiel der Erfindung außerdem die zweite lokale Speicheroperation 42 ausführen. Es sei daran erinnern, daß die zweite lokale Speicheroperation 42 einen Teil des Dateisystems 22 in den zweiten Speicherort 26 des Clients 12 sichert.
Während der zweiten lokalen Speicheroperation 42 führt der Treiber 30 eine Multicast-Wiedergewinnung (retrieval) des Dateisystems 22 in Übereinstimmung mit einem Ausführungsbeispiel der Erfindung durch. Der gelesene Teil des Dateisystems wird dann im zweiten Speicherort 26 des Clients 12 gespeichert.
Bei Dateisystemen 22, auf welche durch eine Reihe von Clients 12 zugegriffen wird, könnte ein individuelles Widergewinnen durch jeden Client 12 auf uneffektive Weise Netzwerkbandbreite verbrauchen, da jede einzelne Verbindung exakt dieselben Daten übermittelt. Eine derartige Umgebung ist somit gut zum Ausführen von Multicast-Operationen geeignet.
Multicasting ist des Prozeß des Sendens einer Nachricht gleichzeitig an mehr als ein Ziel auf einem Netzwerk. Wie auch Broadcasting kann Multicasting verwendet werden, um die Netzwerkbandbreite zu minimieren, indem eine einzige Netzwerkverbindung für mehrere Client-Empfänger eingerichtet wird. Im Unterschied zum Broadcasting jedoch kann eine Multicast-Operation auf eine Untermenge sämtlicher mit dem Netzwerk verbundener Clients anstelle der gesamten Population der Clients eingeschränkt werden.
Bei einem Ausführungsbeispiel der Erfindung kann das Dateisystem 22 über das Netzwerk 20 von dem Server 10 in Multicast ausgesendet werden. Jeder Client 12 kann dann das Dateisystem 22 gemäß der individuellen Kapazität und Bedürfnisse des Clients 12 lesen (retrieve). Der Treiber 30 jedes Clients 12 kann sich für die Multicast-Wiedergewinnung ”registrieren”.
Bei einer Multicast-Operation kann das Dateisystem 22 über das Netzwerk 20 in einzelnen Paketen gesendet werden. Die Übermittlung des Dateisystems in Paketen ist auch als Verströmen (Streaming) bekannt. Wenden wir uns 4A zu; das Dateisystem 22 ist aus einer Vielzahl von Paketen 25 gebildet. Informationen, die die vorgesehenen Empfänger-Clients 12, eine Untermenge sämtlicher möglichen Clients an dem Netzwerk 20, identifizieren, können in jedem Paket 25 enthalten sein. Bei dem in 4A gezeigten Beispiel sind nur der Client A und der Client E vorgesehene Empfänger der Pakete 25.
Ein Dateisystem von N Paketen kann paketweise von Paket 0 bis Paket (N – 1) von dem Dateiserver 12 an das Netzwerk 20 im Multicast gesendet werden. Sobald der sendende Dateiserver 10 das Multicasting des Pakets (N – 1) abschließt, kann der Server 10 in einer Schleife zum Paket 0 zurückkehren und die Übermittlung erneut beginnen.
Sobald die Multicast-Operation beginnt, können sich die Clients 12 für den Empfang der Pakete 25 ”registrieren”. Die Clients A und E können sich registrieren, um das Multicast zu empfangene die Clients B, C und D können sich registrieren, aber sie sind keine vorgesehenen Empfänger, so daß ihre Registrierung ignoriert wird.
Da die Aktion des Servers 10 asynchron zu dem Empfang durch den Client oder die Clients 12 ist, kann jeder Client bei der Registrierung ein anderes Paket 25 empfangen. In 4B sei angenommen, daß das Dateisystem 22 einundzwanzig Pakete, Paket 0 bis Paket 20, enthält. Die Multicast-Operation könnte beginnen, indem Paket 0 über das Netzwerk 20 gesendet wird. Client A registriert sich, nachdem Paket 4 gesendet worden ist. Das erste von dem Client A empfangene Paket ist folglich Paket 5. Client E registriert sich unmittelbar, bevor Paket 14 gesendet wird. Jeder Client 12 kann registriert bleiben, bis sämtliche Pakete 25 empfangen worden sind.
Bei einem Ausführungsbeispiel der Erfindung registriert sich der Treiber 30 für das Multicast-Wiedergewinnen des Dateisystems 22 und verfolgt die Pakete 25, welche von dem Client 12 empfangen worden sind. Die zweite lokale Speicheroperation 42 kann somit ”unsichtbar” für den Benutzer des Clients 12 durchgeführt werden und stört nicht andere Client-Operationen. Bei einem Ausführungsbeispiel der Erfindung wird die Multicast-Wiedergewinnung des Dateisystems 22 in den zweiten Speicherort 26 des Clients 12 gespeichert. Der zweite Speicherort 26 kann lokalen Speicherraum für einen Teil des Dateisystems 22 zur Verfügung stellen, der nicht dem ersten Speicherort 24 zugeteilt ist. Ein Teil des Systemspeichers 16 des Clients 12 kann als zweiter Speicherort 26 verwendet werden. Wie bei dem ersten Speicherort 24 kann die Größe des zweiten Speicherorts 26 in Abhängigkeit von den Charakteristika des Clients 12 variieren.
Für einen Client 12 mit ausreichenden Ressourcen zum lokalen Wiedergewinnen des vollständigen Dateisystems 22 können sämtliche Zugriffe des Dateisystems 22 gespeichert und dann aus dem Client 12 bedient werden. Während der zweiten lokalen Speicheroperation 42 jedoch kann es sein, daß das Betriebssystem 34 einen Zugriff auf das Dateisystem 22 anfordert, welches noch nicht auf dem Client 12 gespeichert ist. Darüber hinaus kann der Client 12 in seiner Speicherkapazität begrenzt sein, so daß es sein kann, daß nicht das gesamte Dateisystem 22 lokal gespeichert werden kann. In beiden Fällen kann der Treiber 30 auf das Dateisystem 22 aus dem Server 10 über das Netzwerk 20 zugreifen.
Im Gegensatz zu der ersten lokalen Speicheroperation 40, welche ausgeführt werden kann, wenn der Client 12 das erste Mal mit dem Netzwerk 20 verbunden wird, kann die zweite lokale Speicheroperation 42 jedesmal dann ausgeführt wird, wenn der Client 12 eingeschaltet wird. Es sei daran erinnert, daß bei einem Ausführungsbeispiel der Erfindung der zweite Speicherort 26 ein flüchtiges Speichermedium ist. Somit gehen die Inhalte des zweiten Speicherorts 26 verloren, sobald die Spannungsversorgung für den Client 12 weggenommen wird.
Alternativ könnte der zweite Speicherort 26 ein nichtflüchtiges Medium sein. Demzufolge kann die zweite lokale Speicheroperation 42 ausschließlich während spezifizierte Zeiten ausgeführt werden. Beispielsweise kann die zweite lokale Speicheroperation 42 periodisch ausgeführt werden, wie beispielsweise bei jedem zehnten Hochfahren (Boot) des Client 12, zu Beginn jedes Monats, bei Empfang einer Benachrichtigung, daß das Dateisystem 22 aktualisiert worden ist, oder wie es von dem Benutzer des Clients 12 spezifiziert ist.
Wiedergewinnungsoperation
Es sei wieder auf 2 Bezug genommen. Bei einem Ausführungsbeispiel der Erfindung kann der Treiber 30 außerdem die Wiedergewinnungsoperation 44 (retrieval operation) ausführen. Während der Wiedergewinnungsoperation 44 antwortet der Treiber 30 auf Anforderungen nach einem Teil des Dateisystems 22.
Wenden wir uns 5 zu. Die Anforderung kann von dem Benutzer des Clients 12, dem Betriebssystem 34 des Client 12 oder aus einem Anwendungsprogramm empfangen werden (Block 158). Der Treiber 30 bestimmt, ob der angeforderte Teil des Dateisystems 22 in dem ersten Speicherort 24 oder dem zweiten Speicherort 26 angeordnet ist.
Wenn der angeforderte Teil des Dateisystems 22 auf dem Client verfügbar ist, sind Netzwerkzugriffe nicht erforderlich. Wenn jedoch der Teil nicht auf dem Client 12 gefunden wird, kann der Treiber 30 noch die angeforderten Daten aus dem Netzwerkserver 10 wiedergewinnen. Demzufolge führt der Treiber 30 gemäß 5 eine Reihe von Anfragen aus.
Der erste Speicherort 24 wird hinsichtlich des Vorhandenseins der angeforderten Daten getestet (Rhombus 160). Sofern sie gefunden werden, können die Daten aus dem ersten Speicherort 24 gelesen werden (Block 162). Anderenfalls wird eine Feststellung darüber getroffen, ob die angeforderten Daten in dem zweiten Speicherort 26 angeordnet sind (Rhombus 164). Wenn dies der Fall ist, liest der Treiber 30 die Daten aus dem zweiten Speicherort 26 (Block 166). Aus beiden Blöcken 162 oder 166 wird die Wiedergewinnung der angeforderten Daten abgeschlossen und ein Zugriff auf das Netzwerk 20 ist nicht erforderlich.
Wenn die Daten weder in dem ersten Speicherort 24 noch in dem zweiten Speicherort 26 vorhanden sind, kann der Treiber 30 als nächstes bestimmen, ob die Daten gelesen (wiedergewonnen) worden sind, aber noch nicht in den zweiten Speicherort 26 gebracht wurden (beispielsweise können die Daten in einem anderen Abschnitt des Speichers sein) (Rhombus 168). Wenn dies der Fall ist, können die Daten in den zweiten Speicherort 26 gebracht werden (Block 170). Die Daten können dann aus dem zweiten Speicherort 26 gelesen werden (Block 166). Wenn statt dessen die Daten nicht gelesen worden sind, kann der Treiber 30 die Daten fern, d. h. über das Netzwerk 20 aus dem Dateiserver 10, wiedergewinnen (Block 172).
Beim Wiedergewinnen der Daten aus dem Server 10 kann der Treiber 30 darauf warten, daß die Multicast-Operation abgeschlossen wird. Während der zweiten lokalen Speicheroperation 42 gewinnt der Treiber 30 den Inhalt des Dateisystems 22 zu dem zweiten Speicherort 26 wieder. Alternativ kann der Treiber 30 eine einzelne Wiedergewinnung der angeforderten Daten aus dem Dateisystem 22 ausführen.
Diese zweite Alternative kann beispielsweise dann wünschenswert sein, wenn die angeforderten Daten sich in der Nähe des Endes der Multicast-Wiedergewinnung befinden, die gegenwärtig stattfindet. Gemäß 4B beispielsweise kann dann, wenn der Client A das Paket 4 benötigt, aber sich für das Multicast beim Paket 5 registriert, der Treiber für den Client entscheiden, auf das Paket 4 aus dem Server 10 zuzugreifen, statt auf die Erzeugung des Pakets 4 aus der Multicast-Operation zu warten.
Entweder im Ergebnis der Multicast-Wiedergewinnung oder des Zugreifens auf den Dateiserver 10 bringt der Blocktreiber 30 die Daten in den zweiten Speicherort 26. Sobald sie wiedergewonnen worden sind, können die Daten aus dem zweiten Speicherort 26 gelesen werden (Block 166).
So kann ein verteiltes Dateisystem mit einer Multicast-Wiedergewinnung durch einen oder mehrere Clients an einem Netzwerk insbesondere für Clients mit begrenzter Speicherfähigkeit, die auf große Dateisysteme zugreifen müssen, geeignet sein. Während das verteilte Dateisystem effizient das große Dateisystem zwischen dem Server und den Clients in Relation zu den Charakteristika jedes Clients verteilt, kann der Verkehr auf dem Netzwerk entlastet werden und die Geschwindigkeit der Wiedergewinnung für den Client kann sich erhöhen. Während die Multicast-Technologie für das Übermitteln des gesamten Dateisystems an mehrere Clients unterstützt wird, kann die Bandbreitenausnutzung zwischen den Clients und dem Netzwerkserver reduziert werden. Wenn die Multicast-Operation in einem Hintergrundmodus ausgeführt wird, wird die Unterbrechung anderer Aufgaben durch den Client verringert. Ein Zugriff auf den fernen Server durch den Client bleibt möglich, wenn die Multicast-Wiedergewinnung ineffizient ist oder wenn dies aus anderen Gründen gewünscht wird.
Während die vorliegende Erfindung unter Bezugnahme auf eine begrenzte Anzahl von Ausführungsbeispielen beschrieben worden ist, werden Fachleuten zahlreiche Modifikationen und Variationen klar. Die beigefügten Ansprüche sollen sämtliche derartigen Modifikationen und Variationen, soweit sie in den wahren Geist und Umfang dieser vorliegenden Erfindung fallen, abdecken.

Claims

Ein Verfahren zum Verarbeiten von Client-Anforderungen in einem Server-Client-Netzwerk, umfassend: Empfangen einer Anforderung eines Clients nach einem Teil eines Dateisystems; Feststellen, ob der angeforderte Teil des Dateisystems in einem ersten Speicher des Clients gespeichert ist, der Teilen des Dateisystems zugeordnet ist und in dem zuvor von dem Client bereits verwendete Teile des Dateisystems gespeichert worden sind; und wenn dies nicht der Fall ist, Feststellen, ob der angeforderte Teil des Dateisystems in einem zweiten Speicher des Clients gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die von einem Server an den Client gestreamt wurden und in dem zweiten Speicher gespeichert wurden.
Das Verfahren nach Anspruch 1, ferner umfassend das Abrufen des Teils des Dateisystems von dem Server, wenn der Teil nicht in dem zweiten Speicherort gespeichert ist.
Das Verfahren nach Anspruch 1, wobei das Feststellen ferner das Zuordnen von solchen Teilen des Dateisystems zu dem ersten Speicherort umfaßt, die von dem Client während des Starts verwendet werden.
Das Verfahren nach Anspruch 1, wobei das Feststellen ferner das Zuordnen des zweiten Speicherorts zu solchen Teilen des Dateisystems umfaßt, die an den Client unter Verwendung einer Multicast-Operation gestreamt wurden.
Das Verfahren nach Anspruch 3, wobei das Zuordnen ferner umfaßt: Überwachen von Zugriffen auf eine Mehrzahl von Teilen des Dateisystems während des Starts; Abrufen der Mehrzahl der Teile aus dem Dateisystem; und Speichern der Mehrzahl der Teile in dem ersten Ort.
Das Verfahren nach Anspruch 4, wobei das Zuordnen ferner umfaßt: Abrufen einer Mehrzahl von Teilen aus dem Dateisystem unter Verwendung von Multicasting; und Speichern der Mehrzahl der Teile in dem zweiten Speicherort.
Das Verfahren nach Anspruch 1, ferner umfassend das Warten auf den an den Client zu streamenden Teil, wenn er nicht in dem zweiten Ort gespeichert ist.
Ein System, enthaltend: einen Prozessor; ein Speichermedium mit einem Software-Programm, das bei seiner Ausführung: einen ersten Speicherort des Systems durchsucht, der Teilen eines Dateisystems zugeordnet ist, die zuvor von dem System verwendet und gespeichert worden sind; und einen zweiten Speicherort des Systems durchsucht, der Teilen des Dateisystems zugeordnet ist, die von einem Server an das System gestreamt worden sind.
Das System nach Anspruch 8, wobei der erste Speicherort ein nicht-flüchtiges Speichermedium ist.
Das System nach Anspruch 9, wobei das nicht-flüchtige Speichermedium ein Flash-Speicherbauelement ist.
Das System nach Anspruch 8, wobei der zweite Ort ein flüchtiges Speichermedium ist.
Das System nach Anspruch 11, wobei das flüchtige Speichermedium ein Speicherbauelement ist.
Das System nach Anspruch 9, wobei der erste Speicherort Teile des Dateisystems enthält, die von dem Client beim Starten verwendet werden.
Das System nach Anspruch 9, wobei der zweite Speicherort Teile des Dateisystems enthält, die unter Verwendung einer Multicast-Operation abgerufen werden.
Das System nach Anspruch 9, wobei das Software-Programm bei seiner Ausführung den Teil aus dem Server abruft, sofern er nicht in dem zweiten Ort gespeichert ist.
Das System nach Anspruch 14, wobei die Inhalte des zweiten Orts als Hintergrundoperation beschafft werden.
Ein Gegenstand, der ein Medium aufweist, das Befehle speichert, die ein prozessor-basiertes System veranlassen: eine Anforderung des prozessor-basierten Systems nach einem Teil eines Dateisystems zu empfangen; festzustellen, ob der Teil des Dateisystems in einem ersten Speicherort gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die zuvor von dem prozessorbasierten System verwendet und gespeichert worden sind; und wenn dies nicht der Fall ist, zu bestimmen, ob der Teil des Dateisystems in einem zweiten Speicherort gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die an das prozessor-basierte System gestreamt wurden.
Der Gegenstand nach Anspruch 17, wobei das Befehle speichernde Medium ein Flash-Speicherbauelement ist.
Der Gegenstand nach Anspruch 17, ferner Befehle speichernd, die das prozessor-basierte System veranlassen, den Teil des Dateisystems aus einem Server abzurufen, wenn er nicht in dem zweiten Speicherort gespeichert ist.
Der Gegenstand nach Anspruch 17, ferner Befehle speichernd, die das prozessor-basierte System veranlassen, zu bestimmen, ob der Teil des Dateisystems in einem zweiten Speicherort gespeichert ist, der Teilen des Dateisystems zugeordnet ist, die an das prozessor-basierte System von einem Server unter Verwendung einer Multicast-Operation gestreamt wurden.