Поделиться через

Hier entsteht die neue Generation von Dateisystemen für Windows: ReFS

  • Статья

Wir möchten unsere Diskussion über das Speichern von Daten fortsetzen, indem wir über die nächste Generation von Dateisystemen sprechen, die in Windows 8 eingeführt wird. Derzeit ist NTFS unter den verbreiteten Dateisystemen das am meisten verwendete und fortschrittlichste, und es verfügt über viele Features. Bei einer Neuentwicklung von Windows, wie es bei Windows 8 der Fall ist, geben wir uns aber nicht mit vergangenen Erfolgen zufrieden. Daher führen wir bei Windows 8 ein neuentwickeltes Dateisystem ein. ReFS (Resilient File System, zuverlässiges Dateisystem) basiert auf den Grundlagen von NTFS, wodurch eine wesentliche Kompatibilität gewährleistet ist, während es gleichzeitig für eine neue Generation von Speichertechnologien und -szenarien entwickelt wurde. Bei Windows 8 wird ReFS nur für Windows Server 8 eingeführt. So sind wir bisher bei jedem neuen Dateisystem vorgegangen. Auf Anwendungsebene können Clients selbstverständlich in gleicher Weise auf ReFS-gespeicherte Daten zugreifen, wie dies bei NTFS-Daten der Fall ist. Wir sollten nicht vergessen, dass NFTS bislang die branchenführende Technologie für Dateisysteme auf PCs ist.

Dieser ausführliche Beitrag zur Architektur wurde von Surendra Verma verfasst, einem Entwicklungsmanager unseres Storage and File System-Teams. Wie bei jedem Feature waren jedoch zahlreiche Mitarbeiter beteiligt. In diesem Beitrag befindet sich auch wieder ein FAQ-Abschnitt.
– Steven

PS: Auf @buildwindows8 erhalten Sie einige Updates von CES.  

In diesem Blogbeitrag möchte ich Sie über ein neues Dateisystem für Windows informieren. Dieses Dateisystem mit dem Namen „ReFS“ wurde von Grund auf entwickelt, um einem weiten Spektrum von aktuellen und zukünftigen Kundenanforderungen in Bezug auf alle Bereitstellungen von Windows zu genügen.

Die Hauptziele von ReFS sind folgende:

  • Bereitstellen einer hohen Kompatibilität mit einer Untergruppe von NTFS-Features, die weitgehend übernommen wurde, während andere wegfallen, die bei hoher Systemkomplexität und -auslastung wenige Vorteile bieten.
  • Überprüfen und automatisches Korrigieren von Daten. Eine Vielzahl von Ursachen kann dazu führen, dass Daten beschädigt werden. Daher müssen sie überprüft und, sofern möglich, automatisch korrigiert werden. Es dürfen keine Metadaten geschrieben werden, um „abgerissene Schreibvorgänge“ zu vermeiden, auf die wir im Folgenden näher eingehen werden.
  • Optimieren für große Skalierungen. Verwenden Sie immer skalierbare Strukturen. Gehen Sie nicht davon aus, dass insbesondere Algorithmen, die Datenträger überprüfen, auf die Größe eines vollständigen Dateisystems skalieren können.
  • Schalten Sie das Dateisystem nie offline. Bei Beschädigungen ist es von Vorteil, den Fehler zu isolieren, während zur gleichen Zeit der Zugriff auf das restliche Volume möglich ist. Dabei wird ohne Verlust der Verfügbarkeit versucht, so viele Daten wie möglich zu retten.
  • Bereitstellen einer zuverlässigen End-to-End-Architektur, wenn das Storage Spaces-Feature verwendet wird, das zusammen mit ReFS entwickelt wurde.

Die Hauptfeatures von ReFS sind folgende (einige dieser Features werden in Kombination mit Storage Spaces bereitgestellt):

  • Metadatenintegrität mit Prüfsummen
  • Integritätsdatenströme für optionale Benutzerdatenintegrität
  • „Allocate on write“-Transaktionsmodell für stabile Datenträgerupdates (wird auch als „Copy on write“ bezeichnet)
  • Große Volume-, Datei- und Verzeichnisgrößen
  • Speicherpooling und Virtualisierung zum einfachen Erstellen und Verwalten des Dateisystems
  • Striping von Daten für die Leistung (Verwalten der Bandbreite) und Redundanz für die Fehlertoleranz
  • Bereinigen von Datenträgern zum Schutz vor latenten Datenträgerfehlern
  • Zuverlässigkeit bei Fehlern durch „Rettung“ für die bestmögliche Volumeverfügbarkeit
  • Computerübergreifend freigegebene Speicherpools für zusätzliche Fehlertoleranz und Lastenausgleich

Zusätzlich übernimmt ReFS die Features und die Semantik von NTFS, einschließlich BitLocker-Verschlüsselung, Zugriffssteuerungslisten für die Sicherheit, USN-Journal, Änderungsbenachrichtigungen, symbolische Links, Abzweigungspunkte, Bereitstellungspunkte, Analysepunkte, Volumesnapshots, Datei-IDs und Oplocks.

