POSIX-kompatibles Dateisystem, Verfahren zum Erzeugen einer Dateiliste und Speichervorrichtung

Die Erfindung betrifft ein POSIX-kompatibles Dateisystem umfassend wenigstens ein Verzeichnis und eine Mehrzahl von in dem Verzeichnis gespeicherten Dateien. Darüber hinaus betrifft die Erfindung ein Verfahren zum Erzeugen einer Dateiliste mit Dateien eines POSIX-kompatiblen Dateisystems, eine Verwendung von erweiterten Attributen sowie eine

Speichervorrichtung .

POSIX-kompatible Dateisysteme sind aus dem Stand der Technik bekannt. Insbesondere basieren die meisten bekannten Linux- Distributoren auf verschiedenen, POSIX-kompatiblen

Dateisystemen, wie beispielsweise ext2 und ext3.

Grundsätzlich weisen derartige Dateisysteme eine

verhältnismäßig große Flexibilität auf und sind zur Ablage einer großen Anzahl von Dateien geeignet.

POSIX-kompatible Dateisysteme verwalten physikalische

Datenträger unter Verwendung so genannter Inodes, wobei die Inodes Metadaten über auf dem Datenträger gespeicherte

Informationen enthalten. Beispiele solcher Metadaten sind

Zugriffsrechte sowie jeweils ein Erstellungs- , Änderungs- und Lesedatum von in dem Dateisystem gespeicherten Dateien.

Derartige Informationen werden unter anderem von Sicherungsund Archivierungslösungen zum Verwalten der in dem

Dateisystem gespeicherten Dateien verwendet.

Die Auswertung und Aktualisierung solcher und ähnlicher Metadaten kann jedoch insbesondere bei sehr umfangreichen Dateisystemen, wie sie beispielsweise in sogenannten „Big Data"-Anwendungen vorkommen, auch zu Problemen führen.

Es ist eine Aufgabe der vorliegenden Erfindung, ein POSIX- kompatibles Dateisystem sowie Verfahren und Vorrichtungen zu seiner Erstellung und Nutzung zu beschreiben, die eine gegenüber bekannten Implementierungen verbesserte

Leistungsfähigkeit aufweisen. Insbesondere soll eine Anzahl von I /O-Zugriffen auf einen Massenspeicher beim Durchsuchen von auf dem Massenspeicher gespeicherten Dateien reduziert werden. Die beschriebenen Vorrichtungen und Verfahren sollen sich insbesondere zur Verwendung in Sicherungs- und

Archivierungssystemen eignen, die hunderttausende bis

Milliarden von Dateien verwalten.

Gemäß einem ersten Aspekt der Erfindung wird ein POSIX- kompatibles Dateisystem umfassend wenigstens ein Verzeichnis und eine Mehrzahl von in dem Verzeichnis gespeicherten

Dateien offenbart. Jeder Datei ist ein Inode mit Metadaten über die jeweilige Datei zugeordnet, und das Verzeichnis umfasst eine Zuordnung zwischen Dateinamen der Mehrzahl von Dateien und dem jeweils einer Datei zugeordneten Inode. Dabei umfassen die Metadaten über die jeweilige Datei wenigstens den Dateinamen der zugeordneten Datei und/oder Informationen über das wenigstens eine Verzeichnis.

Ein derartiges Dateisystem erlaubt die Bestimmung von

Dateinamen und/oder Pfadangaben allein auf Grundlage von in den Inodes gespeicherten Metadaten. Beispielsweise erlaubt ein derartiges Dateisystem basierend auf einer Kombination von Namens und Verzeichnisinformation der Metadaten der

Inodes eine Dateiliste zu erstellen, ohne dass auf sonstige Datenblöcke des Dateisystems, insbesondere Verzeichnisse, zugegriffen werden muss. Die Speicherung von entweder nur Verzeichnis oder Namensinformation erlaub zumindest eine Vorfilterung von zugehörigen Dateiobjekten, so dass auf weniger andere Datenblöcke zugegriffen werden muss. Durch die Lokalisierung von Namens- und/oder Verzeichnisinformationen in den Inodes können I/O-Zugriffe auf sonstige Teile eines Massenspeichers vermieden oder reduziert werden. Somit können Verwaltungsaufgaben, die auf entsprechenden Informationen und Metadaten der Inodes beruhen, beschleunigt werden.

Gemäß einer ersten Ausgestaltung umfasst die Information über das wenigstens eine Verzeichnis einen Verweis auf einen dem Verzeichnis zugeordneten Inode. Durch Vorsehung eines

Verweises auf einen Inode eines übergeordneten Verzeichnisses kann ausgehend von einem Inode einer Datei rückwärts der Pfad zu der Datei aufgebaut werden, ohne dass eine

