DE69333906T2

DE69333906T2 - Verfahren und System für die Dateienverwaltung mit einem schnell löschbaren, programmierbaren ROM

Info

Publication number: DE69333906T2
Application number: DE69333906T
Authority: DE
Inventors: William J. Redmond Krueger; Sriram Bellevue Rajagopalan
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 1992-01-29
Filing date: 1993-01-29
Publication date: 2006-05-24
Anticipated expiration: 2013-01-30
Also published as: US6256642B1; EP0557736A2; US5898868A; CA2325812C; CA2325812A1; JPH07191892A; CA2088442A1; JP4365385B2; JP4608588B2; JP2010049713A; JP2006209807A; CA2325810A1; CA2325810C; JP4858789B2; DE69333906D1; JP2008282429A; JP4608589B2; JP4485586B2; JP3825479B2; JP4836217B2

Description

Technisches Gebiet
Die Erfindung betrifft allgemein ein Verfahren und ein computerlesbares Medium zur Verwaltung von Dateien. Die Erfindung betrifft insbesondere die Verwaltung von Dateien, die in einem flash-artig löschbaren, programmierbaren Festwertspeicher (flash-erasable, programmable read-only memory FEProm) gespeichert sind.
Hintergrund der Erfindung
Computersysteme dienen im Allgemeinen der Speicherung von Informationen in flüchtigen und nichtflüchtigen Speichervorrichtungen. Der Unterschied zwischen flüchtigen und nichtflüchtigen Speichervorrichtungen besteht darin, dass bei der Trennung einer flüchtigen Speichervorrichtung von der Stromversorgung die Informationen verloren gehen. Wird demgegenüber eine nichtflüchtige Speichervorrichtung von der Stromversorgung getrennt, so gehen die Informationen nicht verloren. Dies bedeutet, dass ein Anwender durch die Speicherung von Informationen in einer nichtflüchtigen Speichervorrichtung in die Lage versetzt wird, die Informationen zu einem bestimmten Zeitpunkt einzugeben und diese Informationen zu einem späteren Zeitpunkt wiederabzurufen, auch wenn das Computersystem zwischenzeitlich abgeschaltet war. Der Anwender kann darüber hinaus die nichtflüchtige Speichereinrichtung vom Computer trennen und mit einem anderen Computer verbinden, sodass der andere Computer Zugriff auf die Informationen hat.
Die in nichtflüchtigen Speichervorrichtungen gespeicherten Informationen sind allgemein in Dateien organisiert. Eine Datei ist eine Sammlung aufeinander bezogener Informationen. Im Laufe der Zeit kann ein Computersystem – abhängig vom Speichervermögen der Vorrichtung – Hunderte oder Tausende von Dateien in der Speichervorrichtung speichern. Über das Speichern von Informationen hinausgehend nimmt das Computersystem typischerweise auch das Lesen, Ändern und Löschen der Informationen in den Dateien vor. Hierbei ist wichtig, dass das Computersystem die Dateien in der Speichervorrichtung derart organisiert, dass das Speichern, Lesen, Ändern und Löschen effizient vorgenommen werden kann.
Dateisysteme, die im Allgemeinen Teil eines Computerbetriebssystems sind, wurden entwickelt, um die Verwaltung von Dateien in Speichervorrichtungen zu unterstützen. Ein solches Dateisystem wurde von der Microsoft Corporation für sein Plattenbetriebssystem (disc operating system) MS-DOS entwickelt. Dieses Dateisystem bedient sich eines hierarchischen Ansatzes bei der Speicherung von Dateien. 1A ist eine bildliche Darstellung der Verzeichnisstruktur einer Speichervorrichtung. Die Verzeichnisse enthalten logische Gruppen von Dateien. Die Verzeichnisse organisieren Dateien auf eine Art, die derjenigen Art ähnlich ist, auf die Akten in einer Schublade die Papiere in der Schublade organisieren. Die mit DOS, WORD, DAVID und MARY bezeichneten Blöcke stellen Verzeichnisse dar, wohingegen die Blöcke, die mit AUTOEXEC.BAT, COMMAND.COM, FORMAT.EXE, LETTER2.DOC und LETTER.DOC bezeichnet sind, sowie die beiden Dateien, die mit LETTER1.DOC bezeichnet sind, Dateien darstellen. Die Verzeichnisstruktur versetzt den Anwender in die Lage, Dateien durch Verbringung aufeinander bezogener Dateien in eigene Verzeichnisse zu organisieren. In diesem Beispiel kann das Verzeichnis WORD sämtliche Dateien enthalten, die mittels des Textverarbeitungsprogramms WORD erzeugt worden sind. Innerhalb des Verzeichnisses WORD sind zwei Unterverzeichnisse DAVID und MARY vorhanden, die eine tiefergehende Organisierung der WORD-Dateien in diejenigen, die von DAVID erstellt worden sind, und diejenigen, die von MARY erstellt worden sind, ermöglichen.
Herkömmliche Dateisysteme bedienen sich vorteilhafterweise der Eigenschaft der Mehrfachbeschreibbarkeit nichtflüchtiger Speichervorrichtungen. Die Eigenschaft der Mehrfachbeschreibbarkeit impliziert, dass jedes Informationsbit in der Speichervorrichtung nahezu unbeschränkt oft von 1 nach 0 und von 0 nach 1 geändert werden kann. Durch diese Eigenschaft wird es möglich, dass eine Datei in die Speichervorrichtung geschrieben und anschließend selektiv geändert wird, indem einige Bits der Datei geändert werden.
Der Nachteil herkömmlicher Speichervorrichtungen mit der Eigenschaft der Mehrfachbeschreibbarkeit, so beispielsweise von Disketten, ist ihre Geschwindigkeit, die im Vergleich zur Geschwindigkeit des internen Computerspeichers niedriger ist. Demgegenüber liegt der Vorteil derartiger Speichervorrichtungen im Vergleich zu einem Computerspeicher in ihrer Nichtflüchtigkeit, ihren geringeren Kosten und ihrem hohen Speichervermögen.
Unter der Bezeichnung Flash-EProm (FEProm) bekannte Speichervorrichtungen kombinieren die Geschwindigkeit eines internen Computerspeichers mit der Nichtflüchtigkeit einer Computerplatte. Diese Vorrichtung ist eine Vorrichtung vom EProm-Typ (löschbarer, programmierbarer Festwertspeicher). Die Inhalte des FEProm können gelöscht werden, indem eine bestimmte Spannung an einem Eingang angelegt wird, anstatt dass die Vorrichtung, wie dies bei einem typischen EProm der Fall ist, mit ultraviolettem Licht bestrahlt wird. Das Löschen setzt jedes Bit in der Vorrichtung auf den gleichen Wert. Entsprechend anderen EProm-Vorrichtungen ist auch der FEProm ein nichtflüchtiger Speicher. FEProm-Vorrichtungen sind mit Blick auf ihre Geschwindigkeit dem internen Speicher eines Computers ebenbürtig. Am Anfang und nach einem Löschen wird jedes Bit des FEProm auf 1 gesetzt. Eine charakteristische Eigenschaft des FEProm besteht wie bei anderen EProm-Vorrichtungen darin, dass ein Bitwert von 1 in 0 geändert werden kann, wohingegen ein Bitwert nicht von 0 in 1 geändert werden kann. Daher können Daten nur dann in den FEProm geschrieben werden, wenn damit eine Änderung eines Bits von 1 auf 0 einhergeht. Sobald ein Bit in 0 geändert worden ist, kann es nicht wieder in 1 geändert werden, es sei denn, der gesamte FEProm wird durchgehend in 1 gelöscht. Effektiv kann jedes Bit des FEProm zwischen aufeinanderfolgenden Löschungen nur einmal geschrieben, jedoch viele Male gelesen werden. Zudem kann jedes Bit eines FEProm nur eine beschränkte Anzahl von Malen gelöscht und auf 0 gesetzt werden. Die beschränkte Anzahl von Malen bestimmt die effektive Lebensdauer des FEProm.
Die typische Zugriffszeit eines FEProm hängt von der Art des Zugriffs sowie von einigen anderen Faktoren ab. Die Lesezugriffszeit liegt in einem Bereich von Hunderten von Nanosekunden, wobei keine Beschränkungen dahingehend bestehen, wie oft ein Byte gelesen werden kann. Die Schreibzugriffszeit liegt typischerweise in einem Bereich von einigen Dutzend Mikrosekunden. Die Schreibzugriffszeit hängt davon ab, wie oft das Byte gelöscht worden ist, sowie von der Temperatur der Vorrichtung und der Bytedichte des FEProm. Obwohl theoretisch keine Grenze dahingehend besteht, wie oft ein Byte geschrieben werden kann, stellt die Löschgrenze eine praktische Schreibgrenze dar. Die Löschzeit eines FEProm liegt im Bereich von einigen Sekunden. Die Löschzeit hängt davon ab, wie oft bereits eine Löschung in dem FEProm vorgenommen wurde, sowie von der Temperatur der Vorrichtung und der Bytedichte des FEProm.
Da bei herkömmlichen Dateisystemen davon auszugehen ist, dass die Speichervorrichtung die Eigenschaft der Mehrfachbeschreibbarkeit aufweist, eignen sich diese Dateisysteme nicht für einen FEProm, der effektiv nur die Eigenschaft der Einmalbeschreibbar keit aufweist. Es wäre daher wünschenswert, ein Dateisystem bereitzustellen, das eine auf einem FEProm basierende Speichervorrichtung unterstützt. Ein derartiges Dateisystem würde die Geschwindigkeit des Computerspeichers mit der Nichtflüchtigkeit von Computerplatten verbinden.
Herkömmliche Speichervorrichtungen, so beispielsweise Computerplatten, sind nicht byteweise, sondern blockweise adressierbar. Ein Byte ist die Einheit der Adressierbarkeit des internen Computerspeichers, das heißt, der Computer kann ein Byte (üblicherweise 8 Bit), jedoch nicht weniger, gleichzeitig schreiben oder lesen. Schreibt ein Computer auf eine Platte oder liest er von dieser, so muss dies in Gruppen von Bytes erfolgen, die Blöcke genannt werden. Die Größe der Blöcke kann variieren, entspricht jedoch üblicherweise einer Zweierpotenz (128, 256, 512 etc.). Soll beispielsweise nur ein Byte auf einer Platte geändert werden, so muss die gesamte Anzahl von Bytes in der Blockgröße geschrieben werden. Dies kann dazu führen, dass der gesamte Block von der Diskette in den Computerspeicher gelesen werden muss, und das eine Byte (der interne Speicher ist byteweise adressierbar) geändert wird, woraufhin der gesamte Block zurück auf die Diskette geschrieben wird.
Herkömmliche Dateisysteme speichern Daten derart, dass nicht genutzte Blockbereiche übrigbleiben. Die Dateisysteme speichern Daten zu einem bestimmten Zeitpunkt aus nur einer Datei in einem beliebigen Block. Die Dateisysteme speichern beispielsweise keine Daten aus einer Datei in den ersten 50 Byte eines Blocks und Daten aus einer anderen Datei in den letzten 78 Byte eines 128 Byte aufweisenden Blocks. Ist jedoch die Länge einer Datei kein geradzahliges Vielfaches der Blockgröße, so bleibt Speicherplatz am Ende eines Blockes unbenutzt. Im obigen Beispiel bleiben die letzten 78 Byte eines Blocks unbenutzt. Weist eine Diskette eine hohe Blockgröße, so beispielsweise 4096, auf, so kann vorkommen, dass bis zu 4095 Datenbyte unbenutzt bleiben. Obwohl dieser nicht genutzte Platz eine vernachlässigbare Größe auf einem Plattenlaufwerk sein kann, das die Eigenschaft der Mehrfachbeschreibbarkeit aufweist, und das Millionen von Bytes speichern kann, kann er bei einer Speichervorrichtung ohne die Eigenschaft der Mehrfachbeschreibbarkeit und ohne die Fähigkeit, Millionen von Datenbytes zu speichern, durchaus ins Gewicht fallen.
Der FEProm ist im Gegensatz zu typischen Speichervorrichtungen byteweise und nicht blockweise adressierbar. Es wäre daher wünschenswert, über ein Dateisystem zu verfügen, das die byteweise erfolgende Adressierbarkeit eines FEProm unterstützt.
Ein FEProm kann darüber hinaus in einem blockweise löschbaren Format organisiert sein. Ein blockweise löschbarer FEProm enthält eine Anzahl von Blocks, typischerweise 16, die unabhängig voneinander gelöscht werden können. Jeder einzelne Block kann unabhängig gelöscht werden, ohne dass die Inhalte der anderen Blocks betroffen wären. Es wäre daher wünschenswert, über ein Dateisystem zu verfügen, das einen blockweise löschbaren FEProm unterstützt.
Die Druckschrift EP-A-0 439 920 beschreibt ein System und ein Verfahren zur Speicherverwaltung in einem Mikrocomputer. Es wird offenbart, dass Datenfelder Datenblöcke umfassen. Darüber hinaus wird offenbart, dass ein Datenblock in einen nichtflüchtigen CMOS-Speicher geschrieben werden kann.
Die Druckschrift EP-A-0 261 461 offenbart ein paralleles freies Speicherverwaltungsverfahren sowie eine zugehörige Vorrichtung. Sämtlicher zur Verwendung zur Verfügung stehende Speicherplatz in dem Speicher ist mit einem zugehörigen Zuordnet verknüpft.
In dem Beitrag „Designing a Write-Once File System" von S. Garfinkel, veröffentlicht in Dr. Dobb's Journal, Band 16, 1991, Seiten 78 bis 86, wird ein einmal beschreibbares Dateisystem mit Blöcken zur Speicherung von Verzeichnissen beschrieben. Die eingesetzten Speichermedien sind optische Speicherplatten. Sobald ein Block geschrieben worden ist, kann er nicht mehr geändert werden.
Der Beitrag „The Optical File Cabinet", von J. Gait, veröffentlicht in COMPUTER, Band 21, Nr. 6, 1988, Seiten 11 bis 22, beschreibt ebenfalls ein Dateisystem für einmal beschreibbare optische Speicherplatten. Das Dateisystem arbeitet auf einer Block-für-Block-Basis. Hieraus ergibt sich, dass einzelne Blocks, sobald sie geschrieben worden sind, nicht mehr aktualisiert werden können.
In dem Beitrag „Intel flash EPROM for in-system reprogrammable nonvolatile storage" von S. Zales et al., veröffentlicht in MICROPROCESSORS AND MICROSYSTEMS, Band 14, Nr. 8, 1990, Seiten 543 bis 549, wird ein flash-artiger EPROM zur systemeigenen neuprogrammierbaren nichtflüchtigen Speicherung offenbart. Es werden die Flash-EPROM-Technologie und deren Verwendung in einem Mikrocomputer beschrieben.
Die Aufgabe der vorliegenden Erfindung besteht in der Bereitstellung eines Verfahrens und eines computerlesbaren Mediums zur Speicherverwaltung bei der Speicherung ei nes Dateisystems, das mit einer höheren Geschwindigkeit betrieben werden kann, als dies bei auf einer Computerspeicherplatte gespeicherten Dateisystemen der Fall ist.
Die Aufgabe wird durch die Gegenstände der unabhängigen Ansprüche gelöst.
Bevorzugte Ausführungsbeispiele werden in den abhängigen Ansprüchen beschrieben.
Die Erfindung findet vorzugsweise bei flash-artig löschbaren Speichern Verwendung.
Darüber hinaus ist die Erfindung bei der Zuordnung und Freigabe von Speicher in einem blockweise löschbaren FEProm von Nutzen.
Die vorliegende Erfindung kann verwendet werden, wenn verfolgt werden soll, wie oft ein Block in einem blockweise löschbaren FEProm gelöscht worden ist.
Vorzugsweise speichert der blockweise löschbare Speicher eine Datenstruktur, die die Speicherzuordnung vereinfacht.
Die Erfindung ist darüber hinaus dadurch von Vorteil, dass sie bei der Rückgewinnung freigegebenen Platzes in einem blockweise löschbaren FEProm verwendet werden kann.
Diese und andere Aufgaben, die sich aus der nachfolgenden detaillierten Beschreibung der Erfindung ergeben, werden von einem Verfahren und einem System zur Speicherverwaltung in einem blockweise löschbaren, flash-artig löschbaren und programmierbaren Festwertspeicher gelöst. Bei einem bevorzugten Ausführungsbeispiel umfasst das System einen blockweise löschbaren FEProm mit einem Blockheader, einer Blockzuordnungstabelle, einem Datenspeicherbereich, einer Blockzuordnungsroutine zum Auswählen eines Blockes, in dem die Daten gespeichert werden sollen, einer Datenbereichzuordnungsroutine zum Auswählen eines Eintrages in die Blockzuordnungstabelle und einen Abschnitt des Datenspeicherbereiches und einer Speicherroutine zur Speicherung der Daten. Bei den bevorzugten Ausführungsbeispielen enthält das System einen Dateimanager, um ein Dateisystem für den blockweise löschbaren FEProm zu implementieren.
Kurzbeschreibung der Zeichnung
1A zeigt ein Beispiel für eine hierarchische beziehungsweise baumartig strukturierte Organisation von Verzeichnissen und Dateien.
1B zeigt eine Verbundlistenstruktur, die die Verzeichnisstruktur von 1A darstellt.
1C zeigt eine alternative Verbundlistenstruktur, die die Verzeichnisstruktur von 1A darstellt.
2A zeigt eine Verbundlistenstruktur für eine Datei mit dem Namen „\A\D.DAT".
2B zeigt eine alternative Verbundlistenstruktur für die Datei mit dem Namen „\A\D.DAT".
4 zeigt ein Flussdiagramm der Add_Directory-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
5 und 6 sind eine Vorher- beziehungsweise eine Nachherdarstellung der Verzeichnisstruktur mit einem neu hinzugefügten Verzeichnis bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
7 zeigt ein Flussdiagramm der Add_File-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
8 zeigt ein Flussdiagramm der Extend_File-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
9 zeigt ein Beispielsverzeichnis sowie den Aufbau einer Datei unter Verwendung eines bevorzugten Ausführungsbeispieles der vorliegenden Erfindung.
10 zeigt ein Flussdiagramm der Update_File-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
11 und 12 zeigen einen Beispielsabschnitt einer Datei bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung vor der Aktualisierung beziehungsweise nach dieser.
13, 14 und 15 zeigen Beispielsabschnitte einer Datei bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung nach der Aktualisierung der Datei.
16 zeigt ein Flussdiagramm der Del_Directory-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
17 zeigt ein Flussdiagramm der Change_File_Name-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
18 ist eine Vorher- und Nachherdarstellung der Verzeichnisstruktur für eine Datei, deren Namen geändert wurde.
19 zeigt ein Flussdiagramm der Change_Attribute_Data-Routine bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung.
20 zeigt den Aufbau eines Blocks bei einem bevorzugten Ausführungsbeispiel.
20A zeigt den Aufbau des Blocks von 23 nach der Rückgewinnung bei einem bevorzugten Ausführungsbeispiel.
21 zeigt Beispiele für Blockzuordnungsstrukturen und -regionen für das Beispiel von 26.
22 zeigt das Dereferenzieren eines Handles.
23 zeigt eine Beispielsblockzuordnung für einen Abschnitt der Verzeichnishierarchie von 1B.
24 zeigt ein Flussdiagramm des Initialisierungsvorganges bei einem bevorzugten Ausführungsbeispiel.
25 zeigt ein Flussdiagramm der Blockzuordnungsroutine bei einem bevorzugten Ausführungsbeispiel.
26 zeigt ein Flussdiagramm der Regionszuordnungsroutine bei einem bevorzugten Ausführungsbeispiel.
27 zeigt ein Flussdiagramm der Blockrückgewinnungsroutine bei einem bevorzugten Ausführungsbeispiel.
28 zeigt ein Statusdiagramm der Zustände (states) der Alloc-Einträge.
29 ist ein Statusdiagramm der Zustände (states) der Blöcke.
Detailbeschreibung der Erfindung
Bei einem bevorzugten Ausführungsbeispiel stellt die vorliegende Erfindung ein Verfahren und ein System zur Speicherverwaltung eines blockweise löschbaren FEProm bereit. Das System wird als FEProm-Verwalter (FEProm manager) nebst Dateisystem beschrieben. Der FEProm-Verwalter verwaltet die Speicherzuordnung und die Freigabe des FEProm. Das Dateisystem ist ein hierarchisches Verzeichnissystem und bedient sich des FEProm-Verwalters für die Zuordnung und Freigabe von Speicher. Alternativ können der FEProm-Verwalter und das Dateisystem integriert sein, um bestimmte Optimierungen zu erreichen. Gleichwohl ermöglicht die Verwendung eines separaten FEProm-Verwalters, dass der FEProm Dateien aus verschiedenen Dateisystemen und sogar Nichtdateisystemdateien speichert.
FEProm-Verwalter
Der FEProm-Verwalter der vorliegenden Erfindung ermöglicht die Zuordnung freien Platzes, die Freigabe zugeordneten Platzes und die Rückgewinnung freigegebenen Platzes in einem blockweise löschbaren FEProm. Bei bevorzugten Ausführungsbeispielen enthält, wie in 20 gezeigt ist, jeder Block des FEProm eine Blockzuordnungsstruktur 2302, Datenregionen 2303 sowie freien Platz 2304. Die Blockzuordnungsstruktur 2302 enthält einen Header und ein Zuordnungsfeld (allocation array). Der Header ist eine eine feste Länge aufweisende Struktur, die Statusinformationen für den Block enthält. Das Zuordnungsfeld weist veränderliche Länge auf. Die Einträge des Zuordnungsfeldes be schreiben die Datenregionen. Tabelle A zeigt die Datenstruktur der Blockzuordnungsstruktur. Die Struktur ist zusammen mit einer Beschreibung der Strukturvariablen im Format der Programmiersprache C dargestellt. Das Alloc-Feld ist das Zuordnungsfeld, während die anderen Variablen den Header bilden. Die Datenregionen sind veränderliche Länge aufweisende Regionen, die die Daten in dem FEProm gespeichert halten. Der freie Platz 2304 ist derjenige Platz, der der Blockzuordnungsstruktur oder den Datenregionen nicht zugeordnet ist. Die Blockzuordnungsstruktur 2302 und die Datenregionen 2303 sind an entgegengesetzten Enden des Blockes angeordnet. Werden Regionen hinzugefügt, so „wachsen" die Blockzuordnungsstruktur 2302 und die Datenregion, wie durch Pfeile 2305 und 2306 angedeutet, aufeinander zu. Die Alloc-Einträge in der Blockzuordnungsstruktur enthalten Versätze beziehungsweise Versetzungen (offsets) 2310 bis 2315 gegenüber der entsprechenden Region in dem Block. Bei einem bevorzugten Ausführungsbeispiel enthält die Blockzuordnungsstruktur Daten, die für die in den Regionen gespeicherten Daten spezifisch sind.
Tabelle A: Datenstrukturen
Definitionen
Der FEProm-Verwalter verwaltet eine Datenregion in einem Block, indem er einen Alloc-Eintrag hinzufügt, die Variable Offset derart setzt, dass sie auf die erste Stelle des freien Platzes zeigt, die Variable Len auf die Länge der Region setzt und die Variable Status auf „zugeordnet" setzt. Der FEProm-Verwalter gibt eine Region frei, indem er die Variable Status in dem entsprechenden Alloc-Eintrag auf „freigegeben" setzt. Der freigegebene Platz steht im Allgemeinen nicht für eine Neuzuordnung zur Verfügung, da er auf einen non-FNULL-Wert gesetzt worden sein kann. Der freigegebene Platz wird auf FNULLs gesetzt, bevor eine Neuzuordnung erfolgt. Der Vorgang des Setzens des freigegebenen Platzes auf FNULLs und die Verfügbarmachung für eine Zuordnung stellt die Blockrückgewinnung dar. Der freigegebene Platz wird zurückgewonnen, indem die zugeordneten Regionen einem zweiten Block zugeordnet werden, und die Alloc-Einträge in dem zweiten Block derart gesetzt werden, dass sie auf die neuen Versätze verweisen. Der Vorgang der Blockrückgewinnung stellt sicher, dass die Alloc-Einträge in dem zweiten Block relativ zu dem Blockheader in derselben Position befindlich sind, in der sie in demjenigen Block waren, aus dem heraus kopiert wurde. Der FEProm-Verwalter bedient sich einer logischen Blocksequenznummer, der Variable BlockSeq in dem Header, um einen spezifischen logischen Block von Daten zu identifizieren. Wird ein Block während der Rückgewinnung kopiert, so ändert sich die physische Blocknummer, wohingegen sich die logische Blocksequenznummer nicht ändert.
Der FEProm-Verwalter stellt nicht die Adressen der Anfangsregion, sondern einen Handle für die zugeordnete Region bereit. Der Handle enthält zwei Teile, nämlich (1) eine logische Blocksequenznummer, die einen physischen Block indirekt referenziert, und (2) einen Index auf einen Alloc-Eintrag, der eine Region innerhalb des physischen Blocks indirekt referenziert. Ein Handle wird dereferenziert, indem der physische Block bestimmt wird, der der logischen Blocksequenznummer entspricht, auf die Variable Offset in dem Alloc-Eintrag mit der Indexierung durch den Indexteil des Handles zugegriffen wird, und die Variable Offset der Startadresse des physikalischen Blocks hinzugefügt wird. Diese Dereferenzierung erzeugt die Adresse der Region. Die Verwendung von Handles ermöglicht, dass der FEProm-Verwalter einen Block zurückgewinnt, ohne dass gegebenenfalls existierende Verknüpfungen (links) mit Datenregionen angepasst werden müssten. Es muss lediglich ein Übersetzungscache (nachstehend noch beschrieben) aktualisiert werden, der in dem Speicher vorhanden ist, und der die logischen Blocksequenznummern auf physikalische Blöcke und die Versätze in dem Alloc-Feld abbildet. Wird ein Handle dereferenziert, so wird der neue Versatz verwendet, um die richtige Adresse zu erzeugen. 22 zeigt die Dereferenzierung eines Handles 2501, der eine Blocksequenz nummer 2502 von 9 und einen Alloc-Index 2503 von 3 enthält. Der Blockübersetzungscache 2504 bildet logische Blocknummern auf physische Blocknummern ab. Der FEProm-Verwalter verwaltet den Cache. Wird während der Blockrückgewinnung ein physischer Block zu einem anderen psychischen Block bewegt, so passt der FEProm-Verwalter den Übersetzungscache an, um die logische Blocksequenznummer auf den neuen physischen Block abzubilden. Bei dem Beispiel von 22 wird die logische Blocksequenznummer 9 auf den physikalischen Block 14 2505 abgebildet. Das Alloc-Feld für die physikalische Blocknummer 14 ist durch den Alloc-Index 2503 des Handles 2501 indexiert. Die Variable Offset des Alloc[3]-Eintrages enthält den Versatz der Region 3 2506 in der physikalischen Blocknummer 14 2505. Die Adresse der Region 3 2506 wird bestimmt, indem der Versatz zu der Adresse des physikalischen Blocks 2505 hinzugefügt wird.
26 ist ein Flussdiagramm der Regionszuordnungsroutine, die eine neue Region innerhalb eines Blockes zuordnet. Die Eingabeparameter für diese Routine sind diejenigen Daten, die in der Region gespeichert werden sollen, sowie die Länge der Daten. Die Routine gibt den Handle an die zugeordnete Region zurück. Alternativ schreibt die Routine die Daten nicht, sondern nimmt lediglich eine Platzzuordnung vor. Bei der Routine wird davon ausgegangen, dass der Block ausreichend freien Platz für die Region und einen zusätzlichen Alloc-Eintrag enthält. 28 ist ein Statusdiagramm für den Status (Zustand) eines Alloc-Eintrages. Ein Alloc-Eintrag kann einen der nachfolgenden Zustände aufweisen: nicht genutzt, zugeordnet, freigegeben, ersetzt, frei oder null. Der Eintrag ist darüber hinaus in einem Übergangsstatus beziehungsweise Übergangszustand befindlich, während die Zuordnung vorgenommen wird. Wird ein Eintrag nicht genutzt, dann ist er jenseits des letzten Eintrages in dem Alloc-Feld befindlich, das heißt, er ist nicht Teil des Feldes. Lautet der Eintrag zugeordnet, so ist die entsprechende Region derzeit zugeordnet. Lautet der Eintrag freigegeben, so wird die entsprechende Region nicht gebraucht, wobei jedoch die Region auch nicht zurückgewonnen worden ist. Lautet der Eintrag ersetzt, so entspricht ein anderer Alloc-Eintrag beziehungsweise entsprechen andere Alloc-Einträge derselben Datenregion. Während der Rückgewinnung werden die Daten in einem ersetzten Eintrag ignoriert, da ein anderer Eintrag beziehungsweise andere Einträge auf die Datenregion verweisen. Lautet ein Eintrag frei, so ist die entsprechende Region zurückgewonnen worden, und der Alloc-Eintrag kann neuverwendet werden, wenn eine neue Region dem Block hinzugefügt wird. Lautet der Eintrag null, so trat während des Schreibens in den Eintrag ein Problem auf, und es erfolgt bis zur Löschung keine Benutzung. Ist der Eintrag im Übergangsstatus „Zuordnung wird vorge nommen" befindlich, so können einige Daten, jedoch nicht notwendigerweise alle Daten in dem Eintrag gültig (valid) sein.
Gemäß 28 sind sämtliche Einträge anfänglich im „nicht genutzt"-Zustand 3101 und gehen in den „nicht genutzt"-Zustand 3101 über, wann immer der Block gelöscht wird. Ein Eintrag geht von dem „nicht genutzt"-Zustand 3101 während des „Zuordnung wird vorgenommen"-Zustandes 3104 in den „zugeordnet"-Zustand 3103 über. Ein Eintrag indem „frei"-Zustand 3102 geht in den „zugeordnet"-Zustand 3103 über. Ein Eintrag in dem „nicht genutzt"-Zustand 3103 geht als Ergebnis einer Blockrückgewinnung in den „frei"-Zustand 3102 über, wenn jener Eintrag freigegeben oder ersetzt und nicht nach dem letzten zugeordneten Eintrag in dem rückzugewinnenden Block angeordnet worden ist. Ein Eintrag in dem „zugeordnet"-Zustand 3103 geht in den „freigegeben"-Zustand 3105 über, wenn die entsprechende Region freigegeben ist. Ein Eintrag in dem „zugeordnet"-Zustand 3105 geht in den „ersetzt"-Zustand 3106 über, wenn ein anderer Eintrag beziehungsweise andere Einträge zugeordnet werden, die derselben Region entsprechen. Schließlich geht bei einem Schreibfehler in einen Eintrag der Eintrag in einem beliebigen Zustand in den „null"-Zustand 3107 über.
Gemäß 26 bestimmt das System in dem Block 2901, ob ein Alloc-Eintrag den „frei"-Zustand aufweist. Wird ein derartiger Eintrag gefunden, so verwendet das System den Eintrag erneut und geht zu einem Block 2902 über, wohingegen es andernfalls zu dem Block 2903 übergeht. In dem Block 2902 wählt das System den freien Alloc-Eintrag aus und geht zu dem Block 2905 über. In dem Block 2903 ordnet das System einen neuen Alloc-Eintrag zu, wählt diesen aus und geht zu dem Block 2904 über. Der neue Alloc-Eintrag ist der Eintrag genau nach dem letzten markierten Eintrag. In dem Block 2904 setzt das System die Variable Status für den ausgewählten Alloc-Eintrag derart, dass angegeben wird, dass die Zuordnung vorgenommen wird. Der „Zuordnung wird vorgenommen"-Zustand ist ein Übergangszustand, der angibt, dass die Daten gegebenenfalls in einem inkonsistenten Zustand befindlich sind. In dem Block 2905 setzt das System die Variablen Offset und Len und schreibt die Daten in eine Datenregion, wobei es mit der ersten Stelle des freien Platzes beginnt. In dem Block 2906 geht für den Fall, dass der Alloc-Eintrag neu ist, das System zu dem Block 2907 über, wohingegen es andernfalls zu dem Block 2908 übergeht. In dem Block 2907 setzt das System den Zustand beziehungsweise Status des vorherigen letzten Alloc-Eintrages zurück, um anzugeben, dass dieser nicht mehr den letzten Eintrag in der Alloc-Struktur darstellt. In dem Block 2908 setzt das System die Variable Status für den ausgewählten Alloc-Eintrag auf „zu geordnet", wodurch angegeben wird, dass die Daten jetzt in einem konsistenten Zustand befindlich sind. Das System hat die Zuordnung damit beendet.
Wie vorstehend erläutert wurde, verschlechtert sich die Leistung eines Blocks eines FEProm mit der Zunahme des Löschzählwertes. Es wird vorgezogen, den Löschzählwert für jeden der Blöcke annähernd gleich zu halten, was auch als „ausgeglichen" (leveled) bezeichnet wird. Im Normalbetrieb sind die Löschzählwerte nicht ausgeglichen. Werden beispielsweise ausführbare Dateien in einen Block geschrieben, so kann der Fall auftreten, dass jener Block nicht gelöscht werden muss. Daher verbleibt der Löschzählwert für jenen Block konstant, wohingegen der Löschzählwert für andere Blöcke zunimmt. Ein bevorzugtes Ausführungsbeispiel greift auf mehrere Lösungsansätze zurück, um die Blocklöschzählwerte auszugleichen. Zunächst tastet der FEProm-Verwalter während des Hochfahrens (Bootens) oder bei jedem Laden (Initialisieren) eines FEProm die Platte ab, um Daten zur Verwaltung des FEProm zu ermitteln. Bei einem bevorzugten Ausführungsbeispiel enthalten diese Daten den Löschzählwert für jeden Block. Um einen Ausgleich der Löschzählwerte zu unterstützen, tauscht der FEProm-Verwalter Daten in einem Block mit einem hohen Löschzählwert gegen Daten in einem Block mit einem niedrigen Löschzählwert aus. Da dieser Austausch einige Zeit in Anspruch nehmen kann, ist wünschenswert, die Anzahl von Tauschvorgängen, die während der Initialisierung vorgenommen werden, zu minimieren. Darüber hinaus muss der Austausch lediglich dann vorgenommen werden, wenn die Differenz zwischen Löschzählwerten einen Schwellenwert oder ein entsprechendes Verhältnis übersteigt. Zweitens wählt der FEProm-Verwalter für den Fall, dass er eine Rückgewinnung eines Blockes vornimmt, vorzugsweise einen verfügbaren Block mit einem niedrigen Löschzählwert aus. Drittens erfolgt, wenn der FEProm-Verwalter eine Region zuordnet, eine Zuordnung der Region in einem Block mit einem niedrigen Löschzählwert. Viertens verfolgt der FEProm-Verwalter die Anzahl der Blocklöschungen. Überschreitet die Anzahl der Löschungen einen Schwellenwert, so bestimmt der FEProm-Verwalter, ob die Differenz bei den Löschzählwerten für zwei beliebige Blöcke den Schwellenwert oder das entsprechende Verhältnis überschreitet. Ist die Schwelle überschritten, so tauscht der Verwalter die Daten in den Blöcken aus.
Der FEProm-Verwalter führt den Löschzählwert vorzugsweise in dem Header jedes physikalischen Blockes. Wird ein Block gelöscht, so schreibt der FEProm-Verwalter den heraufgesetzten Löschzählwert zurück in den Blockheader. Wird ein Block kopiert, so wird der Löschzählwert nicht übertragen. Jeder Block behält seinen eigenen Löschzähl wert. Alternativ können die Löschzählwerte in einem einzigen Block gespeichert werden. Diese Vorgehensweise hat jedoch gegenüber dem bevorzugten Verfahren einige Nachteile. Zuallererst können sämtliche Löschzählwerte beim Versagen eines einzigen Blockes verloren gehen. Zweitens muss, wenn ein Block gelöscht wird, der Löschzählwertblock aktualisiert werden. Gegebenenfalls muss der Löschzählwertblock gelöscht und neugeschrieben werden.
25 ist ein Flussdiagramm der Blockzuordnungsroutine, die auswählt, welche Blocks in dem blockweise löschbaren FEProm zur Zuordnung einer Region verwendet werden sollen. Der FEProm-Verwalter bestimmt, welcher Block zugeordnet werden soll, und zwar auf Basis mehrerer Faktoren. Zuerst ordnet der FEProm-Verwalter einen Block mit ausreichend freiem Platz zu, der den niedrigsten Löschzählwert aufweist. Die Zuordnung von Blöcken mit niedrigen Löschzählwerten stellt sicher, dass die Blöcke ausgeglichen sind. Zweitens ordnet der FEProm-Verwalter mehrere Blöcke zu, wenn ein Block mit ausreichend freiem Platz vorhanden ist. Die Daten werden in mehrere Regionen unterteilt, von denen jede in einem anderen Block gespeichert wird. Drittens unterbindet der FEProm-Verwalter die Zuordnung, wenn zu viele Fragmente erzeugt werden. Die Eingabeparameter für diese Routine sind die Länge der zuzuordnenden Regionen und das Faktum, ob die Region in mehreren Blöcken gespeichert werden kann. In dem Block 2801 wählt das System sämtliche Blöcke mit ausreichend freiem Platz zur Speicherung der Daten aus. Bei einem bevorzugten Ausführungsbeispiel bestimmt das System die Länge des freien Platzes auf Basis der Zuordnung des Anfanges des freien Platzes und der Anzahl der Alloc-Einträge. Diese Daten werden vorzugsweise gegebenenfalls während der Initialisierung und der Aktualisierung in einem FEProm-Verwalter-Puffer gespeichert. Das System stellt darüber hinaus sicher, dass ausreichend Platz zur Verfügung steht, um gegebenenfalls einen neuen Alloc-Eintrag hinzuzufügen. Bei einem Ausführungsbeispiel nimmt das System eine Blockrückgewinnung für jene Blöcke vor, die den Rückgewinnungskriterien genügen, bevor eine Bestimmung dahingehend erfolgt, ob der Block ausreichend freien Platz enthält. Bei einem alternativen Ausführungsbeispiel wird keine Blockrückgewinnung vorgenommen, bis bestimmt ist, dass nicht ausreichend freier Platz vorhanden ist. In dem Block 2802 ist für den Fall, dass wenigstens ein Block ausgewählt wird, ausreichend freier Platz in den einzelnen Blocks vorhanden, um die Region zu halten, woraufhin das System bei dem Block 2803 weitermacht, wohingegen es andernfalls bei dem Block 2804 weitermacht. In dem Block 2803 bestimmt das System, welcher der ausgewählten Blöcke den niedrigsten Löschzählwert aufweist und ordnet jeden Block zu, woraufhin das System mit der Blockzuordnung fertig ist. In dem Block 2804 wählt das System einen Satz von Blöcken aus, der ausreichend freien Platz enthält, um die Regionsdaten aufzubewahren. In dem Block 2805 macht das System für den Fall, dass der gesamte freie Platz und der freigegebene Platz nicht ausreichen, um die Daten aufzubewahren, oder für den Fall, dass zu viele Fragmente entstehen würden, bei dem Block 2807 weiter, wohingegen es andernfalls bei dem Block 2806 weitermacht. Müssen die Regionsdaten in einem einzelnen Block gespeichert werden, so impliziert die Auswahl zweier Blöcke zu viele Fragmente. Sollen die Dateien in mehreren Blöcken gespeichert werden, so ist gegebenenfalls eine Rückgewinnung angebracht. In dem Block 2806 ordnet das System die ausgewählten Blöcke zu, woraufhin die Blockzuordnung beendet ist. In dem Block 2807 ist für den Fall, dass die Blöcke rückgewonnen worden sind, nicht ausreichend Platz in dem FEProm vorhanden, um die Daten zu speichern, wodurch die Blockzuordnung beendet ist, wohingegen das System andernfalls bei dem Block 2808 weitermacht. Bei dem Block 2808 gewinnt das System einen Block zurück und geht zu dem Block 2801 zurück, um zu bestimmen, ob noch ausreichend freier Platz vorhanden ist.
27 ist ein Flussdiagramm der Blockrückgewinnungsroutine, bei der die freigegebenen Regionen in einem Block zurückgewonnen werden. Die Eingabeparameter sind die Nummer des rückzugewinnenden Blocks und die physische Nummer eines Ersatzblocks. Ein Block kann zu mehreren verschiedenen Zeitpunkten zurückgewonnen werden. Zunächst kann ein Block (wie vorstehend erläutert) zurückgewonnen werden, wenn nicht ausreichend freier Platz vorhanden ist, um eine Zuordnungsanforderung zu erfüllen. Zweitens kann der FEProm-Verwalter die Anzahl der Schreibzugriffe auf den FEProm verfolgen. Übersteigt die Anzahl der Schreibvorgänge eine Schwellenanzahl, so bestimmt der Verwalter, ob irgendwelche Blocks zurückgewonnen werden können. Ein Block sollte zurückgewonnen werden, wenn das Verhältnis zwischen dem freigegebenen Platz und der Blockgröße einen Schwellenwert übersteigt. Einem Fachmann auf dem einschlägigen Gebiet erschließt sich unmittelbar, dass eine Blockrückgewinnung auch zu anderen Zeitpunkten vorgenommen werden kann, beispielsweise, wenn ein FEProm erstmalig geladen wird. Der FEProm-Verwalter gewinnt einen Block zurück, indem die zugeordneten Regionen in einen Ersatzblock kopiert werden, das heißt in einen Block, der gelöscht worden ist. Indem lediglich die zugeordneten Regionen kopiert werden, werden die freigegebenen Regionen zurückgewonnen. Alternativ kann der FEProm-Verwalter die zugeordneten Regionen in einen Nicht-FEProm-Speicher kopieren, anschließend den Block löschen und die Regionen zurück in den Block kopieren. Gleichwohl erfordert dieses Verfahren ausreichend Nicht-FEProm-Speicher, um die zugeordne ten Regionen zu speichern und birgt die Möglichkeit in sich, dass Daten verloren gehen, sollte ein Systemausfall nach dem Löschen, jedoch vor dem Neuschreiben des Blocks auftreten. Bei den bevorzugten Verfahren kopiert der FEProm-Verwalter die zugeordneten Regionen in dem zurückzugewinnenden Block in den Ersatzblock und kopiert die Blockzuordnungsstruktur, indem die Variable Offset derart angepasst wird, dass sie die Speicherstellen der neuen Region in dem Ersatzblock angibt. 20A zeigt ein Beispiel für den Blockaufbau von 20, nachdem die Regionen 1 und 5 zurückgewonnen worden sind. Die zugeordneten Regionen werden derart kopiert, dass sie einander benachbart sind. Die entsprechenden Alloc-Einträge werden derart aktualisiert, dass sie auf die neuen Regionsspeicherstellen zeigen. Der Alloc[1]-Eintrag wird nach wie vor benötigt, auch wenn die Region 1 zurückgewonnen worden ist. Aufgrund der Verwendung von Handles müssen sämtliche Alloc-Einträge ihre Position in der Blockzuordnungsstruktur behalten. Gleichwohl wird die Variable Status für den Alloc[1]-Eintrag auf „frei" gesetzt und kann verwendet werden, um auf die nächste Regionen zu verweisen, die dem zurückgewonnenen Block hinzugefügt wird. Da keine Alloc-Einträge nach dem Alloc[5]-Eintrag mehr vorhanden sind, besteht kein Bedarf an Platzhaltern für irgendwelche Handles, weswegen eine Entfernung erfolgt. Der Positionszustand des Alloc[4]-Eintrages gibt an, dass es sich hierbei um den letzten Eintrag in dem Alloc-Feld handelt.
29 ist ein Zustandsdiagramm für den Zustand eines Blockes. Der Zustand eines Blockes wird in dem Header der Variable Status gespeichert. Die Zustände eines Blockes lauten: „gelöscht" 3201, „Aktualisierung wird vorgenommen" 3202, „Ersatz" 3203, „Rückgewinnung wird vorgenommen" 3204, „fertig" 3205, „in der Warteschlange zum Löschen befindlich" 3206 und „Ruhe(zustand)" 3207. Ein neugelöschter Block befindet sich im gelöschten Zustand 3201. Ein gelöschter Block geht üblicherweise in den „Aktualisierung wird vorgenommen"-Zustand 3202 und anschließend in den „Ersatz"-Zustand 3203 über. Der „Aktualisierung wird vorgenommen"-Zustand 3202 gibt an, dass bestimmte Daten in dem Header, so beispielsweise der Löschzählwert, gerade aktualisiert werden. Sobald die Aktualisierung beendet ist, geht der Block in den „Ersatz"-Zustand 3203 über. Versagt die Aktualisierung, so geht der Block in den „in der Warteschlange zum Löschen befindlich"-Zustand 3206 über. Ein Block in dem „Ersatz"-Zustand 3203 geht in den „Rückgewinnung wird vorgenommen"-Zustand 3204 über, wenn der Block Dateien aus einem rückzugewinnenden Block aufnehmen soll. Der „Rückgewinnung wird vorgenommen"-Zustand 3204 ist ein Übergangszustand, der angibt, dass die Blockzuordnungsstruktur gegebenenfalls in einem inkonsistenten Zustand befindlich ist. Sobald die Daten konsistent sind, geht der Block in den „fertig"-Zustand 3205 über. Wenn jedoch ein Fehler während des „Rückgewinnung wird vorgenommen"-Zustandes 3205 auftritt, so geht der Block in den „in der Warteschlange zum Löschen befindlich"-Zustand 3206 über, nachdem eine Rückgewinnung für jeden Block erfolgt ist. Ein Block in dem „in der Warteschlange zum Löschen befindlich"-Zustand 3206 geht in den „gelöscht"-Zustand 3201 über, wenn die Löschung erfolgt ist. Erfolgt keine Löschung, so geht der Block in den „Ruhe"-Zustand 3207 über. Der Block verbleibt dann fortwährend im „Ruhe"-Zustand. Wird ein FEProm erstmalig initialisiert, so werden die Blöcke entweder in den „fertig"-Zustand oder den „Ersatz"-Zustand versetzt. Blöcke in dem „fertig"-Zustand können Daten enthalten, wohingegen Blöcke in dem „Ersatz"-Zustand keine Daten enthalten.
Gemäß 27 setzt das System in dem Block 3001 die Variable Status für den rückzugewinnenden Ersatzblock derart, dass angezeigt wird, dass die Rückgewinnung vorgenommen wird. In dem Block 3002 kopiert das System die Variablen Seq, SeqCheckSum und BootRecordPtr aus dem Header des rückzugewinnenden Blockes in den Ersatzblock. In dem Block 3003 bestimmt das System die Position des letzten Alloc-Eintrages in dem zugeordneten Zustand für den rückzugewinnenden Block. Während des Rückgewinnungsvorganges werden Alloc-Einträge nach dem letzten zugeordneten Eintrag ignoriert. Auf diese Weise hat der zurückgewonnene Block die Zustände derjenigen Einträge, die auf „nicht genutzt" gesetzt sind. In den Blöcken 3004 bis 3010 kopiert das System jeden Alloc-Eintrag bis zum letzten zugeordneten Eintrag in den Ersatzblock. In dem Block 3004 initialisiert das System den Index, der die Alloc-Einträge indexiert. In dem Block 3005 werden, wenn der Index größer als der Index des letzten zugeordneten Eintrages gemäß Bestimmung in dem Block 3003 ist, sämtliche Alloc-Einträge und die entsprechenden Regionen kopiert, woraufhin das System bei dem Block 3011 weitermacht, wohingegen es andernfalls bei dem Block 3006 weitermacht. In dem Block 3006 macht das System, wenn der Zustand des Eintrages zugeordnet ist, bei dem Block 3007 weiter, wohingegen das System andernfalls bei dem Block 3009 weitermacht. In dem Block 3007 kopiert das System die dem Alloc[j]-Eintrag entsprechenden Regionsdaten in den Ersatzblock. In dem Block 3008 aktualisiert das System die Variable Offset in dem Alloc-Eintrag des Ersatzblockes, um die Stelle der kopierten Region anzuzeigen, kopiert die Variablen Status (wobei der Positionsstatus geeignet gesetzt wird) und Len und macht bei dem Block 3010 weiter. In dem Block 3009 aktualisiert das System den Zustand des Alloc[j]-Eintrages des Ersatzblockes, um anzuzeigen, dass der Eintrag frei ist. In dem Block 3010 setzt das System den Index j herauf, um den nächsten Alloc-Eintrag zu indexieren, und kehrt zu dem Block 3005 zurück. In dem Block 3011 setzt das System den Zustand des Ersatzblockes auf „fertig". In dem Block 3012 setzt das System den Zustand des rückzugewinnenden Blockes auf „in der Warteschlange zum Löschen befindlich". Nach der vollständigen Verarbeitung für den Block 3011, jedoch vor der Verarbeitung für den Block 3012 weisen sowohl der Ersatzblock wie auch der rückzugewinnende Block gültige Daten auf. Wird die Verarbeitung vor der fertigen Verarbeitung des Blockes 3012 unterbrochen, so enthält der FEProm zwei Blöcke mit derselben logischen Sequenznummer. Vorzugsweise überprüft das System diese Bedingung während der Initialisierung des FEProm. Zu jenem Zeitpunkt kann das System die Verarbeitung des Blocks 3012 vervollständigen. In dem Block 3013 aktualisiert das System die Variablen PhysicalBlockNun, FirstFreeByteOffset, LenDeallocatedSpace und AllocStructCnt in BlockData[Seq], um den Zustand des Ersatzblockes (wird nachstehend noch beschrieben) anzugeben. In dem Block 3014 aktualisiert das System die Größe DriveRec, um die Liste der Ersatzblöcke anzupassen, woraufhin die Rückgewinnung beendet ist (Beschreibung nachstehend).
Tabelle B: Datenstruktur
Definitionen