Der Zugriff auf ReFS-Daten erfolgt selbstverständlich über die gleichen Client-APIs für den Dateizugriff, mit denen auch der Zugriff auf die heutigen NTFS-Volumes möglich ist.

Hauptentwurfsattribute und -features

Unsere Entwurfsattribute sind eng mit unseren Zielen verknüpft. Bei der Erläuterung dieser Attribute sollten Sie an die bisherige Entwicklung von Dateisystemen denken, die von hunderten von Millionen Geräten verwendet werden, von den kleinsten Computern bis zu den größten Datencentern, vom kleinsten Speicherformat bis zum größten Multispindle-Format, von SSDs bis zu den größten verfügbaren Laufwerken und Speichersystemen. Auf die Dateisysteme von Windows greift gleichzeitig von überall aus eine Vielzahl von Anwendungs- und Systemsoftware zu. Dies wird von ReFS berücksichtigt, und es baut darauf auf. Wir haben nicht von vorne begonnen. Wir haben dort weiterentwickelt, wo es sinnvoll erschien, aber die bewährten Aspekte von NTFS beibehalten. Insgesamt sind wir pragmatisch vorgegangen, mit dem Ziel, ein führendes Dateisystem zu entwickeln – etwas, das in diesem Umfang nur Microsoft geleistet hat.

Wiederverwendung von Code und Kompatibilität

Bei der Dateisystem-API handelt es sich um den Bereich, in dem Kompatibilität am schwierigsten und am technisch anspruchvollsten zu erreichen ist. Das Neuschreiben des Codes, der die Semantik des Dateisystems implementiert, führt nicht zum richtigen Kompatibilitätsgrad und würde große Probleme in den Bereichen Anwendungscode, Aufrufzeit und Hardware verursachen. Daher haben wir bei der Entwicklung von ReFS den Code für die Semantik des Dateisystems von Windows wiederverwendet. Dieser Code implementiert die Schnittstelle des Dateisystems (lesen, schreiben, öffnen, schließen, Änderungsbenachrichtigung usw.), verwaltet den Datei- und Volumestatus im Arbeitsspeicher, erzwingt die Sicherheit und verwaltet das Zwischenspeichern und Synchronisieren von Dateidaten. Durch diese Wiederverwendung wird ein hoher Kompatibilitätsgrad mit den Features von NTFS gewährleistet, die beibehalten wurden.

Abgesehen von diesem wiederverwendeten Code, verwendet die NTFS-Version der Codebasis ein neuentwickeltes Modul, mit dem Strukturen auf dem Datenträger wie der Master File Table (MFT) implementiert werden, um Dateien und Verzeichnisse abzubilden. In ReFS wird dieser bewährte Code mit einem neuen Modul kombiniert, das den entscheidenden Anteil der Innovation von ReFS darstellt. Grafisch sieht das folgendermaßen aus:

NTFS.SYS = API/Semantikmodul der oberen NTFS-Schicht / NTFS-Datenträger-Speichermodul; ReFS.SYS = von NTFS abgeleitetes Modul der oberen Schicht / Neues Datenträger-Speichermodul

Zuverlässige und skalierbare Strukturen auf Datenträgern

Strukturen auf Datenträgern und Veränderungen an ihnen werden vom Datenträger-Speichermodul verarbeitet. Dabei handelt es sich um eine allgemeine Schlüssel-Wert-Schnittstelle, die von der oberen Schicht zum Implementieren von Dateien, Verzeichnissen usw. verwendet wird. Zur eigenen Implementierung wird vom Speichermodul ausschließlich die B+-Struktur verwendet. Tätsächlich ist die B+-Struktur die einzige gemeinsame Struktur auf dem Datenträger zum Darstellen aller Informationen. Strukturen können in andere Strukturen integriert werden (der Stamm einer untergeordneten Struktur wird in der Zeile einer übergeordneten Struktur gespeichert). Auf dem Datenträger können Strukturen sehr groß sein und mehrere Ebenen umfassen, oder sie sind sehr kompakt, verfügen nur über wenige Schlüssel und sind in eine andere Struktur eingebettet. So wird eine große Skalierbarkeit für alle Aspekte des Dateisystems gewährleistet. Mit der Beschränkung auf eine einzelne Struktur kann das System wesentlich vereinfacht und der Code reduziert werden. In der neuen Schnittstelle des Moduls werden „Tabellen“ verwendet, bei denen es sich um auflistbare Sätze von Schlüssel-Wert-Paaren handelt. Die meisten Tabellen verfügen über eine eindeutige Kennung (als „Objekt-ID“ bezeichnet), durch die auf sie verwiesen werden kann. In einer speziellen Objekttabelle werden alle Tabellen im System indiziert.

