1. 03.10.2012
NTFS oder ReFS?
Oliver.Ryf@digicomp.ch

2. Inhalt
03.10.2012
 NTFS
 ReFS
 Fazit?

3. 03.10.2012
Umfrage

4. 03.10.2012
NTFS
New Technology(!) File System

5. Welche Probleme macht Ihnen NTFS heute?
03.10.2012
 Management?
 Maintenance?
 Security?
 Performance?
 Stability?

6. NTFS und Checkdisk vorher
03.10.2012
 Das NTFS «Health-Model» war eher simpel
 Entweder war das Filesystem gesund oder nicht
 Zum Reparieren musste das Filesystem offline
genommen werden
 Das dauerte solange, bis alle Fehler behoben sind
 Downtime ist proportional zu der Anzahl Dateien

7. Checkdisk in Windows Server 2008/R2
03.10.2012
 Checkdisk Performance wurde zwar laufend
verbessert und optimiert, aber
 Gleichzeitig wurden Volumes immer grösser

8. Checkdisk und Kundenwunschliste
03.10.2012
 Downtime = 0 bei hochverfügbaren Systemen
 Health-State muss jederzeit abrufbar sein
 Einfache Lösung von Diskproblemen

9. File system health redone
03.10.2012

10. NTFS - Key Design Changes
03.10.2012
 Online self-healing
 Online verification
 Neuer Service – Spot Verification Service
 Online identification and logging
 Scheduled Task – Probleme werden geloggt
 Precise and rapid correction
 Geloggte Probleme können bei passender
Gelegenheit behoben werden
CHKDSK /Spotfix

11. Checkdisk Spotfix
03.10.2012

12. Das neue NTFS Health Model
03.10.2012
 Online and healthy
 Online spot verification needed
 Online scan needed
 Spot fix needed

13. Scheduled Task
03.10.2012

14. Integration ins Action Center
03.10.2012

15. 03.10.2012
ReFS
Resilient File System

16. Ziele von ReFS
03.10.2012
 Hohe Kompatibilität zu NTFS
 Überprüfen und automatisches Korrigieren von
Daten
 Hohe Skalierbarkeit
 Filesystem ist nie Offline
 Zusammenarbeit mit Storage Spaces

17. NTFS / ReFS Kompatibilität
03.10.2012

18. Ein paar Zahlen
03.10.2012
 ReFS unterstützt lange Dateinamen und Pfade
 Wirkliche lange!!!
 Dateinamen – 32K, 32’768 unicode characters
 Pfadlänge – 32K
 Theoretische Maximalgrösse einer Datei:
 2^64-1 Byte
 entspricht rund 18 Trillionen Byte oder 16 Exabyte.
 Pro Verzeichnis theoretisch bis zu 18 Trillionen
Dateien und in einem Volume ebenso viele
Verzeichnisse gespeichert werden.

19. Unterschied zu NTFS
03.10.2012
 Alle ReFS Metadaten erstellen eine 64-bit
Checksumme, welche separate gespeichert wird
 NTFS Metadata werden In-Place aktualisiert
 Problem bei einem Stromausfall
 «Torn Writes» sind die Folge
 BSOD oder unleserliche Daten beim Booten

20. Integrity Streams
03.10.2012
 ReFS verwendet «Integrity Streams» (Copy-on-
Write)
 Bevor Änderungen an den Metadaten erfolgen
wird eine Kopie der entsprechenden Daten
gemacht
 Ist nicht auf jedem Volume sinnvoll
D:>format /fs:refs /q /i:enable <volume>

21. Bit Rot
03.10.2012
 Scrubbing

22. 03.10.2012
 “We perform significant testing where power is
withdrawn from the system while the system is
under extreme stress, and once the system is back
up, all structures are examined for correctness. This
testing is the ultimate measure of our success. We
have achieved an unprecedented level of
robustness in this test for Microsoft file systems.
We believe this is industry-leading and fulfills our
key design goals.”
Surendra Verma, Development Manager, Storage
and File Systems, Microsoft

23. ReFS und Storage Spaces/Pools
03.10.2012
 ReFS arbeitet mit Storage Spaces um Problem noch
besser zu Erkennen und zu Reparieren
 ReFS kann mit Storage Spaces verwendet werden
 Storage Spaces können ReFS nutzen
 Zusammen funktionieren sie besser!
 ReFS verwendet Metadata Checksums
 Korrupte Daten können bei Fehler automatisch
wiederhergestellt warden
 Einzelne Storage Pools können maximal 4 Petabyte
umfassen.

24. Bit Rot
03.10.2012
 Mit dem Lauf der Zeit oder aus technischen
Gründen können Teile einer Disk Defekte aufweisen
 “Scrubbing” ist ein Task, der auf mirrored Storage
Spaces alle redundanten Daten überprüft inkl.
 Metadaten
 Integrity Streams
 Bei fehlerhaften Checksummen werden die
korrupte Daten automatisch durch “guten” Daten
wiederhergestellt
INTEGRITY.EXE

25. Was passiert bei Data Corruption
03.10.2012
 Data Corruptions in NTFS haben Auswirkungen auf
das komplette Volume
 Volume muss Offline genommen werden
 Checkdisk findet und repariert den Fehler
 Downtime ist die Konsequenz

26. ReFS Salvaging
03.10.2012
 «Salvaging» kann einzelne korrupte Daten aus dem
Namespace des Volumes entfernen
 Korrupte Daten haben somit keine Einfluss auf die
Verfügbarkeit «Gesunder Daten»
 Passiert in der Regel in weniger als einer Sekunde
 Korrupte Daten können dann vom Admin
wiederhergestellt werden
 ReFS Volumes bleiben online auch bei ireparablen
Schäden

27. 03.10.2012
ReFS
deprecated Features

28. Was wird nicht mehr unterstützt
03.10.2012
 Named Streams
 Object IDs
 Short Names
 Compression
 File level encryption (EFS)
 User Data Transactions
 Sparse
 Hard-links
 Extended Attributes
 Quota

29. 03.10.2012
Was kann ReFS nicht?

30. NTFS exclusive
03.10.2012
 Data Deduplication
 Second Level Caching zwischen DRAM&Storage
 Writable Snapshots

31. 03.10.2012
Warum nicht?

32. Microsoft Statements
03.10.2012
 ReFS does not itself offer deduplication. One side
effect of its familiar, pluggable, file system
architecture is that other deduplication products
will be able to plug into ReFS the same way they do
with NTFS.
 ReFS does not explicitly implement a second-level
cache, but customers can use third-party solutions
for this.
 ReFS and VSS work together to provide snapshots
in a manner consistent with NTFS in Windows
environments. For now, they don’t support writable
snapshots or snapshots larger than 64TB.

33. 03.10.2012
The Best of the Bests of the…?

34. Der Vergleich aus der Sicht eines Xlers ;-)
03.10.2012

35. 03.10.2012
Migrieren, oder?

36. 03.10.2012
Fragen?