BlockCnt

Anzahl der physikalischen Blöcke in dem FEProm

BlockSize

Anzahl der Bytes in einem Block

RootDirPtr

Handle bezüglich der Datenregion, die das Ausgangsverzeichnis enthält, bei Verwendung des FEProm als Dateispeichervorrichtung

SpareBlockPtr[]

veränderliche Länge aufweisendes Feld, das die physikalischen Blocknummern der Ersatzblöcke enthält

SpareBlockCnt

Anzahl der Ersatzblöcke

WriteAccessCntThreshold

Anzahl der Schreibungen in den FEProm, die das System veranlasst zu bestimmen, ob Blöcke zurückgewonnen werden sollten

EraseCntThreshold

Anzahl der Löschungen in dem FEProm, die das System veranlasst zu bestimmen, ob ein Blockausgleich vorgenommen werden soll

BlockReclamationThreshold

Verhältnis zwischen freigegebenem Platz und Blockgröße, bei dem die Blockrückgewinnung ausgelöst wird

BlockEraseLevelingThreshold

Differenz zwischen minimalem und maximalem Löschzählwert, bei der der Ausgleichsvorgang zwischen den Blöcken ausgelöst wird

PhysicalBlockNum

Nummer des physikalischen Blockes, enthaltend den logischen Block