Im Folgenden wird erläutert, wie die gemeinsamen Abstraktionen des Dateisystems mithilfe von Tabellen aufgebaut sind.

Objekttabelle: Objekt-ID, Offset und Prüfsumme des Datenträgers. Pfeil zum Verzeichnis: Dateiname, Dateimetadaten; Dateimetadaten: Schlüssel, Wert; Dateierweiterungen: 0-07894, Offset und Prüfsummen des Datenträgers; 7895-10000, Offset und Prüfsummen des Datenträgers; 10001-57742, Offset und Prüfsummen des Datenträgers; 57743-9002722, Offset und Prüfsummen des Datenträgers

Dateistrukturen

Wie im vorangegangenen Diagramm zu sehen, werden Verzeichnisse als Tabellen dargestellt. Da Tabellen mithilfe der B+-Struktur implementiert werden, können sehr große Verzeichnisse effizient skaliert werden. Dateien werden als Tabellen implementiert, die in eine Zeile des übergeordneten Verzeichnisses eingebettet sind, bei dem es sich ebenfalls um eine Tabelle handelt (im vorangegangenen Diagramm als Dateimetadaten dargestellt). Durch die Zeilen innerhalb der Dateimetadatentabelle werden die verschiedenen Dateiattribute dargestellt. Die erweiterten Speicherorte für Dateidaten werden durch eine eingebettete Datenstromtabelle dargestellt, bei der es sich um eine Tabelle mit Offsetzuordnungen (optional mit Prüfsummen) handelt. Auch bei sehr großen Dateien und Verzeichnissen treten also, abgesehen von den Beschränkungen in NTFS, keine Leistungeinbußen auf.

Wie erwartet, werden andere globale Strukturen im Dateisystem wie ACLs (Access Control Lists, Zugriffssteuerungslisten) als Tabellen mit einem Stamm innerhalb der Objekttabelle dargestellt.

Alle Speicherplatzzuordnungen werden von einer hierarchischen Zuordnung verwaltet, die freien Speicherplatz durch Bereiche in Tabellen darstellt. Für die Skalierbarkeit gibt es drei Tabellen: für große, mittlere und kleine Zuordnungen. Sie unterscheiden sich hinsichtlich der Granularität des von ihnen verwalteten Speicherplatzes: Von einer mittleren Zuordnung werden z. B. Abschnitte mittlerer Größe verwaltet, die von einer großen Zuordnung zugeordnet werden. Hierdurch lassen sich die Algorithmen zur Speicherplatzzuordnung sehr gut anpassen, und wir können verwandte Metadaten zur Leistungssteigerung besser anordnen. Auf die Stämme dieser Zuordnungen und der Objekttabelle kann von einer bekannten Position auf dem Datenträger zugegriffen werden. Einige Tabellen verfügen über spezifische Zuordnungen, wodurch die Auslastung verringert und eine bessere Zuordnung begünstigt wird.

Abgesehen von Tabellen mit globalen Systemmetadaten, verweisen die Einträge in der Objekttabelle auf Verzeichnisse, da Dateien in die Verzeichnisse eingebettet sind.

Strategie für stabile Datenträgerupdates

Die Aktualisierung der Zuverlässigkeit und Effizienz des Datenträgers ist einer der wichtigsten und anspruchsvollsten Aspekte bei der Entwicklung eines Dateisystems. Wir haben verschiedene Herangehensweisen ausführlich überprüft. Einer der Ansätze, die wir in Betracht gezogen und anschließend verworfen haben, bestand in der Implementierung eines durch ein Protokoll strukturiertes Dateisystems. Diese Herangehensweise ist nicht für ein universell einsatzfähiges Dateisystem geeignet, wie es für Windows erforderlich ist. NTFS nutzt ein Transaktionsjournal, um die Konsistenz auf dem Datenträger sicherzustellen. Bei diesem Ansatz werden Metadaten direkt auf dem Datenträger aktualisiert. Mithilfe eines Journals können Änderungen nachverfolgt werden, wodurch bei Fehlern und bei Wiederherstellung nach Stromausfall ein Rollback möglich ist. Ein Vorteil dieser Herangehensweise ist, dass das Metadatenlayout am gleichen Ort verbleibt, was möglicherweise zu einer besseren Leseleistung führt. Die Hauptnachteile eines Journalsystems bestehen darin, dass Schreibvorgänge zufällig erfolgen können und, was wichtiger ist, dass beim Aktualisieren des Datenträgers vorher geschriebene Metadaten beschädigt werden können, wenn zum Zeitpunkt des Schreibens ein Stromausfall auftritt. Dieses Problem wird in der Regel als abgerissener Schreibvorgang bezeichnet.