Verzeichnisstruktur durch Lesen von Verzeichnisobjekten aufgebaut werden muss. Gemäß einer alternativen Ausgestaltung ist das Dateisystem als WORM-Dateisystem ausgeführt und die Information über das wenigstens eine Verzeichnis umfasst eine Pfadangabe der zugeordneten Datei von einem vorbestimmten Bezugspunkt, insbesondere einem Mountpoint des WORM-Dateisystems. Wenn das Dateisystem als so genanntes WORM-Dateisystem (Englisch:

„write once, read multiple") , also als nur einmal

beschreibbares Dateisystem ausgestaltet ist, können nach der ersten Speicherung einer Datei keine weiteren Änderungen in dessen Pfad, beispielsweise durch Umbenennen oder Verschieben der Datei oder von übergeordneten Verzeichnisse entstehen. In diesem Fall kann die vollständige Pfadangabe in dem der Datei zugeordneten Inode gespeichert werden. In einem derartigen System ist es durch einen linearen Scan durch die Liste der Inodes möglich, eine Dateiliste mit Pfadangaben zu Dateien und zugehörigen Inodes aufzubauen.

Zum Speichern des Dateinamens und der Informationen über das wenigstens eine Verzeichnis werden gemäß einem weiteren

Aspekt erweiterte Attribute des Dateisystems verwendet.

Gemäß einem weiteren Aspekt der Erfindung wird ein Verfahren zum Erzeugen einer Dateiliste mit Dateien eines POSIX- kompatiblen Dateisystems beschrieben. Das Verfahren umfasst die Schritte:

- Scannen einer vorbestimmten Gruppe von Inodes zum

Erfassen von Metadaten einer Mehrzahl von den Inodes jeweils zugeordneten Dateien, wobei die Metadaten wenigstens den Dateinamen der jeweils zugeordneten Datei und/oder

Informationen über ein Verzeichnis umfassen, in dem die jeweilige Datei gespeichert ist;

- Bestimmen von Dateinamen und/oder Pfadangaben von

Dateien basierend allein auf den in den Inodes gespeicherten Metadaten; und

- Erzeugen einer Dateiliste auf Grundlage der bestimmten Dateinamen bzw. Pfadangaben.

Das oben genannte Verfahren gestattet die Erzeugung einer Dateiliste ausschließlich auf Informationen, die in Inodes eines POSIX-kompatiblen Dateisystems enthalten sind. Auf diese Weise kann insbesondere das mehrfache Hin- und

Zurückspringen von Schreib-/Lese-Köpfen einer physikalischen Speichervorrichtung zwischen einem ersten Speicherbereich mit Informationen der Inodes und einem zweiten Speicherbereich mit anderen Datenblöcken vermieden werden, so dass der Aufbau der Dateiliste insgesamt beschleunigt wird. Gemäß einer vorteilhaften Ausgestaltung umfassen die

Metadaten wenigstens ein weiteres Attribut, insbesondere ein Datum einer letzten Sicherung der jeweils zugeordneten Datei, wobei das wenigstens eine weitere Attribut in die Dateiliste übernommen wird und/oder eine Übernahme einer Datei in die Dateiliste auf Grundlage des wenigstens einen weiteren

Attributs entschieden wird. Durch die Kombination des

Dateinamens mit weiteren Attributen der zugehörigen Datei, insbesondere eines Datum einer letzten Sicherung, können Sicherungs- und Archivierungssysteme sowie ähnliche

Softwareprogramme allein anhand der in den Inodes enthaltenen Metadaten entscheiden, welche Dateien weiterverarbeitet, beispielsweise gesichert, werden müssen. Gemäß einem weiteren Aspekt der Erfindung wird eine

Speichervorrichtung umfassend wenigstens eine Schnittstelle zum Zugriff von durch die Speichervorrichtung gespeicherten Dateien und wenigstens ein Massenspeichersystem zum

nichtflüchtigen Speichern der Dateien offenbart. Dabei ist die Speichervorrichtung dazu eingerichtet, bei Erhalt eines

Schreibbefehls zum Schreiben oder Ändern einer Datei über die wenigstens eine Schnittstelle Metadaten über die wenigstens eine Datei in dem Massenspeichersystem zu speichern bzw.

bereits gespeicherte Metadaten zu ändern, wobei die über die Datei gespeicherten Metadaten wenigstens den Dateinamen der Datei und/oder Informationen über ein Verzeichnis umfassen, in dem die Datei gespeichert ist.

Die genannte Speichervorrichtung speichert die notwendigen Informationen zur Ausführung des oben genannten Verfahrens und zur Bereitstellung eines POSIX-kompatiblen Dateisystems. Gemäß weiteren Ausgestaltungen der Erfindung umfasst die Speichervorrichtung des Weiteren eine Softwarekomponente, wobei die wenigstens eine Softwarekomponente dazu

eingerichtet ist, eine Dateiliste allein auf Grundlage der gespeicherten Metadaten zu erzeugen. Beispielsweise kann es sich um eine Softwarekomponente zur Dateiverwaltung handeln, die allein basierend auf den gespeicherten Metadaten Dateien für eine weitere Verarbeitung auswählt. Insbesondere kann eine Sicherung von Dateien basierend auf wenigstens einer in den Metadaten gespeicherten Zeitangabe, insbesondere eines Vergleichs eines zusätzlich gespeicherten Datums einer letzten Sicherung mit einem standardmäßig gespeicherten Datum einer letzten Änderung der den Metadaten zugeordneten Datei, durchgeführt werden.

Weitere vorteilhafte Ausgestaltungen und Einzelheiten der Erfindung sind in den angehängten Ansprüchen sowie der nachfolgenden ausführlichen Beschreibung von

Ausführungsbeispielen offenbart.

Die Erfindung wird nachfolgend anhand von unterschiedlichen Ausführungsbeispielen unter Bezugnahme auf die angehängten Figuren im Detail beschrieben. Dabei werden unterschiedliche Instanzen gleicher oder gleichwirkender Komponenten mit alphabetischen Suffixen gekennzeichnet. Soll auf alle

Instanzen gemeinsam Bezug genommen werden, wird das

entsprechende Suffix weggelassen. In den Figuren zeigen:

Figuren 1A bis IC, eine Baumdarstellung, eine

Speicheraufteilung sowie eine Listendarstellung eines POSIX- kompatiblen Dateisystems im Allgemeinen, Figuren 2A und 2B, eine konventionelle Datenstruktur sowie ein konventionelles Verfahren zum Erstellen einer Dateiliste,

Figuren 3A und 3B, eine Datenstruktur sowie ein Verfahren gemäß einer ersten Ausgestaltung der Erfindung,

Figuren 4A und 4B, eine Datenstruktur und ein Verfahren gemäß einer zweiten Ausgestaltung der Erfindung und Figur 5, eine schematische Darstellung einer

Speichervorrichtung gemäß einer Ausgestaltung der Erfindung.

Zum besseren Verständnis der Erfindung wird nachfolgend zunächst ein POSIX-kompatibles Dateisystem im Allgemeinen anhand der Figuren 1A bis IC sowie eine konventionelle

Datenstruktur zu seiner Implementierung sowie ein Verfahren zum Erstellen einer Dateiliste anhand der Figuren 2A und 2B beschrieben . Figur 1A zeigt einen Verzeichnisbaum 1 eines POSIX- kompatiblen Dateisystems 2. Zur besseren Unterscheidung werden im weiteren Verlauf Großbuchstaben zur Kennzeichnung von Verzeichnissen und Kleinbuchstaben sowie Ziffern zur Kennzeichnung von regulären Dateien des Dateisystems 2 verwendet. Selbstverständlich gestatten POSIX-kompatible Dateisysteme 2 in der Regel die Verwendung von Groß- und Kleinbuchstaben sowie Ziffern und sonstige Sonderzeichen sowohl für Verzeichnis- als auch Dateinamen. Des Weiteren sind deutliche längere Namen und die Herstellung von deutlich komplizierterer Verzeichnisbäume als dem in der Figur 1A dargestellten Verzeichnisbaum 1 möglich. Soweit in der folgenden Beschreibung und den angehängten Ansprüchen auf Dateien verwiesen wird, sind darunter jeweils reguläre Dateien im Sinne eines POSIX-kompatiblen

Dateisystems, das heißt die in dem Dateisystem 2

gespeicherten Nutzdaten, zu verstehen. Andere Objekte, wie insbesondere Verzeichnisobjekte, sogenannte Hard- und

Softlinks und sonstige Metadaten des Dateisystems 2, werden im Folgenden explizit als solche benannt, um sie besser von regulären Dateien zu unterschieden.

Der Verzeichnisbaum 1 umfasst ein so genanntes

Wurzelverzeichnis 3 das bei dem Betriebssystem Unix und daran angelehnten Betriebssystemen wie beispielsweise Linux

üblicherweise durch den vorwärts gestellten Schrägstrich „/" gekennzeichnet ist. Von dem Wurzelverzeichnis 3 verzweigt sich der Verzeichnisbaum 1 zunächst in drei Verzeichnisse A, B und C einer ersten Hierarchieebene. Das erste Verzeichnis A enthält in dem Verzeichnisbaum 1 gemäß Figur 1 zwei reguläre Dateien al und a2. Das zweite Verzeichnis B umfasst eine einzelne Datei bl . Das dritte Verzeichnis C umfasst ein weiteres Unterverzeichnis D einer zweiten Hierarchieebene sowie reguläre Dateien cl und c2. In dem Unterverzeichnis D zweiter Ordnung ist im Ausführungsbeispiel gemäß Figur 1 eine weitere Datei dl gespeichert.

An dieser Stelle wird darauf hingewiesen, dass der in der Figur 1A dargestellte Verzeichnisbaum 1 einen vereinfachten Sonderfall darstellt, der nur ein einziges Stammdateisystem ohne sogenannte Mountpoints sowie keinerlei Links zwischen unterschiedlichen Datei- und Verzeichnisobjekten des

Dateisystems 2 enthält. Grundsätzlich ist es bei POSIX- kompatiblen Dateisystemen üblich, den Inhalt weiterer

Massenspeicher mit darauf gespeicherten Verzeichnisbäumen an vorbestimmten Stellen, den sogenannten Mountpoints, eines übergeordneten Dateisystems, normalerweise des

Stammdateisystems mit dem Wurzelverzeichnis 3, einzubinden. Ebenfalls könne durch die Verwendung von Soft- oder Hardlinks netzwerkartige Strukturen erzeugt werden, so dass mehrere Pfade von dem Wurzelverzeichnis 3 zu ein und derselben regulären Datei führen können. Derartige Strukturen sind hier aus Gründen der Übersichtlichkeit nicht dargestellt. Ihre Bedeutung für die Implementierung der nachfolgend

beschriebenen Vorrichtungen und Verfahren sind an

entsprechender Stelle aufgeführt.

Figur 1B zeigt schematisch eine Datenstruktur zum Abbilden des Verzeichnisbaums 1 auf einen physikalischen Datenträger 4. Beispielsweise handelt es sich bei dem physikalischen Datenträger 4 um einen Massenspeicher in Form eines

Festplattenlaufwerks oder eines Flash-Laufwerks.

Grundsätzlich sind jedoch auch andere Speichermedien möglich. Der physikalische Datenträger 4 ist im Ausführungsbeispiel in einen ersten Speicherbereich 5 und einen zweiten

Speicherbereich 6 aufgeteilt. Beispielsweise kann es sich um eine Aufteilung gemäß Blockadressen oder sonstigen

Adressangaben des physikalischen Datenträgers 4 handeln. Eine derartige Aufteilung wird in der Regel bei einer ersten

Initialisierung des Datenträgers 4, beispielsweise bei dessen Formatierung mit dem Dateisystem 2, vorgenommen.

In dem ersten Speicherbereich 5 sind im Ausführungsbeispiel so genannte Inodes 7 gespeichert. Bei den Inodes handelt es sich um POSIX-kompatible Datenblöcke mit Metadaten über die in dem Dateisystem 2 gespeicherten Daten. Die genaue

Datenstruktur der einzelnen Inodes 7 wird weiter unten unter Bezugnahme auf die Figur 2A beschrieben. In der Darstellung gemäß Figur 1B ist ein vorbestimmter Inode 7r dem

Wurzelverzeichnis 3 zugeordnet. Beispielsweise handelt es sich um einen ersten adressierbaren Block des ersten

Speicherbereichs 5. Weitere Inodes 7 sind jeweils den

Verzeichnissen A, B, C und D sowie den Dateien al, a2, bl, cl, c2 und dl zugeordnet. Die jeweilige Zuordnung zwischen den Inodes 7 und den zugehörigen Verzeichnissen

beziehungsweise Dateien ist von der Implementierung des

Dateisystems 2 abhängig. Lediglich aus Gründen der

Übersichtlichkeit sind die Inodes 7 des ersten

Speicherbereichs 5 in der oben genannten Reihenfolge

dargestellt. In der Praxis hängt die Zuordnung von Inodes zu zugehörigen Verzeichnissen oder Dateien dagegen eher von der Reihenfolge ihrer Erstellung ab.

In dem zweiten Speicherbereich 6 sind die eigentlichen Daten des Dateisystems 2 gespeichert. Insbesondere sind zu jedem der Verzeichnisse A, B, C und D sowie dem Wurzelverzeichnis „/" ein Verzeichnisobjekt 8 in dem zweiten Speicherbereich 6 gespeichert. Die entsprechenden Verzeichnisobjekte 8 umfassen im Wesentlichen eine Liste mit Listeneinträgen, wobei jeder Listeneintrag die Namen und zugehörigen Inodes der in dem Verzeichnis gespeicherten Objekte angeben. Beispielsweise umfasst das Verzeichnisobjekt 8 für das Verzeichnis A zwei Listeneinträge mit den Dateinamen al und a2 sowie einer zugehörigen nummerischen Adresse der den Dateien al und a2 zugeordneten Inodes 7. In dem zweiten Speicherbereich 6 sind des Weiteren Dateiobjekte 9 regulärer Dateien gespeichert, die korrespondierenden Inodes 7 des ersten Speicherbereichs 5 zugeordnet sind. Je nach Umfang der gespeicherten Dateien können sich die tatsächlichen Daten über ein oder mehrere Dateiobjekte 9 erstrecken. Dies ist aus Gründen der Übersichtlichkeit in der Figur 9 jedoch nicht dargestellt.

Bei sehr großen Dateien reicht ein einzelner Inode 7 nicht immer aus, um Verweise auf sämtliche Dateiobjekte 9 des zweiten Speicherbereichs 6 in einem einzigen Inode 7 zu speichern. In diesem Fall verweist der Inode 7 auf weitere Inodes 7 zweiter oder dritter Ordnung, so dass eine große Anzahl von Verweisen auf entsprechende Dateiobjekte 9

gespeichert werden kann. Bezüglich weiterer Details wird beispielsweise auf den Artikel „Inodes" der

englischsprachigen Online-Enzyklopädie Wikipedia verwiesen (http://en.wikipedia.org/wiki/Inode, Fassung vom 27.10.2013). In der Figur IC ist eine Dateiliste 10 dargestellt. Die

Dateiliste 10 umfasst Listeneinträge 11 für reguläre Dateien. Jeder Listeneintrag 11 umfasst wenigstens eine vollständige Pfadangabe 12, bestehend aus einer einfache Pfadangabe 13 zum Verzeichnis, in dem die Datei gespeichert ist, sowie dem eigentlich Dateinamen 14, eine nummerische Adresse 15 des der Datei zugeordneten Inodes 7 sowie weitere Attribute 16 der Datei, wie beispielsweise das Datum einer Erstellung oder letzten Änderung der Datei. Die Informationen der Dateiliste 10 können beispielsweise von Softwarekomponenten eines

Archivierungssystems verwendet werden, um zu entscheiden, welche Dateiobjekte 9 des zweiten Speicherbereichs 6 auf einem weiteren Speichermedium, wie beispielsweise einem magnetischen Sicherungsband, gespeichert werden müssen. Solche Dateilisten 10 sind unter anderem in hierarchischen Speichersystem (HSM) aber für andere Systeme und Programme zur Verwaltung umfangreicher Daten erforderlich.

Problematisch an bekannten POSIX-kompatiblen Dateisystemen ist, dass die Erstellung einer solchen Dateiliste 10 unter anderem eine erhebliche Zeit in Anspruch nimmt. Insbesondere bei sogenannten „Big Data"-Systemen mit Millionen von über unterschiedliche Knoten eines Clustersystems verteilte

Dateien ist die Erstellung oder Laufendhaltung einer

entsprechenden Dateiliste 10 in der dafür zur Verfügung stehender Zeit mit bekannten Dateisystemen unmöglich.

Nachfolgend wird anhand der Figuren 2A und 2B beschrieben, wie anhand der auf dem physikalischen Datenträger 4

gespeicherten Informationen in konventionellen Dateisystemen eine Dateiliste 10 gemäß Figur IC erstellt werden kann. Dabei zeigt Figur 2A schematisch die dazu verwendeten

Datenstrukturen und Figur 2B ein Ablaufdiagramm eines

konventionellen Verfahrens zum Abarbeiten eines

Verzeichnisbaums 1 zur Erstellung der Dateiliste 10.

In einem ersten Schritt 20 wird der Inode 7r des

Wurzelverzeichnisses 3 bestimmt und geladen. Beispielsweise kann ein Inode-Eintrag mit der Adresse „0" aus dem ersten Speicherbereich 5 eingelesen werden. Gleichzeitig wird in einer Arbeitsvariable p der aktuelle Pfad festgehalten, der in diesem Fall durch einen einfachen „/" dargestellt ist. Nachfolgend wird in einem Schritt 21 ein zugehöriges

Verzeichnisobjekt 8r von dem zweiten Speicherbereich 6 geladen. Das Verzeichnisobjekt 8r umfasst in dem in Figur 2A dargestellten Ausführungsbeispiel drei Verzeichniseinträge 17 für die Verzeichnisse A, B und C der ersten Hierarchieebene.

Dementsprechend wird in einem nachfolgenden Schritt 22 festgestellt, dass in dem Verzeichnisobjekt 8r noch zu verarbeitenden Verzeichniseinträge 17 vorhanden sind. Im nachfolgenden Schritt 23 wird zunächst der erste

Verzeichniseintrag 17A bezüglich des an dieser Stelle noch unbekannten Speicherobjektes A eingelesen. Aus dem

Verzeichniseintrag 17A ergibt sich, dass dem Speicherobjekt A der Inode 7A mit der Adresse „1" zugeordnet ist. Des Weiteren ergibt sich aus dem Verzeichniseintrag 17A der Name „A" des Speicherobjekt A. Im nachfolgenden Schritt 24 wird der zugehörige Inode 7A des Speicherobjektes A mit der Adresse „1" eingeladen, um die zum Speicherobjekt A gehörigen Metadaten zu bestimmen.

Im Schritt 25 wird überprüft, um was für eine Art Objekt es sich bei dem Speicherobjekt A handelt. Aus den geladenen Metadaten des Inodes 7A kann beispielsweise anhand der so genannten Modus-Informationen bestimmt werden, ob es sich dabei, wie im vorliegenden Fall, um ein weiteres Verzeichnis oder eine reguläre Datei oder ein sonstiges Objekt eines POSIX-kompatiblen Dateisystems 2 handelt. In der Figur 2B ist aus Gründen der einfacheren Darstellung lediglich die

Verarbeitung von Dateien und Verzeichnissen angedeutet.

Handelt es sich wie vorliegend um ein weiteres

Verzeichnisobjekt 8, wird in einem nachfolgenden Schritt 26 die Arbeitsvariable für den zu untersuchenden Pfad p um den im Schritt 23 bestimmten Namen ergänzt. Des Weiteren wird das bis jetzt gültige Verzeichnis in einer weiteren Variablen q zwischengespeichert. Danach wird das Verfahren rekursiv im Schritt 21 mit dem Laden des zugehörigen Verzeichnisobjekts 8A fortgesetzt. Im beschriebenen Beispiel enthält das Verzeichnis A lediglich reguläre Dateiobjekte 9 für die Dateien al und a2.

Dementsprechend wird bei der nachfolgenden Überprüfung im Schritt 25 festgestellt, dass die Verzeichniseinträge 17 des Verzeichnisobjekts 8A auf reguläre Dateien verweisen. In einem Schritt 27 wird dementsprechend ein Listeneintrag 11 für die Dateiliste 10 basierend auf dem aktuellen Pfad p und dem im Schritt 23 aus dem Verzeichniseintrag 17 entnommenen Dateinamen „al" generiert. Danach wird das Verfahren im

Schritt 22 für den nächsten Verzeichniseintrag 17

fortgesetzt. Entsprechend wird in einem nachfolgenden Umlauf im Schritt 27 ein weiterer Listeneintrag 11 für die Datei a2 erzeugt . In einem erneuten Aufruf des Schritts 22 wird festgestellt, dass keine weiteren Verzeichniseinträge 17 in dem Verzeichnis A zu verarbeiten sind. Dementsprechend wird in einem

nachfolgenden Schritt 28 der Pfad auf das übergeordnete

Verzeichnis des Verzeichnisses A zurückgesetzt, also dem Wurzelverzeichnis „/", und das Verfahren wird auf der nächst höhere Ebene im Schritt 22 fortgesetzt.

Durch das beschriebene Verfahren wird der in der Figur 1A dargestellte Verzeichnisbaum 1 nach und nach durch den rekursiven Algorithmus besucht, wobei Verzeichniseinträge 17 für Dateiobjekte 9 in der Dateiliste 10 erzeugt werden.

Wie sich insbesondere aus der Darstellung gemäß Figur 2A ergibt, verursacht das Verfahren gemäß Figur 2B ein

regelmäßigen Hin- und Herspringen zwischen dem ersten

Speicherbereich 5 und dem zweiten Speicherbereich 6. Das liegt insbesondere darin begründet, dass ohne Auslesen der Information der Inodes 7 aus dem ersten Speicherbereich 5, die zugehörigen Verzeichnisobjekte 8 und Dateiobjekte 9 in dem zweiten Speicherbereich 6 nicht ausfindig gemacht werden können. Umgekehrt stehen in den Inodes 7 des ersten

Speicherbereichs 5 nicht sämtliche Informationen zur

Verfügung, um beispielsweise Namen oder Pfadangaben einzelner Dateien zu bestimmen oder die hierarchische Struktur des Verzeichnisbaumes 1 zu ermitteln. In der Praxis weist dieses Vorgehen daher den Nachteil auf, dass eine häufige

Neupositionierung von Schreib-/Lese-Köpfen oder sonstigen Lesevorrichtungen eines physikalischen Datenträgers 4 erforderlich sind, um die Dateiliste 10 zu erstellen.

Insbesondere bei sehr umfangreichen Datensammlungen, wie sie beispielsweise bei Archivierungssystemen auftreten, führt dies in der Praxis zu langen Laufzeiten und daher zu

Problemen bei häufig ablaufenden Prozessen.

Figur 3A zeigt eine verbesserte Datenstruktur zur Abbildung des eingangs beschriebenen Verzeichnisbaumes 1. Insbesondere ist in den einzelnen Inodes 7 zusätzlich zu den oben

genannten Informationen jeweils der Name des zugehörigen

Dateiobjekts 9 bzw. Verzeichnisobjekts 8 gespeichert. In den Inodes 7 ist ebenfalls ein Rückverweis 18 auf den Inode 7 eines übergeordneten Verzeichnisobjektes 8 gespeichert, also in dem Inode 7A des Verzeichnisses A beispielsweise ein

Verweis auf den Inode 7r. Nur im Inode 7r des

Wurzelverzeichnisses 3 selbst findet sich dort kein Eintrag.

Optional kann in allen Inodes 7 ein weiterer Verweis auf einen vorbestimmten Bezugspunkt des Dateisystems 2

gespeichert werden (in der Figur 3A nicht dargestellt) . Im

Fall des einfachen Verzeichnisbaums 1 gemäß Figur 1A verweist der Eintrag für den Bezugspunkt direkt auf das

Wurzelverzeichnis 3. Bei komplexeren Verzeichnisbäumen, die über mehrere Datenträger verteilt sind entsprechend mehrere Mountpoints aufweisen, verweist der Bezugspunkt auf den

Mountpoint des die Datei enthaltenen Dateisystems. Auf diese Weise bleiben die in den Inodes 7 gespeicherten Metadaten auch dann gültig, wenn das betreffende Dateisystem an anderer Stelle in einem übergeordneten Dateisystem, insbesondere dem Stammdateisystem, eingebunden wird.

Der Name des zugehörigen Dateiobjekts 9 beziehungsweise

Verzeichnisobjekts 8, der Rückverweis 18 und gegebenenfalls der Verweis auf den Bezugspunkt können beispielsweise als erweiterte Attribute bekannter Dateisysteme, beispielsweise durch Verwendung der sogenannten xattr-Funktion, gespeichert werden .

Figur 3B zeigt ein verbessertes Verfahren zum Erstellen der Dateiliste 10 basierend auf der Datenstruktur gemäß Figur 3A.

In einem ersten Schritt 30 wird überprüft, ob weitere Inodes 7 einer Liste von Inodes zu verarbeiten sind. Beispielsweise kann die Inode-Liste sämtliche Inodes 7 des ersten

Speicherbereichs 5 umfassen.

Ist dies der Fall wird im Schritt 31 der nächste zu

verarbeitende Inode 7 eingelesen. In einem nachfolgenden Schritt 32 wird überprüft, ob der Inode 7 einem regulären Dateiobjekt 9 zugeordnet ist. Ist dies nicht der Fall, kann die Verarbeitung im Schritt 30 unmittelbar mit dem nächsten Inode 7 fortgesetzt werden.

Wird dagegen im Schritt 32 festgestellt, dass der zuletzt gelesene Inode 7 einem regulären Dateiobjekt 9 zugeordnet ist, beispielsweise der Datei al, werden im Schritt 33 die Adresse 15 des Inode 7 sowie der zugehörige Name „al" des Dateiobjekts 9 in einer Variable n zwischengespeichert.

In einem Schritt 34 wird nachfolgend der Inode 7A geladen, den der Rückverweis 18 des zuvor geladenen Inodes 7 als Inode 7A des übergeordneten Verzeichnisobjektes 8A referenziert . Nachfolgend wird in einem Schritt 35 die Variable n um den Namen „A" des übergeordneten Verzeichnisses A ergänzt. In einem Schritt 36 wird überprüft, ob es sich bei dem übergeordneten Verzeichnis bereits um das Wurzelverzeichnis 3 handelt. Ist dies der Fall, wird in einem Schritt 37 die nun in der Variable n enthaltene, vollständige Pfadangabe 12 umfassend die Pfadangabe 13 sowie den Dateinamen 14 in der Dateiliste 10 sowie die Adresse 15 des Inodes 7 gespeichert, der der regulären Datei „al" zugeordnet ist. Danach wird das Verfahren im Schritt 30 mit der Verarbeitung eventuell weiterer Inodes 7 der Inode-Liste fortgesetzt. Wird im Schritt 36 jedoch festgestellt, dass es sich noch nicht um das Wurzelverzeichnis 3 handelt, wird das Verfahren im Schritt 34 mit dem Laden des Inodes 7 des dem aktuellen Verzeichnis übergeordneten Verzeichnisses fortgesetzt, so dass der Pfad im Schritt 35 um die nächsthöhere

Verzeichnisebene ergänzt wird, bis das Verfahren schließlich am Wurzelverzeichnis 3 ankommt. Auf diese Weise kann für jeden Inode 7 durch Folgen der Rückverweise 15 auf

übergeordnete Inodes 7 in sehr kurzer Zeit eine vollständige Pfadangabe 12 ermittelt werden. In konventionellen

Dateisystem 2 wäre dagegen der Aufbau bzw. die Suche über einen vollständigen Verzeichnisbaum 1 erforderlich. Das Verfahren gemäß Figur 3B weist eine Reihe von Vorteilen gegenüber dem Verfahren gemäß Figur 2B auf. Insbesondere kann beim Erstellen der Dateiliste 10 ein Hin- und Herspringen zwischen dem ersten Speicherbereich 5 und dem zweiten

Speicherbereich 6 auf dem physikalischen Datenträger 4 vermieden werden. Sämtliche zur Erstellung der Dateiliste 10 erforderliche Daten sind vollständig in den Inodes 7

gespeichert . Gleichzeitig kann auf eine vollständige rekursive Abarbeitung des Verzeichnisbaumes 1 verzichtet werden. Insbesondere ist es möglich, einen linearen Scan über sämtliche Inodes 7 durchzuführen, die in dem ersten Speicherbereich 5

gespeichert sind. Lediglich für die Inodes 7, die einem regulären Dateiobjekt 9 zugeordnet und deren sonstige

Metadaten beispielsweise einem bestimmten Suchprofil

entsprechen, müssen durch einen rekursiven Algorithmus um eine vollständige Pfadangabe 12 ergänzt werden. Insbesondere wenn bereits auf Grundlage einer Vorfilterung eine Vielzahl von Inodes 7 von dieser Bearbeitung

ausgeschlossen werden können, beispielsweise bei einem

Archivsystem, das nur die Dateinamen von seit einem letzten Sicherungszeitpunkt geänderten Dateien erfasst, spielt dieser rekursive Anteil des Algorithmus jedoch nur eine

untergeordnete Bedeutung für dessen Laufzeitverhalten.

In einer nicht bildlich dargestellten Abwandlung der

Ausgestaltung nach Figur 3A enthalten die Inodes 7 lediglich den Rückverweis auf das übergeordnete Verzeichnisobjekt 8, jedoch kein Attribut mit dem Namen des dem Inode 7

zugehörigen Dateiobjekts 9 oder Verzeichnisobjektes 8. In dieser Ausgestaltung muss zur Erstellung einer Dateiliste 10 noch auf die Verzeichnisobjekte 8 des zweiten

Speicherbereichs 6 zugegriffen werden. Allerdings kann die Anzahl der I/O-Zugriffe bereits in dieser Ausgestaltung deutlich reduziert werden, wenn nur Pfade für einen

verhältnismäßig kleinen Anteil der Inodes 7 bestimmt werden müssen. Beispielsweise können, wie später ausgeführt, aufgrund der sonstigen in dem Inode 7 enthaltenen Metadaten nur bestimmte Dateien für eine weitere Bearbeitung, etwa eine Sicherung, ausgewählt werden. Werden beispielsweise nur 1% der gespeicherten Dateiobjekte 9 gesichert, ist der Aufbau von Pfadangaben für die ausgewählten Inodes 7 durch Einlesen von wenigen Verzeichnisobjekten 8 immer noch mit deutlich weniger I /O-Zugriffen verbunden als ein komplettes

Durchsuchen des Verzeichnisbaumes 1.

Die Figuren 4A und 4B zeigen eine Datenstruktur

beziehungsweise ein Arbeitsverfahren gemäß einer weiteren Ausgestaltung der Erfindung. Wie insbesondere der Figur 4A zu entnehmen ist, ist in den Inodes 7 gemäß der weiteren

Ausgestaltung an Stelle des Namens des Speicherobjektes und dem Rückverweis 18 auf den Inode 7 eines übergeordneten

Verzeichnisobjektes 8 eine Pfadangabe 12, zumindest ab dem übergeordneten Mountpoint gespeichert. Des Weiteren ist in jedem Inode 7 ein Verweis 19 auf den Inode 7 eines

übergeordneten Bezugspunktes gespeichert. In der

beschriebenen Ausgestaltung dient als Bezugspunkt für Objekte des Stammdateisystems das Wurzelverzeichnis 3, hier ein

Verweis auf den Inode 7r. Für Objekte anderer in das

Stammdateisystem eingebundener Dateisysteme, beispielsweise anderen Partitionen einer Festplatte, Netzwerkvolumes oder wechselbaren Speichermedien, wird als Bezugspunkt der Inode des Mountpoints des entsprechenden eingebundenen Dateisystems gespeichert, an dem die Pfadangabe 12 beginnt. Schließlich ist in jedem Inode 7 zusätzlich ein Sicherungsdatum 20 gespeichert, das den Zeitpunkt einer letzten Sicherung des zugehörigen Objekts auf einem weiteren Speichermedium, beispielsweise einem Bandspeichermedium, durch eine

Sicherungskomponente angibt.

In einer Abwandlung der Ausgestaltung gemäß den Figuren 4A und 4B wird ein fester Bezugspunkt, beispielsweise das

Wurzelverzeichnis 3 oder ein anderer festgelegter Knoten des Dateisystems 2, fest vorgegeben oder anderer Stelle

gespeichert. In dieser Ausgestaltung kann auf die Speicherung des Verweises 19 in den Inodes 7 verzichtet werden. Bevorzugt wird in dieser Ausgestaltung nur ein einzelnes zusätzliches Attribut, nämlich eine vollständige Pfadangabe 12 umfassend die einfache Pfadangabe 13 ab dem Wurzelverzeichnis 3 und der Dateiname 14 selbst, als eine zusammenhängende Zeichenkette gespeichert .

Die Datenstruktur gemäß Figur 4A und deren oben beschriebene Abwandlung eignen sich zur noch schnelleren Erstellung von Dateilisten 10. In dem Ausführungsbeispiel handelt es sich bei dem Dateisystem 2 um ein so genanntes WORM-Dateisystem, in dem nach dem erstmaligen Schreiben einer Datei oder dem Erstellen eines Verzeichnisses keine Namensänderungen oder Verschiebungen mehr möglich sind. Da sich somit effektiv der Pfad zu einer einmal gespeicherten Datei ab dem gegebenen Bezugspunkt, entweder einem Mountpoint oder dem

Wurzelverzeichnis 3, nicht mehr ändern kann, kann die

vollständige Pfadangabe 12 wie in der Figur 4A dargestellt zusammenhängend in einem erweiterten Attribut eines Inodes 7 gespeichert werden. Die Erstellung einer Dateiliste gestaltet sich in diesem Fall besonders einfach. In einem ersten Schritt 40 wird überprüft, ob noch weitere Inodes 7 einer Liste von Inodes zu bearbeiten sind. Ist dies der Fall, wird im Schritt 41 der zunächst zu bearbeitende Inode 7 geladen. Nachfolgend wird im Schritt 42 überprüft, ob der geladene Inode 7 einem regulären

Dateiobjekt 9 zugeordnet ist. Ist dies nicht der Fall, kann das Verfahren im Schritt 40 mit der Verarbeitung eventuell weiterer Inodes 7 fortgesetzt werden. Andernfalls kann im Schritt 43 unmittelbar ein Eintrag für die Dateiliste 10 erstellt werden. Handelt es sich bei dem gespeicherten

Bezugspunkt direkt um das Wurzelverzeichnis 3 können die in dem aktuellen Inode 7 gespeicherten Informationen zur

vollständigen Pfadangabe 12 des Datenobjekts 9 direkt zur Erstellung des Eintrags verwendet werden. Bei komplexeren Dateisystemen mit mehreren Mountpoints muss gegebenenfalls noch ein Pfad vom Wurzelverzeichnis 3 bis zum jeweiligen gespeicherten Mountpoint bestimmt werden. Auch dies ist in der Regel ohne weitere I/O-Zugriffe auf einen Massenspeicher möglich, da selbst in komplexen Dateisystem in der Regel nur wenige Mountpoints vorhanden sind, die an einem zentralen Ort, insbesondere einer so genannten Dateisystemtabelle fstab (Englisch: filesystem table), gespeichert sind. Der Inhalt der Dateisystemtabelle fstab wird für eine Vielzahl

verschiedene Zwecke benötigt und ist daher in der Regel in einem Cachespeicher oder einer sonstigen speicherresidenten Datenstruktur gespeichert. Somit kann der Eintrag durch

Kombination eines zwischengespeicherten Pfades bis zu dem angegebenen Mountpoint und den in den Inode 7 gespeicherten Daten zur Pfadangabe gebildet werden. Danach wird das

Verfahren im Schritt 40 mit dem gegebenenfalls vorhandenen nächsten Inode 7 fortgesetzt. Auch das Verfahren gemäß Figur 4B besitzt den Vorteil, dass allein die in den Inodes 7 gespeicherten Informationen zur Erstellung der Dateiliste 10 genügen. Darüber hinaus besitzt das Verfahren gemäß Figur 4B den Vorteil, dass nun überhaupt keine rekursive Erstellung von Pfadangaben mehr erforderlich ist. Stattdessen kann die Dateiliste 10 durch einen

einfachen, linearen Algorithmus erstellt werden, der die in der Regel aufeinander folgend gespeicherten Inodes 7

sequenziell abarbeitet. Durch diese Vorgehensweise ist bei Dateisystem mit einigen Millionen Inodes 7 eine

Beschleunigung von etwa einem Faktor 100 gegenüber bekannten Verzeichnis-Suchläufen möglich.

Sofern eine Entscheidung bezüglich einer möglichen weiteren Verarbeitung der Datenobjekte 9 allein auf Grundlage der in den Inodes 7 gespeicherten Metadaten getroffen werden kann, müssen die Daten des zweiten Speicherbereichs 6 überhaupt nicht mehr eingelesen werden, was zu einer weiteren

wesentlichen Beschleunigung des Verfahrens führt.

Im dargestellten Beispiel dient hierzu unter anderem das zusätzliche Sicherungsdatum 20. Im beschriebenen

Ausführungsbeispiel sollen sämtliche Objekte des Dateisystems regelmäßig auf einem weiteren Speichermedium, beispielsweise einem Magnetband, gesichert werden. Dabei wird ein

sogenanntes inkrementelles Sicherungsverfahren verwendet, bei dem nur seit einer vorhergehenden Sicherung neu

hinzugekommene oder geänderte Objekte gesichert werden sollen. Die Entscheidung, welche Objekte bei einem

anstehenden Sicherungslauf gesichert werden müssen, kann allein auf Grundlage der in den Inodes 7 gespeicherten

Informationen getroffen werden. Insbesondere ist in der Figur 4A zu erkennen, dass das Wurzelverzeichnis 3 seit der letzten Sicherung am 01.07.2012 nicht mehr geändert wurde und daher nicht gesichert werden muss. Dagegen wurde das Verzeichnis A zuletzt am 03.07.2012 und damit nach seiner letzten Sicherung am 01.07.2012 geändert und muss dementsprechend gesichert werden. Die reguläre Datei al wurde noch überhaupt nicht gesichert und muss daher ebenfalls gesichert werden.

Figur 5 zeigt eine Speichervorrichtung 50 gemäß einem

Ausführungsbeispiel der Erfindung. Bei der

Speichervorrichtung 50 handelt es sich beispielsweise um eine so genannte Storage Appliance, die die Archivierung

unterschiedlicher Versionen von Dateien oder sonstigen

Datenobjekten ermöglicht. Dabei wird zumindest die jeweils aktuelle Version einer Datei auf einem leistungsfähigen, im Ausführungsbeispiel internen Massenspeicher 51 vorgehalten. Zusätzlich werden Kopien der aktuellen Version sowie

gegebenenfalls vorhandener vorhergehender Versionen auf einem weiteren Speichermedium vorgehalten. In der Figur 5 ist beispielsweise angedeutet, dass solche Kopien auf einem, im Ausführungsbeispiel externen Bandlaufwerk 52 oder in einem so genannten Cloudspeicher 53, also einer über ein

Datennetzwerk, insbesondere das Internet, angebundenen

Speichersystem gespeichert werden. Die Speichervorrichtung 50 gemäß Figur 5 weist eine erste Schnittstelle 54 zum Zugriff auf die in der

Speichervorrichtung 50 gespeicherten Daten auf.

Beispielsweise handelt es sich dabei um eine Schnittstelle gemäß dem NFS-Protokoll für die Unix-Betriebssystemfamilie oder eine Schnittstelle gemäß dem CIFS-Protokoll für die

Windows-Betriebssystemfamilie. Über die erste Schnittstelle 54 können die aus diesen Protokollen bekannten Anfragen zum Schreiben und Lesen sowie gegebenenfalls zum Löschen und Umbenennen einzelner Dateien an die Speichervorrichtung 50 übermittelt werden.

Im Ausführungsbeispiel werden die über die Schnittstelle 54 empfangenen Befehle über eine Verarbeitungskomponente 55 der Speichervorrichtung 50 analysiert und, soweit zulässig, umgesetzt. Im Ausführungsbeispiel dient dazu eine

Softwarekomponente, die auf einem nichtflüchtigen

Speichermedium der Speichervorrichtung 50 gespeichert ist. Die Verarbeitungskomponente 55 setzt die entsprechenden

Anforderungen in an sich bekannter Weise für ein Dateisystem 2 des Massenspeichers 51, beispielsweise das für

Clustersysteme besonders geeignete GPFS-Dateisystem

(Englisch: „General Parallel File System") der Firma IBM, um.

Bei der Konfiguration des gesamten oder eines Teils der

Speichervorrichtung 50 als WORM-Systemen werden Anfragen zum Ändern und Umbenennen von Dateien und Verzeichnissen mit einer entsprechenden Fehlermeldung quittiert und nicht ausgeführt. Ein Löschen einer Datei ist entweder gar nicht oder erst nach Ablauf einer vorbestimmten Aufbewahrungsfrist zulässig. Unzulässige Löschbefehle werden ebenfalls mit einer Fehlermeldung quittiert. Bei zulässigen Löschbefehlen, insbesondere auch Löschbefehle für reguläre Dateien in einem gewöhnlichen, wiederbeschreibbaren Dateisystemen, wird das Löschen einer Datei in einer zusätzlichen Protokoll-Datei eingetragen, die bei der späteren Erstellung von Dateilisten 10 und ähnlichen auf den Metainformationen beruhenden

Informationen entsprechend berücksichtigt wird.

Beispielsweise wird ein entsprechender Inode 7 durch

Speicherung eines zusätzlichen Attributs oder durch

Speicherung eines vorbestimmten Werts in einem vorhandenen Attribut als ungültig und damit das zugehörige Objekt als gelöscht gekennzeichnet.

Zusätzlich zu der Umsetzung der eigentlichen Anfrage werden in der beschriebenen Ausgestaltung noch bestimmte

vorhergehende und nachfolgende Aktionen ausgeführt, um die zusätzliche Metadaten zu speichern. Insbesondere werden beim Schreiben von neuen Dateien oder Verzeichnissen zugehörige Metadaten in dem zugehörigen Inode 7 des Dateisystems 2 des Massenspeichers 51 abgelegt. Hierzu umfasst die

Softwarekomponente einen sogenannten Dämon-Prozess , der auf Ereignisse gemäß der sogenannten Data Management API (DMAPI) Schnittstelle reagiert und unter anderem die für die oben beschriebenen Verfahren erforderlichen Zusatzinformationen in erweiterten Attributen des GPFS-Dateisystems speichert.

Beispielsweise können über die DMAPI-Schnittstelle die

Ereignisse „create" und „postcreate" für die Erstellung von Dateien abgefangen werden. Alternativ ist es auch möglich, die erforderlichen

Zusatzinformationen in einem einmaligen und/oder regelmäßig durchgeführten Suchlauf über alle Verzeichnisse zu ermitteln. Beispielsweise können in einem ersten Schritt sämtliche

Verzeichnisobjekte 8 eines Dateisystems 2 auf Änderungen seit einem letzten Suchlauf überprüft werden. In einem zweiten Schritt werden die Inodes 7 der Verzeichniseinträge 17 der geänderten Verzeichnisobjekte 8 ermittelt. Für diese Inodes 7 werden dann in einem dritten Schritt entsprechende

Zusatzinformationen gespeichert. Optional kann vor einem erneuten Speichern zunächst überprüft werden, ob die Inodes 7 bereits aktuelle Zusatzinformationen enthalten. Die Speichervorrichtung 50 umfasst des Weiteren eine zweite Schnittstelle 56 zur Administration. Über die zweite

Schnittstelle 56 hat ein Systemadministrator oder sonstiger berechtigter Benutzer Zugriff auf einen Konfigurationsdialog 57, mit dem das Verhalten der Speichervorrichtung 50 im

Detail konfiguriert werden kann. Beispielsweise kann über den Konfigurationsdialog 57 ausgewählt werden, ob sich das über die Schnittstelle 57 bereitgestellte Dateisystem des

Massenspeichers 51 oder einzelne Bereiche davon wie ein WORM- Speichermedium oder wie ein normales, mehrfach (über-) schreibbares Speichermedium verhalten soll.

Die Speichervorrichtung 50 umfasst des Weiteren eine Scan- Komponente 58, die unter anderem zur Verarbeitung der

zusätzlich in den Inodes 7 gespeicherten Metadaten dient. Darüber hinaus umfasst die Speichervorrichtung 50 einen so genannten Object-Mover 59, der für die bedarfsweise Sicherung von Dateien auf einem anderen Speichermedium verantwortlich ist. Eine Sicherung kann aus verschiedenen Gründen heraus erfolgen. Beispielsweise kann es sich um eine regelmäßige

Sicherung (Englisch: backup) der in der Speichervorrichtung 50 gespeicherten Objekte handeln. Alternativ kann es sich auch um eine Auslagerung einer Datei oder Dateiversion in einem hierarchischen Speichersystem bzw. Archivsystem

handeln, bei dem beispielsweise lange nicht benutzten Dateien bzw. veralteten Versionen, von dem Massenspeicher 51 auf das Bandlaufwerk 52 und/oder den Cloudspeicher 53 verschoben werden. Dabei erstellt der Objekt-Mover 59 am Zielort ein neues Objekt, das zumindest die Daten des gesicherten Objekts und gegebenenfalls weitere Metadaten zur Sicherung enthält. Zusätzlich werden die in den Inodes 7 des Dateisystems des Massenspeichers 51 gespeicherten Metadaten entsprechend aktualisiert. Beispielsweise wird bei einer Sicherung in einem erweiterten Attribut das aktuelle Datum als letztes Sicherungsdatum 20 vermerkt. Alternativ kann bei einer

Auslagerung das dem Inode 7 zugehörige Objekt als von dem Massenspeicher 51 gelöscht gekennzeichnet oder durch einen sogenannten Stub ersetzt werden, der auf den neuen

Speicherort verweist.

Die Speichervorrichtung 50 umfasst des Weiteren einen so genannten Backup-Manager 60 der für die selbsttätige

Datensicherung von auf dem Massenspeicher 51 gespeicherten

Daten entsprechend Voreinstellungen des Konfigurationsdialogs 57 verantwortlich ist. Um diese Aufgabe möglichst effizient durchführen zu können, greift der Backup-Manager 60 unter anderem auf die Scan-Vorrichtung 58 zu, um Objekte

auszuwählen, die durch den Object-Mover 59 von dem internen Massenspeicher 51 auf ein weiteres, externes Speichermedium gesichert werden sollen.

Nachfolgend wird anhand der Figur 5 ein so genanntes

„Incremental forever"-Sicherungssystem beschrieben. Der

Begriff der unendlichen, inkrementellen Sicherung soll dabei zum Ausdruck bringen, dass nach einer anfänglichen

Grundsicherung stets nur die seit der letzten Sicherung neu auf dem Massenspeicher 51 gespeicherten oder geänderten

Objekte, insbesondere reguläre Dateien und

Verzeichnisobjekte, gesichert werden. Selbstverständlich können auch andere Sicherungsstrategien, wie beispielsweise eine differenzielle Sicherung, bei der stets der Unterschied seit einer letzten Grundsicherung gesichert wird, oder eine Vollsicherung, bei der stets der gesamte Inhalt oder

vorbestimmte Teile des Massenspeichers 51 gesichert wird, verwendet werden. Über die Konfigurationsschnittstelle 57 werden verschiedene Systemparameter vorgegeben. Beispielsweise wird ein so genannter Mountpoint eines Dateisystems 2, für die die inkrementelle Sicherung durchgeführt werden soll, bestimmt. Darüber hinaus kann ein zeitlicher Abstand zwischen

verschiedenen zu sichernden Dateiversionen vorgegeben werden. Beispielsweise kann vorgegeben werden, dass die

Speichervorrichtung 50 stündlich, täglich oder wöchentliche Sicherung der in dem Massenspeicher 51 gespeicherten Dateien vornimmt. Auch weitere Kriterien, wie beispielsweise die minimale oder maximale Größe zu sichernder Dateien können über den Konfigurationsdialog 57 vorgegeben werden.

Ist ein vorbestimmter Sicherungszeitpunkt oder ein sonstiges eine Sicherung auslösendes Ereignis erreicht, müssen zunächst sämtliche Dateien des Massenspeichers 51 bestimmt werden, die aktuell gesichert werden müssen. Hierzu verwendet die

Speichervorrichtung 50 die Scan-Vorrichtung 58 um alle

Dateien zu bestimmen, deren Erstellungs- oder Änderungsdatum zeitlich nach dem Datum der letzten Sicherung liegt. Es wird angemerkt, dass diese Informationen im Ausführungsbeispiel gemäß Figur 4A bereits als Sicherungsdatum 20 in den Inodes 7 des Dateisystems 2 enthalten sind. Somit kann allein auf Grundlage eines Scans sämtlicher Inodes 7 festgestellt werden, welche Dateiobjekte 9 grundsätzlich für eine

Sicherung in Erwägung zu ziehen sind, ohne die einzelnen Dateiobjekte 9 des zweiten Speicherbereichs 6 zu laden.

Alternativ kann das Datum der letzten Sicherung auch an anderer Stelle in der Speichervorrichtung gespeichert sein. Beispielsweise kann ein global für alle Objekte des

Massenspeichersystems 51 gültiger Sicherungszeitpunkt

gespeichert oder bestimmt werden. Im Falle einer differenziellen Sicherung ist statt dem Datum der letzten Sicherung das Datum der letzten Vollsicherung zu verwenden.

Nur für die Objekte, die seit dem Zeitpunkt der letzten

Sicherung geändert wurden, werden nachfolgend basierend auf den in den Inodes 7 enthaltenen Metadaten, insbesondere dem darin enthaltenen Dateinamen 14 und/oder weiteren

Informationen einer Pfadangabe 12 oder 13 eine entsprechende Dateiliste 10 mit zu sichernden Objekten erstellt. Die zu erstellende Dateiliste 10 kann neben den Pfadangaben 12 oder 13 und/oder dem Dateinamen 14 weitere Informationen,

insbesondere einen direkten Verweis auf den zugehörigen Inode 7, die Größe der Datei und sonstige Informationen der

Metadaten enthalten. Eine derartige Liste 10 kann

beispielsweise an den Objekt-Mover 59 übergeben werden, um für geänderte Dateien neue Sicherungsobjekte auf dem

Bandlaufwerk 52 oder dem Cloudspeicher 53 zu speichern.

Neben dem oben genannten Sicherungssystem eignen sich die Datenstrukturen gemäß den Figuren 3A und 4A sowie die

Algorithmen gemäß den Figuren 3B und 4B jedoch auch für eine Vielzahl von anderen Anwendungen. Insbesondere eignen sich die beschriebenen Mechanismen für eine Vielzahl von

Datenverarbeitungsaufgaben, bei denen Daten zumindest teilweise mit zugehörigen Metadaten verarbeitet werden.

Als weiteres Beispiel wird nachfolgend eine

Bildverwaltungssoftware skizziert, bei der aus einer großen Anzahl von vorhandenen Bilddaten einzelne Bilder auf

Grundlage von Metadaten herausgefiltert werden sollen, wie beispielsweise einem Erstellungszeitraum, einem Aufnahmeort oder Informationen über einem in dem Bild enthaltenen Motiv. Konventionell werden derartige Datenverarbeitungsaufgaben durch einen von zwei möglichen Ansätzen gelöst. Entweder werden die Metainformationen zusammen mit den eigentlichen Daten, hier also den Bilddaten, gespeichert. Dies hat den Nachteil, dass bei einer Suche über die Metadaten sämtliche Bilddateien geöffnet und zumindest teilweise eingelesen werden müssen. Werden im Falle der hier beschriebenen

Bilddaten zugehörige Metadaten beispielsweise als so genannte EXIF-Daten in einem Bildformat, wie beispielsweise einem JPEG-Bildformat, gespeichert, muss zunächst jeweils zumindest die KopfInformationen der jeweiligen Bilddatei eingelesen werden, bevor eine Verarbeitung möglich ist. Dies führt zu der bereits eingangs beschriebenen häufigen Neupositionierung von Leseköpfen eines Massenspeichers und somit zu einer langsameren Verarbeitungsgeschwindigkeit.

Ein anderer Ansatz besteht darin, die erforderlichen

Metadaten in einer gesonderten Datenbank, insbesondere einer relationalen Datenbank oder einer Objektdatenbank zu

speichern. In diesem Fall stehen alle zur Beantwortung einer Abfrage erforderlichen Angaben in einer gemeinsamen Datenbank für eine beschleunigte Verarbeitung zur Verfügung. Der zweite genannte Ansatz besitzt jedoch den Nachteil, dass Änderungen von anderen Softwarekomponenten an den gespeicherten Daten, beispielsweise einer Überarbeitung des Bilds durch ein

Bildverarbeitungsprogramm, gegebenenfalls durch die Datenbank nicht erkannt wird. Dementsprechend besteht grundsätzlich das Problem, die in der Datenbank gespeicherten Metadaten mit den eigentlichen Daten konsistent zu halten.

Gemäß einem Ausführungsbeispiel der Erfindung werden solche, anwendungsspezifische Metadaten, zusätzlich in den Inodes 7 des Dateisystems 2 gespeichert. Beispielsweise kann ein Aufnahmeort eines Fotos in den erweiterten Attributen eines GPFS-Dateisystems gespeichert werden. In diesem Fall sind die oben beschriebenen Verfahren zum Scannen einer umfangreichen Liste von Dateien anwendbar. Insbesondere kann dann allein auf Grundlage einer Liste von Inodes 7 bestimmt werden, welche weiteren Dateien für eine Verarbeitung, beispielsweise die Zusammenstellung einer Diashow, berücksichtigt werden müssen. Da die anwendungsspezifischen Attribute direkt in dem erweiterten Dateisystem 2 gespeichert werden, kann es hierbei auch nicht zu einer Diskrepanz zwischen den gespeicherten Metadaten einerseits und eventuell geänderten Bilddaten andererseits kommen.

Insbesondere bietet sich hierfür das bereits oben ausgeführte Verfahren unter Verwendung der DMAPI-Schnittstelle an. Werden entsprechende Mechanismen zum Erstellen und Laufendhalten der in den Inodes 7 gespeicherten erweiterten Metadaten auf

Dateisystemebene in eine Speichervorrichtung 50 integriert, werden diese stets unabhängig von einer verwendeten Anwendung laufend gehalten.

Bezugs zeichenliste

1 Verzeichnissystem

2 Dateisystem

3 Wurzelverzeichnis

4 physischer Datenträger

5 erster Speicherbereich

6 zweiter Speicherbereich

7 Inode

8 Verzeichnisobjekt

9 Dateiobjekt

10 Dateiliste

11 Listeneintrag

12 (vollständige) Pfadangabe 13 (einfache) Pfadangabe

14 Dateiname

15 Adresse (des Inodes)

16 weiteres Attribut

17 Verzeichniseintrag

18 Rückverweis

19 Verweis (auf Bezugspunkt)

20 Sicherungsdatum

50 Speichervorrichtung

51 Massenspeicher

52 Bandlaufwerk

53 Cloudspeicher

54 erste Schnittstelle

55 Verarbeitungskomponente

56 zweite Schnittstelle 57 Konfigurationsdialog

58 Scanvorrichtung

59 Object-Mover

60 Backup-Manager