FirstFreeByteOffset

in dem physikalischen Block vorhandener Versatz des ersten Bytes des freien Platzes

LenDeallocatedSpace

Gesamtlänge der freigegebenen Regionen in dem physikalischen Block

FirstUsableAllocEntry

Index des ersten verwendbaren Alloc-Eintrages in dem Block

AllocStructCnt

Anzahl der Alloc-Einträge

BlockEraseCnt

Anzahl der Löschungen des physikalischen Blocks

Wird ein FEProm erstmalig geladen, so tastet der FEProm-Verwalter den FEProm ab, um die internen Datenstrukturen (siehe Tabelle B) zu initialisieren. Die Struktur DriveRec enthält Daten, die sich auf die Vorrichtung beziehen, und die Struktur ConfigRec enthält Daten, die sich auf die Konfigurationsparameter beziehen, während das Feld BlockData einen Eintrag mit Daten für jeden physischen Block in dem FEProm enthält. Das Feld BlockData ist der Blockübersetzungscache. Während der Initialisierung initialisiert der FEProm-Verwalter jede der Variablen in dem Feld BlockData und die Variablen, die sich auf die Ersatzblöcke in der Struktur DriveRec beziehen. Die anderen Variablen in der Struktur DriveRec sind systemdefinierte Variablen. Bei einem bevorzugten Ausführungsbeispiel speichert der FEProm-Verwalter Information, die für jede Art von Regionsdaten in diesen Datenstrukturen spezifisch ist. Wird beispielsweise der FEProm als Dateispeichervorrichtung verwendet, so können die Dateistrukturen den Handle auf das Ausgangsverzeichnis (root directory) enthalten. 24 ist ein Flussdiagramm des Initialisierungsvorganges bei einem bevorzugten Ausführungsbeispiel. Das Verfahren initialisiert die DriveRec- und BlockData-Strukturen durch Abtastung der Blockzuordnungsstruktur für jeden Block in dem FEProm. In den Blöcken 2701 bis 2709 nimmt das System wiederholt ein Lesen von Daten aus jedem Block vor. In dem Block 2701 initialisiert das System den Index i, der den physischen Block, auf den aktuell zugegriffen wird, indexiert. In dem Block 2702 sind, wenn der Index i größer als die Anzahl der Blöcke in dem FEProm ist, alle Blöcke abgetastet, woraufhin das System bei dem Block 2710 weitermacht, wohingegen es andernfalls bei dem Block 2703 weitermacht. In dem Block 2703 liest das System den Header für den Block, der mit dem Index indexiert ist. In dem Block 2704 aktualisiert das System die DriveRec- und BlockData[i]-Daten. Ist der Block ein Ersatzblock, so setzt das System SpareBlockCnt herauf und fügt den Block dem SpareBlockPtr-Feld hinzu. Bei einem bevorzugten Ausführungsbeispiel nimmt das System zudem eine Abtastung nach Informationen vor, die für die in den Regionen gespeicherten Daten spezifisch sind. Wird der FEProm beispielsweise als Dateisystem verwendet, so setzt das System für den Fall, dass der Block den Booteintrag enthält, den BootRecPtr, liest den Booteintrag und setzt den RootDirPtr. In den Blöcken 2705 bis 2708 kreist das System, während es die Daten in jedem Alloc-Eintrag verarbeitet. In dem Block 2705 initialisiert das System den Index j, der Alloc-Einträge indexiert. In dem Block 2706 macht das System, wenn es den letzten Alloc-Eintrag verarbeitet hat, bei dem Block 2709 weiter, wohingegen es andernfalls bei dem Block 2707 weitermacht. In dem Block 2707 aktualisiert das System BlockData[BlockSeq]-Daten auf Basis des mit j indexierten Alloc-Eintrages. Das System aktualisiert die Variablen FirstFreeByteOffset, LenDeallocatedSpace und AllocStructCnt. Das System setzt die Variable Physical BlockNum auf den Index i, der den Übersetzungscache initialisiert. In dem Block 2708 setzt das System den Index j herauf, um den nächsten Alloc-Eintrag zu indexieren, und kehrt zu dem Block 2706 zurück. In dem Block 2709 setzt das System den Index i herauf, um den nächsten Block in dem FEProm zu indexieren, und kehrt zu dem Block 2702 zurück. In dem Block 2710 gleicht das System anschließend die Blocknutzung aus. Das System tastet das BlockData-Feld ab, um denjenigen Block mit dem maximalen BlockEraseCnt und denjenigen Block mit dem minimalen BlockEraseCnt zu bestimmen. Das System tauscht sodann die Daten zwischen den Blöcken aus. Das System kopiert zunächst den maximalen Block in einen Ersatzblock. Das System löscht anschließend den maximalen Block. Das System kopiert die Daten aus dem minimalen Block in den gelöschten Block und nimmt während des Kopierens vorzugsweise eine Blockrückgewinnung vor. Das System löscht den minimalen Block, kopiert die Daten aus dem Ersatzblock in dem minimalen Block und nimmt vorzugsweise während des Kopierens eine Blockrückgewinnung vor.
Der FEProm-Verwalter der vorliegenden Erfindung kann Medien unterstützen, die nicht blockiert sind, oder die nicht löschbar sind. Die Vorgänge der Blockrückgewinnung und des Ausgleichs des Blocklöschzählwertes beruhen auf der blockweise möglichen Löschbarkeit. Daher sollten diese Vorgänge deaktiviert sein, wenn das Medium keine blockweise mögliche Löschbarkeit unterstützt. Bei einem bevorzugten Ausführungsbeispiel können diese Vorgänge effektiv deaktiviert werden, indem der Ersatzblockzählwert auf Null gesetzt wird. Der FEProm-Verwalter beruht auf mindestens einem Ersatzblock, um diese Vorgänge zu aktivieren. Ist das Medium nicht blockiert, so kann eine willkürliche Blockgröße als logischer Block ausgewählt werden. Bei einem bevorzugten Ausführungsbeispiel sollte die Größe des Blockes nicht derart groß sein, dass der Versatz in den Zuordnungsfeldeinträgen nicht den gesamten Block aktualisiert, und sie sollte gleichzeitig nicht zu klein sein, dass der Blockheader und das Zuordnungsfeld einen merklichen Prozentsatz der Blockgröße ausmachen, oder dass der Übersetzungscache zu groß ist.
Der FEProm-Verwalter ermöglicht eine dynamische Behebung für FEProm-Schreib- und Löschfehler. Ein Schreibfehler tritt auf, wann immer eine Speicherstelle nicht auf den spezifizierten Wert gesetzt werden kann. Diese Fehler werden entweder durch einen Ausfall der Hardware oder durch den Versuch verursacht, einen Wert in eine Speicherstelle zu schreiben, an der 1 an einem bestimmten Bit erforderlich ist, obwohl bereits in 0 geändert wurde.
Schreibfehler können beim Schreiben einer Datenregion, eines Blockheaders und eines Zuordnungsfeldeintrages auftreten. Bei einem bevorzugten Ausführungsbeispiel setzt der FEProm-Verwalter, wenn ein Schreibfehler während des Schreibens in einer Datenregion auftritt, den Block in den „freigegeben"-Zustand. Der FEProm-Verwalter versucht anschließend, die Daten in eine andere Datenregion zu schreiben, indem der Regionszuordnungsvorgang, wie in 26 gezeigt ist, erneut begonnen wird.
Tritt ein Schreibfehler während des Schreibens in einem Zuordnungsfeldeintrag auf, so setzt der FEProm-Verwalter den Zuordnungsfeldeintrag in den „null"-Zustand. Trat der Fehler auf, während ein Eintrag in den „ersetzt"-, „freigegeben"-, „frei"- oder „Zuordnung wird vorgenommen"-Zustand gesetzt wird, so bewirkt das Setzen des Eintrages in den „null"-Zustand, dass der FEProm in einem konsistenten Zustand befindlich ist. Tritt der Fehler jedoch während des Setzens eines Eintrags in den „zugeordnet"-Zustand auf, so befindet sich der FEProm in einem inkonsistenten Zustand, da die Datenregion keinen entsprechenden Zuordnungsfeldeintrag aufweist, der in dem „zugeordnet"-Zustand befindlich ist. Der FEProm-Verwalter ordnet einen weiteren Eintrag für diese Datenregion zu. Ein Fehler kann zudem beim Setzen eines Eintrages in den „null"-Zustand auftreten. Da der neue Zustand als Zustand mit lauter Nullen definiert ist, ist ein Fehler beim Setzen eines Eintrages in den „null"-Zustand notwendigerweise ein Hardwarefehler. Tritt ein Fehler auf, so kann eine Rückgewinnung von Nöten sein, die spezifiziert, dass die entsprechende Region zurückgewonnen werden muss. Tritt beispielsweise ein Fehler während des Setzens eines Eintrages in den „freigegeben"-Zustand und wiederum während des Setzens des Eintrages in den „Ruhe"-Zustand auf, so wird der Eintrag im „zugeordnet"-Zustand sein. Bei einem Verbleib in diesem Zustand werden der Eintrag und die entsprechende Datenregion bei einer normalen Rückgewinnung nicht zurückgewonnen.
Tritt ein Fehler während des Schreibens in einem Blockheader auf, so setzt der FEProm-Verwalter den Block in den „in der Warteschlange zum Löschen befindlich"-Zustand. Tritt ein Fehler während des Setzens eines Blockes in den „in der Warteschlange zum Löschen befindlich"-Zustand auf, so setzt der FEProm-Verwalter den Block in den „Ruhe"-Zustand. Tritt ein Fehler während des Setzens eines Blockes in den Ruhezustand auf, so kann der Fehler nicht behebbar sein.
Tritt ein Schreibfehler während des Löschens eines Blockes auf, so setzt der FEProm-Verwalter den Block in den „Ruhe"-Zustand. Ist der „Ruhe"-Block ein Ersatzblock, so arbeitet der FEProm-Verwalter mit weniger Ersatzblöcken. Alternativ versucht der FEProm-Verwalter einen Block ohne zugeordnete Zuordnungsfeldeinträge zu lokalisieren. Der FEProm-Verwalter löscht den lokalisierten Block und setzt ihn in den „Ersatz"-Zustand. Sind keine Ersatzblöcke verfügbar, so behandelt der FEProm-Verwalter den FEProm so, als wäre er nicht löschbar, was vorstehend bereits erläutert wurde.
Die vorliegende Erfindung stellt darüber hinaus eine dynamische Fehlerbehebung für den Fall bereit, dass der FEProm in einem inkonsistenten Zustand befindlich ist. Wird der FEProm beispielsweise, wie in 26 dargestellt ist, entfernt, nachdem der Versatz in den Block 2905 geschrieben ist, jedoch bevor der Zustand von dem „frei"-Zustand in den „zugeordnet"-Zustand in Block 2908 aktualisiert wurde, so befindet sich der FEProm in einem inkonsistenten Zustand. Wird der FEProm nächstmalig geladen, so erfasst der FEProm-Verwalter, dass der Zuordnungseintrag „frei" ist, und versucht eine Neuverwendung desselben. Ein Versuch, nach Offset zu schreiben, würde jedoch fehlschlagen (es sei denn, dass dieselben Daten nach Offset geschrieben würden). Wie vorstehend erläutert, behebt der FEProm-Verwalter den Fehler dadurch, dass er den Eintrag in den „null"-Zustand versetzt und den Regionszuordnungsprozess erneut beginnt, um einen anderen Eintrag auszuwählen. Ist ein Teil der Daten in die Datenregion geschrieben, bevor der FEProm entfernt ist, so würde ein Fehler erfasst werden, wenn der FEProm-Verwalter versucht, die Daten über jene Region zu schreiben. Dieser Fehler würde gemäß vorstehender Beschreibung behandelt werden.
Dateisystem
Die vorliegende Erfindung stellt ein verzeichnisbasiertes hierarchisches Dateisystem für eine FEProm-Vorrichtung bereit. Ein hierarchisches Dateisystem ermöglicht das Speichern von Dateien in logischen Gruppierungen. Ein bevorzugtes Ausführungsbeispiel nutzt eine Verbundlistendatenstruktur, um sowohl die Verzeichnishierarchie wie auch die interne Dateispeicherung zu implementieren.
1A zeigt eine typische hierarchische Verzeichnisstruktur. Das MS-DOS-Betriebssystem, das bei der Microsoft Corporation aus Redmont, Washington, erhältlich ist, implementiert ein Dateisystem mit einer hierarchischen Verzeichnisstruktur. Wein 1A gezeigt ist, enthält das Verzeichnis ROOT 100 zwei Unterverzeichnisse (DOS 102 und WORD 103) und zwei Dateien (AUTOEXEC.BAT 104 und COMMAND.COM 105). Das Verzeichnis DOS 102 enthält eine Datei (FORMAT.EXE 106). Das Verzeichnis WORD 103 enthält zwei Unterverzeichnisse (DAVID 107 und MARY 108) in der nächsttieferen Ebene. Das Verzeichnis DAVID 107 enthält eine Datei LETTER1.DOC 109. Das Verzeichnis MARY 108 enthält drei Dateien LETTER1.DOC 110, LETTER2.DOC 111 und LETTER3.DOC 112.
1B zeigt eine mögliche Verbundliste, die die Verzeichnisstruktur von 1A bei einem bevorzugten Ausführungsbeispiel implementiert. Das Verzeichnis ROOT-Eintragung 100 (die Begriffe „Eintrag" beziehungsweise „entry" und „Eintragung" beziehungsweise „record" werden im Sinne dieser Beschreibung gleichwertig verwendet) enthält einen Zeiger 120, der auf eine Verbundliste 140 von Unterverzeichnis- und Dateieinträgen in der nächsttieferen Ebene verweist. Die Verbundliste 140 enthält Verzeichniseinträge DOS 102 und WORD 103 sowie Dateieinträge AUTOEXEC.BAT 104 und COMMAND.COM 105, die mittels Zeigern 121, 122, 123 verknüpft sind. Der Unterverzeichniseintrag DOS 102 enthält einen Zeiger 124 auf den Dateieintrag 106 auf der nächsttieferen Ebene, während der Unterverzeichniseintrag WORD 103 einen Zeiger 125 auf eine Verbundliste 141 von Unterverzeichniseinträgen auf der nächsttieferen Ebene aufweist. Die Verbundliste 141 enthält Verzeichniseinträge DAVID 107 und MARY 108, die mittels des Zeigers 126 verknüpft sind. Der Unterverzeichniseintrag DAVID 107 enthält einen Zeiger 127 auf die Datei auf der nächsttieferen Ebene, wohingegen der Unterverzeichniseintrag MARY 108 einen Zeiger 128 auf die Verbundliste 142 der Dateieinträge auf der nächsttieferen Ebene enthält. Die Verbundliste 142 enthält Dateieinträge LETTER1.DOC 110, LETTER2.DOC 111 und LETTER3.DOC 112, die mittels der Zeiger 129 und 130 verknüpft sind. Das Muster 10 zeigt den Aufbau der Eintragung, der in den Zeichnungen verwendet wird. Bei einem bevorzugten Ausführungsbeispiel sind die Einträge von 1B DirEntry- und FileEntry-Strukturen, die nachstehend noch beschrieben werden.
1B zeigt lediglich eine mögliche Verbundlistenanordnung, die 1A repräsentiert. Die Anordnung würde für den Fall anders aussehen, dass Dateien hinzugefügt, anschließend jedoch gelöscht werden, oder für den Fall, dass der Name einer Datei geändert wird. 1C zeigt eine weitere mögliche Anordnung. 1C stellt dieselbe Verzeichnishierarchie wie 1A dar, wobei jedoch das Verzeichnis BILL beziehungsweise RECHNUNG 113 zu einem bestimmten Zeitpunkt existierte, dann jedoch gelöscht wurde. Da eine FEProm-Vorrichtung nur einmal beschrieben werden kann (es sei denn, es erfolgt eine Löschung), wird bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung der Verzeichniseintrag BILL 113, wie in 1C gezeigt ist, nicht physisch aus der Verbundliste entfernt. Ein Verzeichnis- oder Dateieintrag wird aus der Verbundliste gelöscht, indem der Zustand des Verzeichnis- oder Dateieintrages geändert wird. Ist das Verzeichnis oder die Datei auf einer Computerplatte gespeichert, so kann der Verzeichniseintrag BILL 113 physisch entfernt werden, indem der Zeiger 131 in den Verzeichniseintrag DAVID 107 derart neugeschrieben wird, dass er auf den Verzeichniseintrag MARY 108 verweist.
Ein bevorzugtes Ausführungsbeispiel verwendet darüber hinaus eine Verbundlistendatenstruktur, um die Extents zu verknüpfen, die eine Datei bilden. Jede Datei weist einen damit verbundenen Dateieintrag auf, der – neben anderen Daten – den Namen der Datei enthält, und der mit der Verzeichnishierarchie gemäß vorstehender Beschreibung verknüpft ist. Ein Extent ist eine benachbarte Speicherregion, die Daten für die Datei enthält. Jede Datei enthält einen oder mehrere Extents, die Dateidaten enthalten. Jeder Extent enthält einen damit verknüpften Extent-Eintrag. Der Extent-Eintrag enthält – neben anderen Daten – einen Zeiger auf den Extent und die Länge des Extents. 2A zeigt die Extents der Datei „\A\D.DAT" 202. Die Extent-Einträge R1 203, R2 204 und R3 205 sind verknüpft und enthalten einen Zeiger auf die entsprechenden Extents E1 211, E2 212 und E3 213. Die Datei ist die logische Aneinanderreihung der Extents E1 211, E2 212 und E3 213. Bei einem bevorzugten Ausführungsbeispiel sind die Extent-Einträge FileInfo-Strukturen gemäß nachstehender Beschreibung.
2A stellt lediglich eine mögliche Verbundlistenanordnung für die Datei „\A\D.DAT" 202 dar. 2B zeigt eine weitere Anordnung, die dieselbe Datei darstellt. Der Extent E4 214 wurde der Datei angefügt, anschließend jedoch gelöscht. Bei einem bevorzugten Ausführungsbeispiel wird der Extent-Eintrag R4 206 nicht physisch aus der Verbundliste derjenigen Extents, die die Datei bilden, entfernt. Vielmehr wird der Extent-Eintrag E4 206 logisch entfernt, indem der Zustand des Eintrages derart gesetzt wird, dass angezeigt wird, dass der Eintrag gelöscht ist.
Tabellen C und D enthalten einige Datenstrukturen, die bei einem bevorzugten Ausführungsbeispiel der vorliegenden Erfindung zum Einsatz kommen. Die Datenstruktur gemäß Tabelle C ist der BootRecord. Der BootRecord enthält bestimmte allgemeine Informationen, die sich auf die Identifikation des Datensystems, die Versionsnummer des Datensystems, das auf den FEProm zugreifen kann, den Zeiger auf das Ausgangsver zeichnis und zusätzliche Daten, siehe nachstehende Beschreibung, beziehen. Die erste und zweite Struktur gemäß Tabelle B sind DirEntry- und FileEntry-Strukturen. Eine dieser Strukturen wird für jedes Verzeichnis und für jede Datei zugeordnet. Die Strukturen sind identisch. Die Variable SiblingPtr verweist auf den nächsten Sibling in der Verbundliste der DirEntry- und FileEntry-Strukturen auf derselben Ebene in der Verzeichnishierarchie. Die Variablen PrimaryPtr und SecondaryPtr werden nachstehend vollständig beschrieben. Die dritte Struktur ist die FileInfo-Struktur. Jeder Datei-Extent weist eine zugeordnete FileInfo-Struktur auf. Die Variable PrimaryPtr verweist auf die FileInfo-Struktur für jede Datei.
Tabelle C: Datenstruktur
Definitionen