Um die Zuverlässigkeit zu optimieren und abgerissene Schreibvorgänge auszuschließen, haben wir uns für den „Allocate on write“-Ansatz entschieden, bei dem Metadaten nie am gleichen Ort aktualisiert, sondern auf atomare Art an einen anderen Speicherort geschrieben werden. In gewisser Weise ist dies an das alte Prinzip des „Shadow Paging“ angelehnt, mit dem Strukturen auf Datenträgern zuverlässig aktualisiert werden. Transaktionen basieren auf diesem „Allocate on write“-Ansatz. Da die obere Schicht von ReFS von NTFS abgeleitet wurde, unterstützt das neue Transaktionsmodell nahtlos die bereits vorhandene Wiederherstellungslogik für Fehler, die im Laufe vieler Veröffentlichungen getestet und stabilisiert wurde.

Metadaten werden von ReFS so zugeordnet, dass Schreibvorgänge für zusammenhängende Bereiche (z. B. Datenstromzuordnung, Dateiattribute, Dateinamen und Verzeichnisseiten) zu weniger und größeren E/As kombiniert werden können. Dies ist sowohl für rotierende Medien als auch für Flashlaufwerke von Vorteil. Gleichzeitig wird eine gewisse Lesekontiguität sichergestellt. Das hierarchische Zuordnungsschema wird besonders unterstützt.

Wir führen entscheidende Tests durch, bei denen wir den Strom unterbrechen, während das System stark beansprucht wird. Nach dem Sichern des Systems werden dann alle Strukturen auf ihren ordnungsgemäßen Zustand überprüft. In diesen Tests zeigt sich unser Erfolg. Wir haben in diesem Test für Dateisysteme von Microsoft ein einzigartiges Niveau an Stabilität erreicht. Unserer Ansicht nach ist das System branchenführend und erfüllt unsere wesentlichen Entwurfsziele.

Zuverlässigkeit bei Beschädigungen des Datenträgers

Wie im Vorangegangenen erwähnt, war es eines unserer Entwurfsziele, Beschädigungen zu erkennen und zu beheben. Auf diese Weise lässt sich nicht nur die Datenintegrität gewährleisten, sondern es werden auch die Verfügbarkeit des Systems und Onlinevorgänge verbessert. So wird die Prüfsumme aller ReFS-Metadaten auf der Ebene einer B+-Struktur-Seite ermittelt, und diese Prüfsummen werden von der Seite selbst unabhängig gespeichert. Wir können daher alle Arten von Beschädigungen des Datenträgers erkennen, einschließlich verlorener und fehlgeleiteter Schreibvorgänge und bitweiser Rotation (Herabsetzung von Daten auf dem Medium). Wir haben zusätzlich eine Option hinzugefügt, mit der auch die Prüfsumme von Dateiinhalten ermittelt werden kann. Wenn diese Option, als „Integritätsdatenströme“ bezeichnet, aktiviert wird, werden die Dateiänderungen von ReFS immer an einen anderen Speicherort als den ursprünglichen geschrieben. Durch diese „Allocate on Write“-Methode wird sichergestellt, dass bestehende Daten nicht durch die neuen Schreibvorgänge verloren gehen. Die Aktualisierung der Prüfsumme erfolgt beim Schreiben der Daten automatisch, sodass bei einem Stromausfall während des Schreibvorgangs immer eine konsistente bestätigte Version der Datei verfügbar ist, wodurch Beschädigungen autorisierend erkannt werden können.

Vor einigen Wochen haben wir in einem Beitrag Storage Spaces behandelt. ReFS und Storage Spaces wurden so entwickelt, dass sie sich als zwei Komponenten eines vollständigen Speichersystems ergänzen. Storage Spaces steht NTFS (und Clientcomputern) zur Verfügung, worin ein großer Vorteil liegt. Durch die Schichtung der Architektur wird dieser Clientansatz unterstützt, während wir ReFS für die Verwendung auf Clients anpassen, damit Sie letztendlich ReFS sowohl für Clients als auch für Server verwenden können.

Zusätzlich zur Leistungsteigerung werden durch Storage Spaces Daten vor teilweisen oder vollständigen Datenträgerfehlern geschützt, indem auf verschiedenen Datenträgern Kopien erstellt werden. Bei Lesefehlern kann Storage Spaces alternative Kopien lesen, und bei Schreibfehlern (oder bei vollständigem Medienverlust beim Lesen/Schreiben) können Daten erneut übersichtlich zugeordnet werden. Bei vielen Fehlern handelt es sich nicht um Medienfehler, sondern um die Beschädigung von Daten oder um verlorene und fehlgeleitete Schreibvorgänge.

Diese Fehler können von ReFS mithilfe von Prüfsummen erkannt werden. Wenn einer dieser Fehler von ReFS erkannt wird, wird eine Verbindung zu Storage Spaces hergestellt, um alle verfügbaren Kopien der Daten zu lesen. Anschließend wird anhand der Prüfsummenvalidierung die richtige ausgewählt. Dann wird Storage Spaces veranlasst, die Probleme der fehlerhaften Kopien auf Grundlage der ordnungsgemäßen Kopien zu beheben. Alles erfolgt im Hinblick auf die Übersichtlichkeit der Anwendung. Wenn ReFS nicht auf einem gespiegelten Storage Space ausgeführt wird, erfolgt die Reparatur der Beschädigung nicht automatisch. In diesem Fall wird nur ein Ereignis protokolliert, aus dem hervorgeht, dass eine Beschädigung festgestellt wurde und, wenn es sich um Dateidaten handelt, dass das Lesen fehlgeschlagen ist. Zu einem späteren Zeitpunkt werden wir die Auswirkungen auf Metadaten behandeln.

Für ReFS-Metadaten sind Prüfsummen (64-Bit) immer aktiviert. Wenn das Volume auf einem gespiegelten Storage Space gehostet wird, ist auch die automatische Korrektur immer aktiviert. Alle Integritätsdatenströme (siehe oben) werden auf die gleiche Weise geschützt. Dadurch erhält der Kunde eine End-to-End-Lösung mit hoher Integrität, mit der auch bei relativ unzuverlässigen Speichern eine hohe Zuverlässigkeit erreicht werden kann.

Integritätsdatenströme

Durch Integritätsdatenströme werden Dateiinhalte vor allen Arten von Datenbeschädigungen geschützt. Obwohl dieses Feature für viele Szenarien nützlich ist, ist es für einige nicht geeignet. Beispielsweise erfolgt bei einigen Anwendungen die Verwaltung der Dateispeicherung sorgfältig, und sie stützt sich auf ein bestimmtes Dateilayout auf dem Datenträger. Da bei jeder Änderung von Inhalten Blöcke durch die Integritätsdatenströme neu zugeordnet werden, ist das Dateilayout für diese Anwendungen zu wenig vorhersehbar. Datenbanksysteme sind hierfür ein sehr gutes Beispiel. Solche Anwendungen behalten in der Regel auch die eigenen Prüfsummen für Dateiinhalte, und sie sind in der Lage, Daten durch direkte Interaktion mit Storage Spaces-APIs zu überprüfen und zu korrigieren.

In diesen Fällen, in denen ein bestimmtes Dateilayout erforderlich ist, stellen wir Mechanismen und APIs zum Steuern dieser Einstellung auf verschiedenen Granularitätsebenen bereit.

Auf der einfachsten Ebene handelt es sich bei der Integrität um das Attribut einer Datei (FILE_ATTRIBUTE_INTEGRITY_STREAM). Sie ist auch das Attribut eines Verzeichnisses. Wenn sie sich in einem Verzeichnis befindet, wird sie von allen Dateien und Verzeichnissen geerbt, die im Verzeichnis erstellt werden. Sie können dies auch mithilfe des Befehls „formatieren“ für das Stammverzeichnis eines Volumes in einem Zeitformat festlegen. Durch das Festlegen in einem Stamm wird die standardmäßige Übertragung auf jede Datei und jedes Verzeichnis des Volumes sichergestellt. Beispiel:

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

Wenn der /i-Switch standardmäßig nicht festgelegt ist, hängt das Systemverhalten davon ab, ob sich das Volume auf einem gespiegelten Space befindet. Auf einem gespiegelten Space wird die Integrität aktiviert, da davon auszugehen ist, dass die Vorteile gegenüber den Kosten deutlich überwiegen. Dies kann von Anwendungen für einzelne Dateien jederzeit programmatisch überschrieben werden.

Maßnahmen gegen „bitweise Rotation“

Wie im Vorangegangenen erläutert, führt die Kombination aus ReFS und Storage Spaces zu einem hohen Grad an Datensicherheit bei Beschädigungen von Datenträgern und Speicherfehlern. Eine Art des Datenverlusts, die schwieriger zu erkennen und zu handhaben ist, resultiert aus „bitweiser Rotation“. Dabei treten im Laufe der Zeit bei Teilen des Datenträgers Beschädigungen auf, die unbemerkt bleiben, sofern sie sich in selten gelesenen Teilen befinden. Wenn sie dann gelesen und erkannt werden, sind die Alternativkopien möglicherweise aufgrund anderer Fehler auch beschädigt oder verloren.

Zum Schutz vor bitweiser Rotation haben wir eine Systemaufgabe hinzugefügt, durch die in bestimmten Zeitabständen alle Metadaten und Daten des Integritätsdatenstroms eines ReFS-Volumes, die sich auf einem gespiegelten Storage Space befinden, gereinigt werden. Bei diesem Reinigen werden mithilfe der ReFS-Prüfsummen alle redundanten Kopien gelesen und auf ihren ordnungsgemäßen Zustand überprüft. Wenn die Prüfsummen nicht übereinstimmen, werden die fehlerhaften Kopien mithilfe von ordnungsgemäßen repariert.

Durch das Dateiattribut FILE_ATTRIBUTE_NO_SCRUB_DATA wird angegeben, dass das Reinigungsprogramm die Datei überspringt. Dieses Attribut eignet sich für Anwendungen, die die eigenen Integritätsinformationen beibehalten, wenn der Anwendungsentwickler eine bessere Kontrolle über das Reinigen der Dateien anstrebt.