Signature

Wert, der angibt, dass das Medium dieses Dateisystem unterstützt

SerialNumber

in Kombination mit VolumeLabel eine eindeutige Kennung für den speziellen FEProm

FFSWriteVersion

Versionsnummer im Highbyte und Revisionsnummer im Lowbyte eines Dateisystems, deren Schreiben in diesen Abschnitt notwendig ist

FFsReadVersion

Versionsnummer im Highbyte und Revisionsnummer im Lowbyte der ältesten Version eines Dateisystems, deren Schreiben in diesen Abschnitt notwendig ist

TotalBlockCount

Gesamtzahl der Blöcke, einschließlich Ersatzblöcke, in dem FEProm

SpareBlockCount

Anzahl der Blöcke, die für eine Blockrückgewinnung und Fehlerbehebung verfügbar sind

BlockLen

Länge eines Blockes in Byte

RootDirectoryPtr

Zeiger auf das Ausgangsverzeichnis Status Daten, die Dateinamenformate spezifizieren

VolumeLabelLen

Anzahl der Zeichen im Volumelabel BootCodeLen Anzahl der Bytes im Bootcodefeld; bei „0" Medium nicht bootbar

VolumeLabel[]

Volumelabel

BootCode[]

Bootcode für das Betriebssystem

Tabelle D: Datenstruktur
Definitionen
Das Dateisystem der vorliegenden Erfindung unterteilt die Verzeichnis- und Dateistrukturen in einem blockweise löschbaren FEProm über Blockgrenzen hinweg. Das Dateisystem bedient sich des FEProm-Verwalters, um den Speicher in dem FEProm zuzuordnen und freizugeben. Das Dateisystem verwendet, wie vorstehend beschrieben, Handles als Zeiger in den Verbundlisten. Im Folgenden werden die beiden Begriffe „Handles" und „Zeiger" gleichbedeutend verwendet. 23 zeigt eine Beispielsblockzuordnung für einen Teil der Verzeichnishierarchie von 1B. Der in 23 gezeigte Teil umfasst die DirEntry- und FileEntry-Eintragungen für das Verzeichnis ROOT, das Verzeichnis DOS, die Datei AUTOEXEC.BAT und die Datei COMMAND.COM. Der Block 0 umfasst das Verzeichnis DOS und das Verzeichnis WORD. Der Block 12 umfasst das Verzeichnis ROOT und die Datei COMMAND.COM, und der Block 14 umfasst die Datei AUTOEXEC.BAT.
21 zeigt Beispielsblockzuordnungsstrukturen und Regionen für das Beispiel von 23. 21 zeigt den Block 0 2401, den Block 12 2402 und den Block 14 2403. Der Block 0 2401 umfasst Regionen 2420 und 2430. Die Region 2420 umfasst den DirEntry für das Verzeichnis DOS, und die Region 2430 umfasst den DirEntry für das Verzeichnis WORD. Der Block 0 2401 umfasst darüber hinaus den Header 2404. Der Alloc[0]-Eintrag 2421 entspricht der Region 2420, und der Alloc[1]-Eintrag 2431 entspricht der Region 2430. Der Block 12 2402 umfasst Regionen 2410 und 2450. Die Re gion 2410 umfasst den DirEntry für das Verzeichnis ROOT, und die Region 2450 umfasst den FileEntry für die Datei COMMAND.COM. Der Block 12 2402 umfasst darüber hinaus den Blockheader 2405, den Alloc[0]-Eintrag 2411 entsprechend der Region 2410 und den Alloc[1]-Eintrag 2451 entsprechend der Region 2450. Der Block 14 2403 umfasst Regionen 2490 und 2440. Die Region 2490 umfasst die Booteintragung, und die Region 2440 umfasst den FileEntry für die Datei AUTOEXEC.BAT. Der Block 14 2403 umfasst darüber hinaus den Blockheader 2406, den Alloc[0]-Eintrag 2491 entsprechend der Region 2490 und den Alloc[1]-Eintrag 2451 entsprechend der Region 2440.
In 21 definieren die Zeiger 2407, 2413, 2423, 2433, 2443, 2453 und 2493 die Verzeichnishierarchie, beginnend mit dem Zeiger 2407 bis hin zu der Booteintragung in dem Blockheader 2406. Die Booteintragung 2490 ist in dem Block 14 2403 befindlich. Die Variable Status für den Block 14 2403 zeigt an, dass der Block das Bootverzeichnis enthält. Der BootRecordPtr 2407 verweist auf den Alloc[0]-Eintrag 2491 für die Booteintragung. Der Alloc[0]-Eintrag 2491 enthält die Variable Offset 2492, die den Versatz der Region 2490 enthält. Die Region 2490 enthält die Booteintragung. Die Booteintragung enthält den Zeiger RootDirectoryPtr 2493, der auf den Alloc[0]-Eintrag 2411 verweist, der dem Verzeichnis ROOT entspricht. Der Alloc[0]-Eintrag 2411 enthält die Variable Offset 2412, die den Versatz der Region 2410 enthält. Die Region 2410 enthält den DirEntry für das Verzeichnis ROOT. Der PrimaryPtr 2413 des Verzeichnisses ROOT verweist auf den Alloc[0]-Eintrag 2421, der dem Verzeichnis DOS entspricht. Der Alloc[0]-Eintrag 2421 enthält die Variable Offset 2422, die den Versatz der Region 2420 enthält. Die Region 2420 enthält den DirEntry für das Verzeichnis DOS. Der Zeiger SiblingPtr 2423 des Verzeichnisses DOS verweist auf den Alloc[1]-Eintrag 2431 für das Verzeichnis WORD. Der Alloc[1]-Eintrag 2431 enthält die Variable Offset 2432, die den Versatz der Region 2430 enthält. Die Region 2430 enthält den DirEntry für das Verzeichnis WORD. Der Zeiger SiblingPtr 2433 des Verzeichnisses WORD verweist auf den Alloc[1]-Eintrag 2451 für die Datei AUTOEXEC.BAT. Der Alloc[1]-Eintrag 2441 enthält die Variable Offset 2442, die den Versatz der Region 2440 enthält. Die Region 2440 enthält den FileEntry für die Datei AUTOEXEC.BAT. Der Zeiger SiblingPtr 2443 für die Datei AUTOEXEC.BAT verweist auf den Alloc[1]-Eintrag 2453 für die Datei COMMAND.COM. Der Alloc[1]-Eintrag 2451 enthält die Variable Offset 2452, die den Versatz der Region 2450 enthält. Die Region 2450 enthält den FileEntry für die Datei COMMAND.COM. Der SiblingPtr 2453 ist auf FNULL gesetzt, um das Ende der Verbundliste anzuzeigen.
Das Dateisystem ermöglicht, dass Verzeichnisse hinzugefügt und gelöscht werden, und dass Dateien erzeugt, erweitert und geändert werden. 4 zeigt ein Flussdiagramm für diejenige Routine, die ein Verzeichnis zu einem FEProm hinzufügt. Die Eingabeparameter für diese Routine sind der vollständige Pfadnamen des neuen Verzeichnisses und Eigenschaftsdaten (attribute data) für das neue Verzeichnis. Die Routine setzt die Variable P derart, dass sie die Adresse des DirEntry für das Elternverzeichnis (parent directory) enthält. Sie setzt darüber hinaus die Variable C derart, dass sie die Adresse des DirEntry für das Kinderverzeichnis (child directory) enthält. So bedeutet beispielsweise der Pfadname „\P\C", dass ein Verzeichnis C erzeugt werden soll, das ein Unterverzeichnis von P darstellt, das wiederum ein Unterverzeichnis des Ausgangsverzeichnisses ist. 5 zeigt denjenigen Fall, in dem das Verzeichnis C das erste Unterverzeichnis von P ist, wohingegen 6 denjenigen Fall zeigt, dass das Verzeichnis C nicht das erste Unterverzeichnis von P ist. Gemäß 5 und 6 zeigen die durchgezogenen Linien die Verzeichnisstruktur, bevor das Verzeichnis C hinzugefügt wird, wohingegen die unterbrochenen Linien die Verzeichnisstruktur zeigen, nachdem das Verzeichnis C hinzugefügt worden ist.
In dem Block 401 von 4 lokalisiert das System das Verzeichnis P, indem es den Pfad ab dem Ausgangsverzeichnis verfolgt und die Variable P derart setzt, dass sie auf den DirEntry für das Verzeichnis P verweist. Bei der Lokalisierung des Verzeichnisses P folgt das System der Variable PrimaryPtr, es sei denn, es ist eine Ersetzung durch die Variable SecondaryPtr erfolgt. In dem Block 402 ordnet das System eine Region für den DirEntry für das Verzeichnis C zu. Das System ordnet die Region zu, indem es Prozeduren für den FEProm-Verwalter aufruft. Das System setzt die Variable C derart, dass sie auf die zugeordnete Region verweist. Im Folgenden wird der Handle, der von dem FEProm-Verwalter zurückgegeben wird, Zeiger auf die Regionen genannt. In dem Block 403 setzt das System die Variablen Name, Time, Date und Attributes in der neuzugeordneten Eintragung. Es setzt darüber hinaus die Variable Status derart, dass sie anzeigt, dass der neuzugeordnete Eintrag ein Verzeichniseintrag ist.
In den Blöcken 405 bis 412 verknüpft das System den neuen Verzeichniseintrag mit der alten Verzeichnisstruktur. In den Blöcken 406 bis 410 handhabt das System diejenige Situation, in der das neue Verzeichnis nicht das erste Unterverzeichnis von P ist. In den Blöcken 411 und 412 handhabt das System diejenige Situation, in der das neue Verzeichnis das erste Unterverzeichnis von P ist. In dem Block 405 hat oder hatte für den Fall, dass P→Status angibt, dass PrimaryPtr gültig ist, das Verzeichnis P ein Unterver zeichnis, woraufhin das System bei dem Block 406 weitermacht, wohingegen andernfalls das Verzeichnis kein Unterverzeichnis hatte, woraufhin das System bei dem Block 411 weitermacht. In dem Block 411 setzt das System P→PrimaryPtr derart, dass ein Verweis auf das Verzeichnis C erfolgt, wobei der neuzugeordnete Verzeichniseintrag eine Verknüpfung mit dem neuen Verzeichnis bewirkt. In dem Block 412 setzt das System P→Status, um anzuzeigen, dass die Variable PrimaryPtr gültig ist, woraufhin die Routine beendet ist.
In dem Block 406 setzt das System die Variable next_ptr gleich P→PrimaryPtr. Die Variable next_ptr enthält den Zeiger auf das nächste Verzeichnis in der Verbundliste Sibling-Unterverzeichnisse. In dem Block 407 macht das System für den Fall, dass der Zustand der Eintragung, auf die next_ptr verweist, anzeigt, dass SiblingPtr gültig ist, bei dem Block 408 weiter, wohingegen andernfalls das Ende der Verbundliste von Siblings erreicht wurde, und das System bei dem Block 409 weitermacht. In dem Block 408 setzt das System next_ptr gleich SiblingPtr derjenigen Eintragung, auf die next_ptr verweist, woraufhin ein Verrücken von next_ptr derart erfolgt, dass ein Verweis auf das nächste Verzeichnis in der Verbundliste vorliegt, woraufhin das System bei dem Block 407 weitermacht, um zu bestimmen, ob das Ende der Verbundliste erreicht worden ist. Bei der Suche nach dem Ende der Verbundliste von Siblings folgt das System der Variable SiblingPtr. In dem Block 409 setzt das System SiblingPtr derjenigen Eintragung, auf die next_ptr verweist, gleich dem Zeiger auf DirEntry für das Verzeichnis C. In dem Block 410 setzt das System den Zustand derjenigen Eintragung, auf die next_ptr verweist, um anzuzeigen, dass SiblingPtr in demjenigen Eintrag, der auf den neuzugeordneten Verzeichniseintrag verweist, gültig ist, woraufhin die Routine beendet ist.
7 zeigt ein Flussdiagramm der Routine, die eine FileEntry-Eintragung zu dem Dateisystem für eine neue Datei hinzufügt. Da FileEntry-Eintragungen einfache Blattknoten des hierarchischen baumartig strukturierten Dateisystems sind, ähnelt die Routine, die die FileEntry-Eintragungen hinzufügt, stark der Routine für die DirEntry-Eintragungen, stellt also ein Add_Directory dar, was in 4 gezeigt ist. Der merkliche Unterschied besteht dann, dass die Variable Status derart gesetzt wird, dass sie anzeigt, dass der Eintrag eine Datei ist (Block 803).
8 zeigt ein Flussdiagramm derjenigen Routine, die Daten an das Ende einer Datei anfügt. An diese Routine werden der vollständige Pfadname, die zu schreibenden Daten und die Anzahl der zu schreibenden Bytes übergeben. 9 zeigt einen Beispielsauf bau für die Verzeichnisstruktur, die die Datei „\L.DAT" enthält, die erweitert werden soll. Die durchgezogenen Linien zeigen die Struktur, bevor die Datei erweitert worden ist, während die unterbrochenen Linien die Struktur zeigen, nachdem die Datei erweitert worden ist. Anfangs enthält die Datei L.DAT die FileEntry-Eintragung 1101, die FileInfo-Eintragung 1102 und den damit verknüpften Extent 1103. Die unterbrochenen Linien zeigen die FileInfo-Eintragung 1104 mit denjenigen Daten, die der Datei in dem Extent D2 2105 hinzugefügt werden sollen.
Gemäß 8 ordnet das System in dem Block 1001 eine Region für eine neue FileEntry-Eintragung in dem FEProm zu und setzt die Variable FI derart, dass sie auf jene Eintragung verweist. In dem Block 1002 ordnet das System eine Region für den Datenextent zu und setzt die Variable D derart, dass sie auf den Extent verweist. In dem Block 1003 schreibt das System die Daten in den zugeordneten Block. In dem Block 1004 setzt das System die Variablen Attributes, Time und Date in dem zugeordneten FileInfo-Eintrag. In dem Block 1005 setzt das System Fi→ExtentPtr auf den Handle des zugeordneten Extents. In dem Block 1005A setzt das System FI→ExtentLen, damit die Länge des Extents erhalten bleibt. In dem Block 1005B setzt das System FI→Status to Exists, ATDRecent, FileInfo und ExtentPtrValid. In dem Block 1006 lokalisiert das System die FileEntry-Eintragung für die zu erweiternde Datei und setzt FI auf die Adresse jener Eintragung. In einem bevorzugten Ausführungsbeispiel lokalisiert das System die FileEntry-Eintragung vor der Zuordnung des neuen Extents und der FileInfo-Eintragung, um sicherzustellen, dass die Datei existiert, bevor eine Zuordnung erfolgt ist.
In den Blöcken 1007 bis 1012 lokalisiert das System die letzte FileInfo-Eintragung (sofern eine solche existiert) für die zu erweiternde Datei. Das System folgt PrimaryPtr oder SecondaryPtr der FileEntry-Eintragung und der FileInfo-Eintragungen. Ein gültiger SecondaryPtr zeigt an, dass die Datei, auf die PrimaryPtr verweist, durch Daten in derjenigen Eintragung ersetzt worden ist, auf die SecondaryPtr verweist. In dem Block 1007 setzt das System den Zeiger next_ptr gleich dem Zeiger auf die FileEntry-Eintragung. In dem Block 1008A setzt das System den Zeiger prev_ptr gleich next_ptr. Ist die letzte FileInfo-Eintraung in der Datei lokalisiert, so enthält der Zeiger prev_ptr den Zeiger auf jene Eintragung. In dem Block 1009 werden für den Fall, dass der Zustand derjenigen Eintragung, auf die next_ptr verweist, angibt, dass SecondaryPtr gültig ist, die Daten in der Eintragung, auf die next_ptr verweist, ersetzt, woraufhin das System bei dem Block 1011 weitermacht, wohingegen es andernfalls bei dem Block 1010 weitermacht. In dem Block 1010 setzt das System next_ptr gleich PrimaryPtr derjenigen Eintragung, auf die next_ptr verweist, damit der Zeiger auf die nächste Eintragung in der Verbundliste verweist, und macht bei dem Block 1012 weiter. In dem Block 1011 setzt das System next_ptr gleich SecondaryPtr derjenigen Eintragung, auf die next_ptr verweist, damit der Zeiger auf die nächste Eintragung in der Verbundliste verweist, und macht bei dem Block 1008A weiter. In dem Block 1012 ist, wenn next_ptr gültig ist, das Ende der Verbundliste erreicht, und das System macht bei dem Block 1013 weiter, wohingegen es andernfalls bei dem Block 1008A weitermacht, um die nächste Eintragung in der Verbundliste zu verarbeiten. In dem Block 1013 setzt das System PrimaryPtr derjenigen Eintragung, auf die prev_ptr verweist, gleich dem Zeiger auf FI, um die Erweiterung der Datei zu bewirken. In dem Block 1014 setzt das System den Zustand derjenigen Eintragung, auf die prev_ptr verweist, gleich PrimaryPtrValid, woraufhin die Routine beendet ist.
10 zeigt ein Flussdiagramm für diejenige Routine, nämlich Update_File, die die Daten in einer Datei aktualisiert. Die Parameter für diese Routine sind R, die Adresse des FileInfo_Blocks, die den damit verknüpften geänderte Extent enthalten soll; extent offset, der Versatz in den Extent für die neuen Daten; new_data, die neuen Daten; und data_length, die Länge der neuen Daten. Da der FEProm effektiv eine Festwertvorrichtung ist – zumindest bis ein Block gelöscht ist –, kann eine Region, in der Daten gespeichert werden, nicht neu beschrieben werden, wenn eine Aktualisierung an einer Datei vorgenommen wird. Bei einem bevorzugten Ausführungsbeispiel werden die aktualisierten Daten in eine andere Region des FEProm geschrieben, was nachstehend noch beschrieben wird.
11 zeigt einen typischen Teil der Verbundliste der FileInfo-Eintragung für eine Datei. Die Update_File-Routine ersetzt die Daten, die durch den schraffierten Bereich 1301 dargestellt sind. 12 zeigt die Struktur der Verbundliste, nachdem die geänderten Dateien in den FEProm geschrieben worden sind. Drei FileInfo-Eintragungen R1 1411, R2 1412 und R3 1413 sind in die Verbundliste aufgenommen. Der gesamte Extent wird nicht neugeschrieben, sondern es wird nur derjenige Teil neugeschrieben, der tatsächlich geändert worden ist. Die Routine unterteilt den Extent in drei Sektionen, D1 1401, D2 1402 und D3 1403. Die Sektionen D1 1401 und D3 1403 enthalten Daten, die vor der Aktualisierung nicht geändert werden, wohingegen die Sektion D2 1402 Daten enthält, die geändert werden. Jede Sektion umfasst eine entsprechende FileInfo-Eintragung. Die FileInfo-Eintragungen R1 1411, R2 1412 und R3 1413 sind durch ihre PrimaryPtr-Felder verknüpft. Darüber hinaus ist das ExtentPtr-Feld in R1 1411 und R3 1413 derart gesetzt, dass es auf ihre entsprechenden Extent-Sektionen verweist, und die ExtentLen-Felder sind gesetzt. Eine neuer Extent wird für die neuen Daten zugeordnet, die der Sektion „neues D2 1402" entsprechen, auf die die Eintragung R2 1412 verweist. Die SecondaryPtr der Eintragung R 1410 verweist auf das FileInfo R1 1411, um anzuzeigen, dass der PrimaryPtr von R 1410 ersetzt ist. Der PrimaryPtr der FileInfo-Eintragung R3 1413 wird auf einen Wert gesetzt, der in dem PrimaryPtr der FileInfo-Eintragung R 1410 enthalten ist, um die Verknüpfung zu vervollständigen.
Die Update_File-Routine hängt davon ab, ob ausreichend Platz in dem Block vorhanden ist, der den Extent enthält, um drei neue Alloc-Einträge hinzuzufügen. Diese drei Alloc-Einträge definieren den Extent in den drei Regionen neu, anstatt dass sie eine Neudefinition in einer Region vornehmen. Ist nicht ausreichend Platz vorhanden, so erzeugt gegebenenfalls eine Rückgewinnung des Blockes ausreichend freien Platz, woraufhin die Update_File-Routine aufgerufen werden kann. Ist jedoch nicht ausreichend Platz vorhanden, so werden die Daten in dem Extent zu einem neuen Extent bewegt. Sind die Daten bewegt worden, so können die neuen Daten in die alten Daten integriert und in eine Region in dem neuen Block mit nur einer FileInfo-Eintragung geschrieben werden. Die Region in dem alten Block wird freigegeben. Bei dem bevorzugten Ausführungsbeispiel unterstützt der FEProm-Verwalter das Hinzufügen von Alloc-Einträgen derart, dass diese auf Teile einer existierenden Region verweisen. Das Beispiel von 12 verwendet drei neue Alloc-Einträge, die dem Block hinzugefügt worden sind, was den neudefinierten Regionen entspricht, die mit D1, D2 und D3 verknüpft sind. Der Alloc-Eintrag für D2 würde dann freigegeben werden, wohingegen die Alloc-Einträge für D1 und D3 zugeordnet würden. Der Zustand des alten Alloc-Eintrages, der der Region mit den Sektionen D1, D2 und D3 entspricht, würde derart gesetzt, dass angezeigt wird, dass eine Ersetzung stattgefunden hat. Der „ersetzt"-Zustand gibt an, dass der Alloc-Eintrag im Wesentlichen ohne entsprechende Region freigegeben worden ist.
In dem Block 1201 von 10 ordnet das System drei Regionen für die FileInfo-Eintragungen zu und setzt die Variablen R1, R2 und R3 derart, dass sie die Adressen der Regionen enthalten. In dem Block 1202 setzt das System für den Fall, dass R→Status ATDRecent anzeigt, R1→Time, R1→Date und R1→Attributes auf die Werte in R und setzt R1→Status nach ATDRecent, wohingegen das System andernfalls diese Felder auf FNULL lässt. Bei einem bevorzugten Ausführungsbeispiel unterstützt der FEProm-Verwalter das Setzen aller Alloc-Einträge auf „ersetzt" und das Zuordnen der Einträge für eine existierende Region. In dem Block 1203 ordnet das System eine Region für die neuen Daten zu und setzt R2NewData auf die Adresse der Region. In dem Block 1204 ordnet das System drei Alloc-Einträge zu. Die Einträge werden initialisiert, damit sie auf D1, D2 und D3 verweisen. Der Status des Alloc-Eintrages, der auf die Regionen mit D1, D2 und D3 verweist, wird auf „ersetzt" gesetzt. In dem Block 1205 schreibt das System new data in die neue Region, die mittels R2NewData adressiert ist. In den Blöcken 1206 bis 1208A setzt das System die Daten in der FileInfo-Eintragung R2. In dem Block 1206 setzt das System R2→ExtentPtr gleich dem Zeiger auf die Region für die neuen Daten. In dem Block 1207 setzt das System R2→ExtentLen gleich der Länge der neuen Region. In dem Block 1208 setzt das System R2→PrimaryPtr auf den Zeiger nach R3. In dem Block 1208A setzt das System R2→Status, um anzuzeigen, dass ExtentPtr und PrimaryPtr gültig sind.
In den Blöcken 1209 bis 1211A setzt das System die Daten in der FileInfo-Eintragung R3. In dem Block 1209 setzt das System R3→ExtentPtr gleich dem Zeiger auf die D3-Region. In dem Block 1210 setzt das System R3→ExtentLen gleich der Länge der D3-Region. In dem Block 1211 setzt das System R3→PrimaryPtr gleich R→PrimaryPtr. In dem Block 1211A setzt das System R3→Status, um anzuzeigen, dass ExtentPtr und PrimaryPtr gültig sind.
In den Blöcken 1212 bis 1214A setzt das System die Daten in der FileInfo-Eintragung R1. In dem Block 1212 setzt das System R1→ExtentPtr gleich dem Zeiger auf die D1-Region. In dem Block 1213 setzt das System R1→ExtentLen gleich der Länge der D3-Region. In dem Block 1214 setzt das System R1→PrimaryPtr auf den Zeiger auf R2. In dem Block 1214A setzt das System R1→Status, um anzuzeigen, dass ExtentPtr und PrimaryPtr gültig sind.
In dem Block 1215 setzt das System R→SecondaryPtr gleich dem Zeiger auf R1. In dem Block 1216 setzt das System R→Status, um anzugeben, dass SecondaryPtr gültig ist. Damit ist die Routine beendet.
13 und 14 zeigen die FileInfo-Liste für einige Spezialfälle von Dateiaktualisierungen. Die Routine zur Verarbeitung dieser Spezialfälle ist eine Teilmenge der Routine, die zur Verarbeitung im allgemeinen Fall zum Einsatz kommt, nämlich die Routine Update File gemäß 10. Gemäß 13 werden Daten, beginnend mit dem Anfang eines Extents, aktualisiert. Die Sektion D1 1501 enthält die Daten am Anfang des Extents, die aktualisiert werden sollen, und die Sektion D2 1502 enthält die Daten am Ende des Extents, die nicht aktualisiert werden sollen. Es werden nur die neuen FileInfo- Eintragungen benötigt. Die erste FileInfo-Eintragung R1 1511 verweist auf die neuen Daten 1503, wohingegen die zweite FileInfo-Eintragung R2 1512 auf die alten Daten in der Sektion D2 1502 verweist. Eine ähnliche Situation tritt auf, wenn die Daten, die an einer Extentgrenze enden, aktualisiert werden, was in 14 dargestellt ist. Wie im allgemeinen Fall einer Dateiaktualisierung wird die alte Region, die D1 und D2 enthält, in zwei Regionen unterteilt, indem die beiden neuen Zuordnungstabelleneinträge in dem Block unterteilt werden, der die alte Region enthält. Ist nicht ausreichend Platz für die neuen Einträge vorhanden, so werden die nicht geänderten Daten in den neuen Block bewegt.
15 zeigt eine Verbundliste für FileInfo-Eintragungen, wenn die aktualisierten Daten Extentgrenzen überschreiten.
16 zeigt ein Flussdiagramm einer Routine, die ein Verzeichnis aus dem FEProm löscht. Die Routine zum Löschen einer Datei ist ähnlich, außer dass die verknüpften FileInfo-Eintragungen freigegeben sind. Diese Routine setzt den Zustand von DirEntry derart, dass „gelöscht" angegeben wird. In dem Block 1801 lokalisiert das System das zu löschende Verzeichnis und setzt die Variable Pointer D derart, dass sie die Adresse des Verzeichnisses enthält. In dem Block 1802 setzt das System D→Status, um anzuzeigen, dass das Verzeichnis gelöscht ist.
Der Name eines Verzeichnisses oder einer Datei wird geändert, indem ein neuer DirEntry beziehungsweise ein neuer FileEntry zugeordnet werden, woraufhin der SecondaryPtr des alten Eintrages derart gesetzt wird, dass er auf den neuen Eintrag zeigt. 18 zeigt den Dateieintrag für „D.DAT" mit durchgezogenen Linien, wohingegen Änderungen bei einer Änderung des Namens nach „B.DAT" mit unterbrochenen Linien dargestellt sind. Der neue Eintrag verweist auf die Verbundliste der FileInfo-Einträge, die Verzeichnisstruktur und die mit dem alten Eintrag verknüpften Extents.
17 ist ein Flussdiagramm einer bevorzugten Unterroutine, die die Änderung eines Dateinamens implementiert. Die Unterroutine zur Änderung eines Dateinamens ist ähnlich, außer dass keine verknüpften Extents vorhanden sind. Die Eingabeparameter für diese Routine sind der Pfadname der Datei und der neue Dateiname. In dem Block 1901 durchsucht das System die Verzeichnisstruktur, lokalisiert diejenige Datei, deren Name geändert werden soll, und setzt die Variable P derart, dass sie auf FileEntry verweist. Das System sucht nach dem letzten FileEntry in der Verbundliste der Einträge für die Datei. Eine Datei hat einen Eintrag für jede Namensänderung.
In dem Block 1904 ordnet das System eine Region für den neuen FileEntry zu und setzt die Variable derart, dass sie auf diese Region verweist. In dem Block 1905 setzt das System C→Name gleich dem neuen Dateinamen und setzt C→Attributes, C→Date, C→Time, und setzt C→Status auf Basis des ersetzten Dateieintrages auf ATDRecent. In dem Block 1906 setzt das System C→SiblingPtr gleich P→SiblingPtr, um den Eintrag in der Verzeichnishierarchie zu verknüpfen. In dem Block 1909 setzt das System C→PrimaryPtr gleich P→PrimaryPtr, um den neuen Eintrag mit der Liste von Extents zu verknüpfen. In dem Block 1909A setzt das System C→Status, um anzugeben, dass ExtentPtr und PrimaryPtr gültig sind. In dem Block 1910 setzt das System P→PrimaryPtr gleich dem Zeiger auf C. In dem Block 1910A setzt das System P→Status, um anzugeben, das SecondaryPtr gültig ist, wodurch die Ersetzung des alten Eintrages vollzogen ist, und die Routine endet.
19 zeigt ein Flussdiagramm einer Routine, die die Eigenschaftsdaten (attribute data) einer Datei ändert. Die Eigenschaftsdaten, die mit einer Datei verbunden sind, werden geändert, indem der erste FileEntry-Eintrag mit einem Zustand von ATDRecent ausgewählt wird, wobei die Attribute-, Date- und Time-Felder auf FNULL gesetzt werden. Existiert kein solches Feld, so wird ein neuer FileInfo-Eintrag erzeugt und ausgewählt. Das System setzt anschließend die Attribute-, Date- und Time-Felder in dem ausgewählten FileInfo-Eintrag. Der FileInfo-Eintrag, der bislang die aktuellsten Attribute-, Date- und Time-Daten gespeichert hat, wird auf den „ATDSuperseded"-Zustand gesetzt. Die Eingabeparameter sind der Pfadname und die Eigenschaftsdaten. In dem Block 2101 durchsucht das System die Verzeichnisstruktur, um die Datei zu lokalisieren, und setzt die Variable P derart, dass sie auf FileEntry verweist. In dem Block 2102 enthält FileEntry für den Fall, dass P→Status ATDRecent anzeigt, die aktuellsten Eigenschaftsdaten, woraufhin das System bei dem Block 2103 weitermacht, wohingegen es andernfalls bei dem Block 2104 weitermacht. In dem Block 2103 setzt das System die Variable X auf die Variable P und macht bei dem Block 2111 weiter. In dem Block 2104 setzt das System die Variable C gleich P→PrimaryPtr. In den Blöcken 2105 bis 2108 läuft das System bei der Suche nach dem FileInfo-Eintrag mit demjenigen Zustand, der die aktuellsten Eigenschaftsdaten anzeigt, um. In dem Block 2105 macht das System für den Fall, dass C→Status anzeigt, dass SecondaryPtr gültig ist, bei dem Block 2106 weiter, wohingegen es andernfalls bei dem Block 2107 weitermacht. Bei dem Block 2106 setzt das System die Variable C gleich C→SecondaryPtr, um auf den vorrangigen Eintrag zu verweisen, und kehrt zu dem Block 2105 zurück. In dem Block 2107 enthält der FileInfo-Eintrag für den Fall, dass C→Status ATDRecent angibt, die aktuellsten Eigenschaftsdaten, woraufhin das System bei dem Block 2109 weitermacht, wohingegen es andernfalls bei dem Block 2108 weitermacht. In dem Block 2108 setzt das System die Variable C gleich C→PrimaryPtr und kehrt zu dem Block 2105 zurück. In dem Block 2109 setzt das System die Variable X auf die Variable C und macht bei dem Block 2111 weiter.
In dem Block 2111 initialisiert das System die Variable Y auf die Variable X. Die Variable X verweist auf den Eintrag mit den aktuellsten Eigenschaftsdaten. In den Blöcken 2112 bis 2119 lokalisiert das System den nächsten Eintrag mit einem Zustand der aktuellsten Eigenschaftsdaten, gesetzt auf FNULLs. In dem Block 2112 macht das System für den Fall, dass Y→Status angibt, dass PrimaryPtr gültig ist, bei dem Block 2113 weiter, wohingegen andernfalls ein neuer Eintrag hinzugefügt wird, und das System bei dem Block 2120 weitermacht. In dem Block 2113 setzt das System die Variable Y gleich Y→PrimaryPtr. In dem Block 2114 macht das System für den Fall, dass Y→Status angibt, dass SecondaryPtr gültig ist, bei dem Block 2115 weiter, wohingegen es andernfalls bei dem Block 2116 weitermacht. In dem Block 2115 setzt das System die Variable Y gleich Y→SecondaryPtr und kehrt zu dem Block 2114 zurück. In dem Block 2116 macht das System für den Fall, dass Y→Status auf ATDRecent gesetzt ist, bei dem Block 2117 weiter, wohingegen es andernfalls zu dem Block 2112 zurückkehrt. In dem Block 2117 macht das System für den Fall, dass Y→Attribute, Y→Date und Y→Time gleich FNULL sind, bei dem Block 2118 weiter, wohingegen es andernfalls zu dem Block 2112 zurückkehrt. In dem Block 2118 setzt das System Y→Attribute, Y→Date und Y→Time auf die neuen Eigenschaftsdaten. In dem Block 2119 setzt das System X→Status gleich ATDSuperseded, woraufhin die Routine beendet ist.
In den Blöcken 2120 bis 2123 ordnet das System einen neuen FileInfo-Eintrag zu und initialisiert diesen. In dem Block 2120 ordnet das System einen neuen FileInfo-Eintrag zu und setzt die Variable Z derart, dass sie auf den neuen Eintrag verweist. In dem Block 2121 setzt das System Z→Attribute, Z→Date und Z→Time auf die neuen Eigenschaftsdaten, setzt Z→Status auf Exists, ATDRecent und FileInfo, setzt Z→ExtentPtr auf Y→ExtentPtr, und setzt Z→ExtentLen nach Y→ExtentLen. In dem Block 2122 setzt das System Y→SecondaryPtr gleich der Variable Z und Y→Status derart, dass angezeigt wird, dass SecondaryPtr gültig ist. In dem Block 2123 setzt das System X→Status gleich ATDSuperseded, um anzugeben, dass der Eintrag die aktuellen Eigenschaftsdaten nicht mehr enthält, woraufhin die Routine endet.