Bei dem Befehlszeilentool „Integrity.exe“ handelt es sich um eine effiziente Möglichkeit, die Integrität zu verwalten und Richtlinien zu reinigen.

Ununterbrochene Volumeverfügbarkeit bei Ausfällen

Wir gehen davon aus, dass viele Kunden ReFS in Kombination mit Storage Spaces verwenden, wodurch Beschädigungen automatisch und übersichtlich repariert werden. Es gibt allerdings seltene Fälle, in denen sogar ein Volume auf einem gespiegelten Space beschädigt werden kann. Daten können beispielsweise durch fehlerhafte Systemspeicher beschädigt werden, die dann möglicherweise alle redundanten Kopien auf dem Datenträger beschädigen. Einige Kunden möchten möglicherweise auch kein gespiegeltes Storage Space mit ReFS verwenden.

In diesen Fällen, in denen das Volume beschädigt wird, implementiert ReFS „Rettung“, ein Feature, durch das die beschädigten Daten vom Namespace auf einem Live-Volume entfernt werden. Durch dieses Feature soll sichergestellt werden, dass Beschädigungen, die nicht repariert werden können, die Verfügbarkeit der ordnungsgemäßen Daten nicht negativ beeinflussen. Wenn z. B. eine einzelne Datei in einem Verzeichnis beschädigt wird und sich nicht automatisch reparieren lässt, wird sie von ReFS aus dem Namespace des Dateisystems entfernt, während der Rest des Volumes gerettet wird. Dieser Vorgang wird in der Regel in weniger als einer Sekunde ausgeführt.

Normalerweise kann eine beschädigte Datei vom Dateisystem nicht geöffnet oder gelöscht werden, weshalb ein Administrator nicht reagieren kann. Da aber ReFS die beschädigten Daten immer noch retten kann, kann der Administrator diese Datei aus einer Sicherungskopie wiederherstellen oder durch die Anwendung erneut erstellen, ohne das Dateisystem offline zu nehmen. Durch diese wesentliche Innovation können eine teure Offlineüberprüfung des Datenträgers und ein Reperaturtool vermieden werden, und es können sehr große Datenvolumes ohne das Risiko langer Offlinezeiten durch Beschädigungen bereitgestellt werden.

Es passt genau in den Speicherstapel von Windows

Unser Entwurfsziel war klar: Ein Maximum an Flexibilität und Kompatibilität. Wir haben ReFS so entwickelt, dass es wie jedes andere Dateisystem in den Speicherstapel eingebunden werden kann, um eine größtmögliche Kompatibilität mit den umgebenden Ebenen zu erreichen. Es kann z. B. BitLocker-Verschlüsselung, Zugriffssteuerungslisten für die Sicherheit, USN-Journal, Änderungsbenachrichtigungen, symbolische Links, Abzweigungspunkte, Bereitstellungspunkte, Analysepunkte, Volumesnapshots, Datei-IDs und Oplocks nahtlos nutzen. Wir gehen davon aus, dass die meisten Dateisystemfilter mit ReFS ohne oder nur mit kleinen Änderungen funktionieren. Darauf weisen unsere Tests hin. Wir konnten z. B. die Funktionalität der vorhandenen Forefront-Antivirenlösung überprüfen.

Einige Filter, die vom physischen NTFS-Format abhängen, erfordern größere Änderungen. Durch ein umfangreiches Kompatibilitätsprogramm testen wir unsere Dateisysteme mit Antiviren- und Sicherungsprogrammen sowie vergleichbarer Software von Drittanbietern. Genauso gehen wir bei ReFS vor, und wir arbeiten mit unseren wichtigsten Partnern daran, alle entdeckten Inkompatibilitäten zu beheben. Dies gilt nicht nur für ReFS, sondern ist bei uns schon lange gängige Praxis.

Flexibiltät wird dadurch gewährleistet, dass ReFS und Storage Spaces zwar gut miteinander kombiniert werden können, aber so entwickelt wurden, dass sie unabhängig voneinander funktionieren. Auf diese Weise wird für beide Komponenten eine maximale Flexibilität bei der Entwicklung erreicht, ohne dass sie sich gegenseitig unnötig einschränken. Oder anders ausgedrückt: bei der Auswahl einer umfassenden Speicherlösung werden Kompromisse hinsichtlich der Zuverlässigkeit und Leistung eingegangen, darunter eine Bereitstellung von ReFS mit einem zugrunde liegenden Speicher unserer Partner.

Mit Storage Spaces kann ein Speicherpool von mehreren Computern genutzt werden, und das nahtlose Wechseln der virtuellen Datenträger zwischen ihnen führt zu einer zusätzlichen Zuverlässigkeit bei Fehlern. Durch unseren Systementwurf kann ReFS davon nahtlos profitieren.

Verwendung

Wir haben ReFS mithilfe von zehntausenden anspruchsvollen und groß angelegten Testreihen getestet, die in zwanzig Jahren für NTFS entwickelt wurden. Bei diesen Tests werden Bereitstellungsanforderungen simuliert, wie sie bei starker Systembeanspruchung, bei Stromausfall sowie Fehlern in Zusammenhang mit Skalierbarkeit und Leistung auftreten. Daher kann ReFS jetzt für die Bereitstellung in einer verwalteten Umgebung getestet werden. Da es sich um die erste Version eines großen Dateisystems handelt, ist ein wenig Vorsicht angebracht. Wir bezeichnen ReFS unter Windows 8 nicht als „Beta-Feature“. Wenn die Betaversion von Windows 8 abgelöst wird, ist ReFS in einem produktionsfertigen Zustand, mit dem Vorbehalt, dass nichts wichtiger ist als die Zuverlässigkeit der Daten. Daher sind in diesem Punkt, im Gegensatz zu anderen Aspekten des Systems, eine konservative Herangehensweise bei der ersten Bereitstellung und die Tests erforderlich.

Vor diesem Hintergrund werden wir ReFS stufenweise als Weiterentwicklung implementieren: Zunächst als Speichersystem für Windows Server, dann als Speicher für Clients und abschließend als Startvolume. Mit diesem Verfahren haben wir auch in der Vergangenheit bei anderen neuen Dateisystemen gute Erfahrungen gemacht.

Bei unserer ersten Testreihe wird ReFS zunächst als Dateiserver ausgeführt. Wir gehen davon aus, dass die Verwendung von ReFS als Dateiserver unseren Kunden Vorteile bietet, besonders auf einem gespiegelten Storage Space. Wir möchten auch mit unseren Speicherpartnern daran arbeiten, ReFS in deren Speicherlösungen zu integrieren.

Fazit

In Verbindung mit Storage Spaces bildet ReFS für die nächsten zehn Jahre oder länger die Speicherbasis von Windows. Wir sind der Meinung, so die modernste Speicherlösung zu entwickeln. Die Entwicklung von Storage Spaces und ReFS bietet Möglichkeiten für weitere Innovationen, und wir erwarten, dass ReFS als Dateisystem große Verbreitung findet.

– Surendra

Häufig gestellte Fragen:

F) Was bedeutet „ReFS“?

ReFS ist die Abkürzung für Resilient File System (zuverlässiges Dateisystem). Auch wenn es in vielen verschiedenen Bereichen große Qualitäten aufweist, ist die Zuverlässigkeit eine der herausragendsten Funktionen.

F) Wo liegen die Grenzen der Kapazität von ReFS?

In der folgenden Tabelle sind die Kapazitätsgrenzen des Datenträgerformats aufgeführt. Andere Aspekte führen möglicherweise zu einigen Einschränkungen in der Verwendung, wie Systemkonfiguration (z. B. die Speichergröße), Beschränkungen durch verschiedene Systemkomponenten oder auch die Zeit, die zum Auffüllen von Datensätzen erforderlich ist, die Sicherungszeit usw.

Attribute

Vom Datenträgerformat abhängige Grenze

Maximale Größe einer einzelnen Datei

2^64-1 Bytes

Maximale Größe eines einzelnen Volumes

Das Format unterstützt 2^78 Bytes mit einer Clustergröße von 16 KB (2^64 * 16 * 2^10). Die Stapeladressierung von Windows lässt 2^64 Bytes zu

Maximale Anzahl von Dateien in einem Verzeichnis

2^64

Maximale Anzahl von Verzeichnissen in einem Volume

2^64

Maximale Länge des Dateinamens

32K Unicode-Zeichen

Maximale Pfadlänge

32K

Maximale Größe eines beliebigen Speicherpools

4 PB

Maximale Anzahl von Speicherpools in einem System

Unbegrenzt

Maximale Anzahl von Spaces in einem Speicherpool

Unbegrenzt

F) Können Daten zwischen NTFS und ReFS konvertiert werden?

In Windows 8 können Daten nicht am gleichen Speicherort konvertiert werden. Daten können kopiert werden. Hierbei handelt es sich um eine gewünschte Entwurfsentscheidung, bedingt durch die derzeitige Größe von Datensätzen, und bedingt durch den Umstand, dass eine Konvertierung am gleichen Speicherort sehr unpraktisch wäre. Zusätzlich müsste vor und nach der Konvertierung wahrscheinlich der Konstruktionsansatz geändert werden.

F) Kann ich unter Windows Server 8 von ReFS starten?

Nein, das ist nicht implementiert und wird nicht unterstützt.

F) Kann ReFS auf Wechseldatenträgern verwendet werden?

Nein, das ist nicht implementiert und wird nicht unterstützt.

F) Welche Semantik und welche Features von NTFS werden bei ReFS nicht mehr unterstützt?