Claims

Verfahren zur Speicherverwaltung mittels einer Computer-Speicherverwaltungseinrichtung, um ein Dateisystem in einem blockweise löschbaren, flash-artig löschbaren, programmierbaren Festwertspeicher zu speichern, wobei der Speicher eine Vielzahl von Blöcken umfasst, die unabhängig gelöscht werden können, und das Verfahren die folgenden Schritte umfasst: Speichern von Block-Header-Informationen in jedem Block, wobei die Block-Header-Informationen einen Block-Status, der den Zuordnungsstatus des Blocks anzeigt, und einen Block-Lösch-Zählwert enthalten, der anzeigt, wie oft der Block gelöscht worden ist; Speichern einer Zuordnungstabelle in jedem Block, wobei die Zuordnungstabelle Einträge enthält, die Abschnitten eines Datenspeicherbereiches des Blocks entsprechen und jeder Zuordnungstabellen-Eintrag Daten enthält, die den entsprechenden Abschnitt des Datenspeicherbereiches beschreiben; Identifizieren eines Blocks auf Basis des entsprechenden Lösch-Zählwerts, um den Block für die Speicherung von Daten des Dateisystems zuzuordnen, wenn der Block ausreichend Raum zum Speichern der Daten in dem Datenspeicherbereich bietet; und Speichern der Daten in dem Datenspeicherbereich in dem Block auf Basis der entsprechenden Zuordnungstabelle.
Verfahren nach Anspruch 1, wobei die Block-Header-Informationen des Weiteren eine logische Block-Nummer enthalten, die einen spezifischen Block von Daten identifiziert.
Verfahren nach Anspruch 1 oder 2, wobei die Zuordnungstabellen-Einträge Einträge umfassen, die einen Zeiger auf den entsprechenden Abschnitt des Datenspeicherbereiches, eine Länge, die die Länge des entsprechenden Abschnitts des Datenspeicherbereiches anzeigt, und einen Status enthalten, der den Status des Eintrags anzeigt.
Verfahren nach einem der Ansprüche 1–3, das des Weiteren den Schritt des Rückgewinnens von freigegebenem Platz in dem Speicher umfasst, wobei der Schritt die folgenden Teilschritte umfasst: Identifizieren von Datenregionen in einem rückzugewinnenden Block als freigegeben oder zugeordnet; Löschen eines Ersatzblocks; und Kopieren zugeordneter Datenregionen aus dem rückzugewinnenden Block in den Ersatzblock, so dass ein Speicherbereich, der der freigegebenen Datenregion entspricht, zur Zuordnung rückgewonnen wird.
Verfahren nach Anspruch 4, wobei die zugeordneten Datenregionen in benachbarte Speicherplätze in dem Ersatzblock kopiert werden.
Verfahren nach einem der Ansprüche 1–5, das des Weiteren den Schritt des Adressierens einer Datenregion in dem Speicher umfasst, wobei jeder Block eine physikalische Block-Nummer hat, die Zuordnungstabelle Einträge hat, die einen Versatz einer Datenregion in dem Block anzeigen und die einen Eintrags-Index haben, wobei der Schritt des Adressierens die folgenden Teilschritte umfasst: Speichern einer logischen Block-Nummer in jedem Block; Identifizieren einer Datenregion anhand der logischen Block-Nummer und eines Zuordnungstabellen-Eintrags-Index; und Erzeugen einer Adresse für die identifizierte Datenregion auf Basis der logischen Block-Nummer und des Zuordnungstabellen-Eintrags-Index.
Verfahren nach Anspruch 6, wobei der Schritt des Erzeugens einer Adresse die folgenden Schritte enthält: Bestimmen der physikalischen Block-Nummer aus der logischen Block-Nummer, wobei jeder Block eine entsprechende Startadresse hat; Abrufen des Versatzes aus dem Zuordnungstabellen-Eintrag in der bestimmten physikalischen Block-Nummer, die mit dem Zuordnungstabellen-Eintrags-Index indexiert wird; und Hinzufügen des abgerufenen Versatzes zu der Startadresse des Blocks mit der bestimmten physikalischen Block-Nummer, um die Adresse der identifizierten Datenregion zu erzeugen.
Verfahren nach einem der Ansprüche 1–5, das des Weiteren den Schritt des Identifizierens eines Blocks in dem Speicher umfasst, wobei jeder Block eine physikalische Block-Nummer hat und der Schritt des Identifizierens die folgenden Teilschritte umfasst: Speichern einer logischen Block-Nummer in jedem Block; Erzeugen einer Abbildung von jeder logischen Block-Nummer auf der physikalischen Block-Nummer, an der die logische Block-Nummer gespeichert ist; Empfangen einer logischen Block-Nummer; und Umsetzen der empfangenen logischen Block-Nummer in eine physikalische Block-Nummer unter Verwendung der erzeugten Abbildung.
Verfahren nach Anspruch 8, das beim Rückgewinnen eines Blocks den Schritt des Kopierens der logischen Block-Nummer aus dem rückzugewinnenden Block in den rückgewonnenen Block einschließt.
Verfahren nach einem der Ansprüche 1–9, das des Weiteren den Schritt des Führens eines Lösch-Zählwertes eines Blocks in dem Speicher umfasst, wobei der Schritt die folgenden Teilschritte umfasst: Speichern eines Lösch-Zählwertes in jedem Block, wobei der Lösch-Zählwert anzeigt, wie oft der Block gelöscht worden ist; Kopieren eines ersten Blocks in einen zweiten Block unter Beibehaltung des Lösch-Zählwertes des zweiten Blocks; und beim Löschen eines Blocks Heraufsetzen des Lösch-Zählwertes vor Löschung und Speichern des heraufgesetzten Lösch-Zählwertes in dem gelöschten Block.
Verfahren nach einem der Ansprüche 1–10, das des Weiteren den Schritt des Ausgleichens von Block-Löschungen in dem Speicher umfasst, wobei der Schritt die folgenden Teilschritte umfasst: Identifizieren eines ersten Blocks, der gelöscht worden ist; Identifizieren eines zweiten Blocks, der weniger häufig gelöscht worden ist als der erste Block; und Austauschen von Daten in dem ersten Block gegen Daten in dem zweiten Block.
Verfahren nach einem der Ansprüche 1–11, das des Weiteren den Schritt des Aktualisierens von in dem Speicher gespeicherten Daten durch neue Daten umfasst, wobei der Speicher Sätze von Daten enthält und jeder Satz einen sekundären Zeiger hat, der anfänglich einen vordefinierten Wert hat, und der Schritt des Aktualisierens die folgenden Teilschritte umfasst: Auffinden eines Satzes, der zu aktualisierende Daten enthält; Zuordnen eines Satzes, der zu aktualisierende Daten enthalten soll; Schreiben der neuen Daten in den zugeordneten Satz; und Setzen des sekundären Zeigers in dem aufgefunden Satz so, dass er auf den zugeordneten Satz zeigt, um anzuzeigen, dass die neuen Daten in dem zugeordneten Satz eine Aktualisierung der Daten in dem aufgefundenen Satz darstellen.
Verfahren nach Anspruch 12, wobei der Schritt des Setzens des sekundären Zeigers das Setzen eines Flags in dem aufgefundenen Satz einschließt, um anzuzeigen, dass der sekundäre Zeiger gegenüber dem vordefinierten Wert verändert worden ist.
Verfahren nach einem der Ansprüche 1–13, das des Weiteren den Schritt des Durchführens von Fehlerkorrektur in einem Computersystem mit einer einmal beschreibbaren und mehrmals lesbaren Speichervorrichtung umfasst, wobei die Speichervorrichtung einen oder mehrere logische Blöcke hat und der Schritt die folgenden Teilschritte umfasst: a) Definieren einer Datenregion für jeden Block, wobei die Datenregion logisch in Datenregionsbereiche zum Speichern von Daten geteilt ist; b) Definieren einer Blockstruktur für jeden Block, wobei die Blockstruktur einen Header und eine Zuordnungstabelle hat und der Header blockspezifische Informationen enthält, die Zuordnungstabelle Einträge hat, die Datenregionsbereichen entsprechen und Informationen enthalten, die sich auf die entsprechenden Datenregionsgebiete beziehen; c) Zuordnen eines Zuordnungstabellen-Eintrags; d) Zuordnen eines Datenregionsbereiches zum Speichern von Daten; e) Schreiben von Daten bezüglich des zugeordneten Datenregionsbereiches in den zugeordneten Zuordnungstabellen-Eintrag; f) Schreiben von Daten in den zugeordneten Datenregionsbereich; g) Erfassen eines Fehlers beim Schreiben in den Datenregionsbereich; und h) beim Erfassen des Fehlers Setzen des Zuordnungstabellen-Eintrags auf einen freigegebenen Status, und Wiederholen der Schritte c), d), e) und f), bis kein Fehler beim Schreiben von Daten in den Datengebietsbereich erfasst wird.
Verfahren nach Anspruch 14, wobei der Schritt g) die folgenden Teilschritte enthält: Setzen des zugeordneten Zuordnungstabellen-Eintrags auf einen zugeordneten Status; und Erfassen eines Fehlers beim Setzen des zugeordneten Zuordnungstabellen-Eintrags auf den zugeordneten Status.
Verfahren nach einem der Ansprüche 1–13, das des Weiteren den Schritt des Durchführens von Fehlerkorrektur in einem Computersystem mit einer einmal beschreibbaren und mehrmals lesbaren Speichervorrichtung umfasst, wobei die Speichervorrichtung einen oder mehrere logische Blöcke hat, die gelöscht werden können, und der Schritt die folgenden Teilschritte umfasst: Definieren einer Block-Header-Datenstruktur für einen Block, wobei die Block-Header-Datenstruktur den Status des Blocks enthält; Schreiben von Daten in die Block-Header-Datenstruktur; und beim Erfassen eines Fehlers beim Schreiben in die Block-Header-Datenstruktur Setzen des Blocks auf einen Status in der Warteschlange zum Löschen, so dass der Block nicht zum Speichern von Daten verwendet wird, bis er gelöscht ist.
Verfahren nach einem der Ansprüche 1–13, das des Weiteren den Schritt des Durchführens von Fehlerkorrektur in einem Computersystem mit einer einmal beschreibbaren und mehrmals lesbaren Speichervorrichtung umfasst, wobei die Speichervorrichtung einen oder mehrere logische Blöcke hat, die gelöscht werden können, und die Schritte die folgenden Teilschritte umfassen: Definieren einer Block-Header-Datenstruktur für einen Block, wobei die Block-Header-Datenstruktur den Status des Blocks enthält; Löschen des Blocks; und beim Erfassen eines Fehlers beim Löschen des Blocks, Setzen des Blocks auf einen Ruhestatus, so dass der Block nicht zum Speichern von Daten verwendet wird.
Verfahren nach einem der Ansprüche 1–17, das den Schritt des Betreibens einer Computer-Speicherverwaltungseinrichtung umfasst, die angibt, dass eine angegebene Speichervorrichtung nicht blockweise gelöscht werden kann, wobei die Computer-Speicherverwaltungseinrichtung dazu dient, eine blockweise löschbare, einmal beschreibbare und mehrmals lesbare Speichervorrichtung zu verwalten, und die Speicherverwaltungseinrichtung einen Zählwert von Ersatzblöcken führt, wobei die Speicherverwaltungseinrichtung Daten in einem angegebenen Block komprimiert, indem sie die Daten in einen Ersatzblock kopiert, den angegebenen Block löscht und den angegebenen Block als einen Ersatzblock setzt, wobei das Verfahren den Schritt des Setzens des Zählwertes von Ersatzblöcken auf Null umfasst, so dass die Speicherverwaltungseinrichtung Daten in einem Block nicht komprimiert, da in der angegebenen Speichervorrichtung kein Ersatzblock verfügbar ist.
Verfahren nach einem der Ansprüche 1–17, das den Schritt des Betreibens einer Computer-Speicherverwaltungseinrichtung umfasst, die angibt, dass eine angegebene einmal beschreibbare und mehrmals lesbare Speichervorrichtung nicht blockweise gelöscht werden kann, wobei die Speicherverwaltungseinrichtung dazu dient, eine blockweise löschbare, einmal beschreibbare und mehrmals lesbare Speichervorrichtung zu verwalten, und die Speicherverwaltungseinrichtung einen Zählwert von Ersatzblöcken führt und ein Ersatzblock zum Komprimieren von Daten in einem Block dient, und das Verfahren den Schritt des Setzens des Zählwerts von Ersatzblöcken auf 0 umfasst, um die Löschung eines Blocks durch die Speicherverwaltungseinrichtung zu verhindern.
Computerlesbares Medium, auf dem durch Computer ausführbare Befehle für eine Computer-Speicherverwaltungseinrichtung zum Ausführen von Schritten der Speicherverwaltung zum Speichern eines Dateisystems in einem blockweise löschbaren, flash-artig löschbaren, programmierbaren Festwertspeicher gespeichert sind, der eine Vielzahl von Blöcken umfasst, die unabhängig gelöscht werden können, wobei die Schritte umfassen: Speichern von Block-Header-Informationen in jedem Block, wobei die Block-Header-Informationen einen Block-Status, den Zuordnungsstatus des Blocks und einen Block-Lösch-Zählwert enthalten, der anzeigt, wie oft der Block gelöscht worden ist; Speichern einer Zuordnungstabelle in jedem Block, wobei die Zuordnungstabelle Einträge enthält, die Abschnitten eines Datenspeicherbereichs des Blocks entsprechen, und jeder Zuordnungstabellen-Eintrag Daten enthält, die den entsprechenden Abschnitt des Datenspeicherbereiches beschreiben; Identifizieren eines Blocks auf Basis des entsprechenden Lösch-Zählwertes, um den Block für die Speicherung von Daten des Dateisystems zuzuordnen, wenn der Block ausreichend Platz zum Speichern der Daten in dem Datenspeicherbereich bietet; und Speichern der Daten in dem Datenspeicherbereich in dem Block auf Basis der entsprechenden Zuordnungstabelle.
Computerlesbares Medium nach Anspruch 20, das durch Computer ausführbare Befehle zum Durchführen der Verfahren nach den Ansprüchen 2–19 aufweist.