Folgende Features von NTFS werden von ReFS nicht unterstützt: Benannte Datenströme, Objekt-IDs, kurze Namen, Komprimierung, Verschlüsselung auf Dateiebene (EFS), geringe Datendichte, feste Links, erweiterte Attribute und Datenträgerkontingente.

F) Wie sieht es bei ReFS mit Paritätsspaces aus?

ReFS wird bei den Fehlerzuverlässigkeits-Optionen von Storage Spaces unterstützt. In Windows Server 8 ist die automatische Datenkorrektur nur für gespiegelte Spaces implementiert.

F) Wird Clustering unterstützt?

Failoverclustering wird unterstützt, wobei einzelne Volumes ein Failover computerübergreifend ausführen können. Zusätzlich werden freigegebene Speicherpools in einem Cluster unterstützt.

F) Wie sieht es mit RAID aus? Wie kann ich die Möglichkeiten von ReFS für Striping, Spiegelung oder andere Arten von RAID verwenden? Verfügt ReFS z. B. über die Leseleistung, die für Videos erforderlich ist?

ReFS verwendet die Funktionen für Datenredundanz von Storage Spaces, die Stripespiegelungen und Parität enthalten. Die Leseleistung von ReFS wird wahrscheinlich der von NTFS entsprechen. Beide verfügen in weiten Bereichen über den gleichen relevanten Code. ReFS ist beim Streamen von Daten besonders leistungsfähig.

F) Warum verfügt ReFS nicht über Deduplizierung, Zwischenspeicherung auf zwei Ebenen zwischen DRAM und Speicher und über beschreibbare Snapshots?

ReFS bietet keine eigene Deduplizierung. Ein Vorteil der üblichen und austauschbaren Konstruktion des Dateisystems besteht darin, dass andere Deduplizierungsprodukte in ReFS wie bei NTFS eingebunden werden können.

Bei ReFS ist eine Zwischenspeicherung auf zwei Ebenen nicht implementiert, aber Kunden können Lösungen von Drittanbietern verwenden.

ReFS und VSS stellen, auf ähnliche Weise wie NTFS in Windows-Umgebungen, gemeinsam Snapshots bereit. Bislang unterstützen sie keine beschreibbaren Snapshots oder Snapshots, die größer als 64 TB sind.

Comments

  • Anonymous
    February 08, 2012
    "...Derzeit ist NTFS unter den verbreiteten Dateisystemen das am meisten verwendete und fortschrittlichste..."Diese Aussage ist nicht nur dreist, sondern auch schlichtweg falsch.Die Art und Weise, wie M$ wieder und wieder versucht seinen Usern eine Heile Welt vorzugaukeln widert mich an.
  • Anonymous
    June 26, 2012
    ZFS? ZFS! Das letzte Wort in Sachen Dateisysteme. Am besten gleich mal bei nexenta.com vorbeischauen.
  • Anonymous
    October 27, 2012
    @kohly: deine Aussage sind eigentlich zwei Aussagen. Die Aussage "am meisten verwendet" ist zweifellos richtig, die Aussage "fortschrittlichste" ist nicht objektiv überprüfbar, da es keine objektive Defnition von "fortschrittlich" gibt.Also es handelt sich um eine richtige + eine unüberpprüfbare Aussage, eine falsche Aussage ist nicht dabei.
  • Anonymous
    November 18, 2013
    Welches andere Dateisystem ist denn deiner Meinung nach besser?Und jetzt bitte keine typischen Argumente der Linux-Fricklerfraktion, ich will Fakten hören...
  • Anonymous
    July 28, 2014
    Tja, mal aus der Praxis der "heilen" ReFS-Welt, resiliant wie unverwüstlich, robust.  :lol:Nach einem längeren Test ohne grössere Probleme habe ich dummerweise ein Produktiv-System mit ReFS,bestehend aus 12 HDDs in Parity und Thin-Provisionierung aufgebaut.Von 8 ReFS - Volumina sind nach normalen Neustarts (also kein Stromausfall, Virenbefall, o.ä.) inzwischen 4 Volumes stattmit ReFS-Dateisystem und Dateninhalten, stattdessen nur noch als RAW-Laufwerke mit 0 Bytes vorhanden!Die boardeigene Datenträgerreparatur ist nicht in der Lage, diese Fehler zu beseitigen, zeigt aber zumindest den Fehler an (sic!).Das M$ Technet bemerkt in einem Antwort-Kommentar, dass derzeit keine Lösung für das Problem existiert - na bravo!Mit kostenpflichtigem Recovery über Third Party komme ich hochrechnend in einigen Wochen vlt. wieder an ca. 20 TB Daten.Das wird ein nettes Urlaubsvergnügen.Noch Fragen zu ReFS?
  • Anonymous
    September 12, 2014
    @Stefan: Linux ist ein zuverlässiges, hacksicheres alleskönner OS, das von Fricklern gebaut wurde. Windows ist ein zusammengefrickeltes System, das von Profis gebaut wurde.