Comprendere la struttura del file system ReFS & il recupero dei dati

• Autore:
  
  Anton Kryvoruchko
• Editore:
  
  Mykhailo Miroshnichenko
• Aggiornato: 20.12.2025 9:59

Scopri i segreti di ReFS! ReFS (Resilient File System) è il file system di nuova generazione di Microsoft progettato per affidabilità, scalabilità e integrità dei dati. In questo articolo esaminiamo in dettaglio ReFS, esplorandone la struttura del file system e l’algoritmo di recupero dei dati. Sia che tu sia un amministratore di sistema, un professionista IT o semplicemente curioso sulle tecnologie di storage, questo video ti fornirà una comprensione completa di ReFS e di come gestisce i dati.

Indice dei contenuti

• 1. Introduzione
• 2. Funzioni principali:
• 3. Caratteristiche particolari
• 4. Differenze rispetto a NTFS
• 5. Architettura del file system
• 6. Struttura del file system ReFS
• 7. Attributo di base
• 8. Record
• 9. Rami dell'albero delle directory
• 10. Sottodirectory
• 11. L'algoritmo di ricerca utilizzato da un noto strumento di recupero dati, Hetman Partition Recovery
• Domande e risposte
• Commenti

1. Introduzione

Il nuovo file system, ReFS, è il risultato dell’evoluzione del suo predecessore, NTFS. Supporta i reparse points, una tecnologia precedentemente disponibile solo in NTFS. I reparse points consentono l’implementazione di collegamenti simbolici e punti di mount in Windows.

2. Funzioni principali:

• Integrità dei metadata mediante checksum.
• Integrity streams: metodo di scrittura su disco per protezione aggiuntiva dei dati nel caso in cui una parte del disco risulti danneggiata.
• Allocate on write modello transazionale (noto anche come copy-on-write).
• Limiti di dimensione più elevati per partizioni (volumi), file e directory.
• Pooling e virtualizzazione dello storage per una creazione più semplice dei volumi e gestione del file system.
• Segmentazione dei dati sequenziali nota come data striping per migliorare le prestazioni e fornire ridondanza per tolleranza ai guasti.
• Supporto per la pulizia del disco in background nota come disk scrubbing per protezione contro errori latenti del disco.
• Recupero dei dati nell’area circostante i settori danneggiati del disco.
• Pool di storage condivisi tra macchine per ulteriore tolleranza ai guasti e load balancing.
• Compatibile con le funzionalità ampiamente utilizzate di NTFS.
• Verifica dei dati e correzione automatica.
• Scalabilità massima.
• Il file system non può essere disabilitato grazie all’isolamento dei blocchi settori danneggiati.
• Architettura flessibile che usa la funzionalità Storage Spaces progettata e implementata specificamente per ReFS.

Inoltre, ReFS eredita molte funzionalità da NTFS, inclusi la cifratura BitLocker, le liste di controllo degli accessi – ACL, il journal USN, le notifiche di modifica, i collegamenti simbolici, i junction points, i mount points, i reparse points, gli snapshot di volume, gli ID dei file e gli oplocks.

Naturalmente, i dati su ReFS saranno accessibili ai client tramite le stesse API attualmente utilizzate in tutti i sistemi operativi per l’accesso alle partizioni formattate in NTFS.

3. Caratteristiche particolari

Vai a vedere

Come aprire un disco Linux su macOS — ext4, btrfs, xfs

Caratteristiche del file system ReFS:

• Il file system utilizza checksum per i metadata e può anche utilizzare checksum per i dati dei file. Durante la lettura o la scrittura di un file, il sistema controlla il checksum per verificarne la correttezza. In questo modo la corruzione dei dati può essere monitorata in tempo reale.

• Se il file system rileva dati danneggiati per i quali non esiste una copia alternativa per il recupero, ReFS rimuoverà tali dati dal disco immediatamente. In tal caso non è necessario riavviare il computer o scollegare il supporto, operazioni richieste quando si utilizza NTFS.

• Non è più necessario usare l’utility chkdsk poiché il file system viene corretto automaticamente non appena si manifesta un errore. Il nuovo sistema è inoltre resistente ad altri casi di corruzione dei dati.

• Maggiore affidabilità per l’archiviazione dei dati. ReFS utilizza B+ tree per tutte le strutture su disco, inclusi metadata e dati dei file. La dimensione dei file, il numero di file in una cartella, la dimensione totale del volume e il numero di cartelle in un volume sono limitati da numeri a 64 bit. Lo spazio disco libero è conteggiato da un allocatore gerarchico che include tre tabelle separate per chunk grandi, medi e piccoli. La lunghezza dei nomi di file e dei percorsi è limitata a 32 KiB di caratteri Unicode.

• Il nuovo file system è anche più resistente ai danni che possono verificarsi durante operazioni di aggiornamento. Ad esempio, quando si aggiorna un metadata di file – per esempio il nome di un file – NTFS modifica direttamente il metadata. Se il computer si blocca o si verifica un’interruzione di corrente durante il processo, i dati potrebbero danneggiarsi. Al contrario, quando si aggiorna un metadata in ReFS, viene creata una nuova copia del metadata e il metadata aggiornato viene assegnato al file solo dopo che tutte le nuove informazioni sono state scritte. In questo modo non c’è rischio che il metadata del file venga corrotto. Questo approccio è noto come Copy-on-write.

• ReFS è integrato con la tecnologia di virtualizzazione nota come Storage Spaces, che permette il mirroring e la combinazione di più dispositivi di storage fisici all’interno di un computer o di una rete.

• Tuttavia, questo file system non supporta gli stream nominati, i nomi brevi, la compressione e la cifratura a livello di file (Encrypting File System), così come le transazioni NTFS, i hard links, gli extended attributes e le quote disco.

4. Differenze rispetto a NTFS

• ReFS è più recente e supporta volumi più grandi e nomi di file più lunghi rispetto a NTFS. Sul lungo periodo queste sono evoluzioni importanti.

• In NTFS i percorsi dei file sono limitati a 255 caratteri. Nel frattempo, ReFS supporta oltre 30 mila caratteri (32 768) nel nome di un file.

• NTFS ha una capacità massima teorica di 16 exabyte, mentre ReFS raggiunge l’incredibile valore di 262 144 exabyte. Nella pratica corrente ciò non cambia troppo la situazione, ma rappresenta una riserva per il futuro.

• In ReFS non troverai alcune funzioni di NTFS come la compressione dei dati, l’Encrypting File System, gli hard link, gli extended attributes, la deduplicazione dei dati e le quote disco. Tuttavia, ReFS è compatibile con varie funzionalità: ad esempio, se non è possibile cifrare alcuni dati a livello di file system, ReFS supporta comunque la cifratura con BitLocker.

• Windows 10 non consente di formattare partizioni in ReFS, e al momento ReFS può essere utilizzato solo per gli Storage Spaces dove le sue funzionalità aiutano a proteggere i dati. In Windows Server 2016 è possibile formattare volumi con ReFS invece di NTFS. Tuttavia, non è possibile utilizzare ReFS per un volume di avvio, poiché Windows può avviarsi solo da un disco NTFS.

• Attualmente, ReFS è usato principalmente nelle versioni server di Windows e nelle edizioni Enterprise (nota anche come LTSC).

5. Architettura del file system

Nonostante ReFS e NTFS siano spesso citati come simili, ciò che effettivamente condividono è la compatibilità di alcune strutture di metadata. Il modo in cui la struttura disco di ReFS è implementata differisce completamente dagli altri file system Microsoft.

Gli elementi strutturali principali del nuovo file system sono i B+ tree. Tutti gli elementi della struttura del file system possono essere di tipo a singolo livello (leaf) o multi-livello (tree). Questo approccio consente una maggiore scalabilità per quasi ogni elemento del file system. Unitamente all’indirizzamento a 64 bit reale per tutti gli elementi di sistema, si evitano possibili colli di bottiglia qualora il file system debba essere scalato ulteriormente.

Oltre al record radice del B+ tree, tutti gli altri record hanno una dimensione del blocco di metadata di 16 KB. I nodi intermedi (di indirizzo) hanno una dimensione ridotta (circa 60 byte). Per questo motivo di solito è necessario un numero limitato di livelli dell’albero per descrivere strutture anche molto grandi, il che migliora certamente le prestazioni complessive del sistema.

L’elemento strutturale principale del file system è la Directory presentata sotto forma di B+ tree con chiave il numero dell’oggetto cartella. Contrariamente ad altri file system simili, un file in ReFS non è un elemento chiave separato della Directory, ma esiste solo come record nella cartella che lo contiene. Forse questa caratteristica architetturale spiega perché ReFS non supporta i hard links.

Le leaf delle directory sono record tipizzati. Per un oggetto cartella esistono tre tipi principali di record: un descrittore di directory, un record di indice e un descrittore di oggetto annidato. Tutti questi record sono impacchettati come un B+ tree separato con un identificatore della cartella. La radice di questo albero è una leaf del B+ tree della Directory. Ciò consente di impacchettare virtualmente un numero illimitato di record. A livello inferiore, nelle leaf del B+ tree, si trova primariamente un record descrittore di directory contenente informazioni di base sulla directory come nome, informazioni standard, attributo nome file ecc.

All’interno della directory si trovano poi le cosiddette voci di indice: strutture compatte con i dati degli elementi della directory. Rispetto a NTFS, questi record sono notevolmente più brevi, il che significa che il volume deve memorizzare meno metadata. Gli ultimi elementi sono i record degli item di directory. Per le cartelle questi elementi contengono il nome della cartella, l’identificatore della cartella nella Directory e la struttura delle standard information. Per i file l’identificatore manca ma la struttura contiene tutti i dati di base sul file compresi i frammenti del file nell’albero radice. Pertanto, un file può essere composto da un numero quasi illimitato di frammenti (chunk).

I file su disco sono collocati in blocchi da 64 KB. Sono indirizzati esattamente nello stesso modo dei blocchi di metadata (in cluster da 16 KB). La residenza dei dati dei file su ReFS non è supportata, quindi un file di 1 byte su disco occuperà un intero blocco di 64 KB, con conseguente significativa ridondanza nello storage per i file piccoli. D’altra parte, ciò semplifica la gestione dello spazio libero e il processo di allocazione dei nuovi file risulta molto più veloce.

La dimensione dei metadata di un file system vuoto è circa lo 0,1% della dimensione del file system stesso (ossia circa 2 GB su un volume da 2 TB). Alcuni metadata di base sono duplicati, il che migliora la resilienza ai guasti.

6. Struttura del file system ReFS

È possibile identificare un file system come ReFS dalla seguente firma all’inizio della partizione:

00 00 00 52  65 46 53 00  00 00 00 00  00 00 00 00 ...ReFS.........
46 53 52 53  XX XX XX XX  XX XX XX XX  XX XX XX XX FSRS Copia

Le pagine ReFS hanno lunghezza 0x4000 byte.

Su tutti i sistemi analizzati, il primo numero di pagina è 0x1e (0x78000 byte dopo l'inizio della partizione contenente il file system). Questo è in linea con la documentazione Microsoft che indica che la prima directory dei metadata si trova a un offset fisso sul disco.

Altre pagine contengono varie strutture di sistema, directory e volume e tabelle, nonché versioni journaled di ciascuna pagina.

Il primo byte di ogni pagina è il suo numero di pagina.

I primi 0x30 byte di ogni pagina di metadata formano l'Intestazione della Pagina (Page Header) che appare come segue:

byte  0: XX XX 00 00  00 00 00 00  YY 00 00 00  00 00 00 00
byte 16: 00 00 00 00  00 00 00 00  ZZ ZZ 00 00  00 00 00 00
byte 32: 01 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 Copia

• dword 0 (XX XX) è il numero di pagina che è sequenziale e corrisponde all'offset 0x4000 della pagina;

• dword 2 (YY) è il numero di journal o numero di sequenza;

• dword 6 (ZZ ZZ) è il Virtual Page Number, che non è sequenziale.

L'Object Table, virtual page number 0x02, associa gli identificatori degli oggetti alle pagine in cui risiedono. Qui è possibile osservare un AttributeList composto da record di Key / Value pairs.

Possiamo usarli per cercare l'ID dell'oggetto della directory root e recuperare la pagina in cui risiede:

50 00 00 00 10 00 10 00 00 00 20 00 30 00 00 00 – lunghezza totale / confini chiave e valore
00 00 00 00 00 00 00 00 00 06 00 00 00 00 00 00 – identificatore dell'oggetto
F4 0A 00 00 00 00 00 00 00 00 02 08 08 00 00 00 – identificatore di pagina / flag
CE 0F 85 14 83 01 DC 39 00 00 00 00 00 00 00 00 – somma di controllo
08 00 00 00 08 00 00 00 04 00 00 00 00 00 00 00 Copia

L'entry della object table per la directory root, contenente la sua pagina (0xAF4)

Quando si recuperano pagine per ID o virtual page number, cercare quelle con il numero di sequenza più elevato in quanto sono le copie più recenti del meccanismo di shadow-write.

Le directory, dalla root verso il basso, seguono uno schema coerente. Sono costituite da elenchi sequenziali di strutture i cui parametri di lunghezza sono determinati dal valore della prima word (attributi e liste di attributi).

Gli elenchi sono spesso prefissati da un attributo header che definisce la lunghezza totale degli attributi che seguono, che costituiscono l'elenco.

In entrambi i casi, gli attributi possono essere analizzati iterando sui byte dopo l'intestazione della pagina di directory, leggendo e processando la prima word per determinare il prossimo numero di byte da leggere.

Vari attributi assumono semantiche diverse includendo riferimenti a sottodirectory e file nonché rami verso pagine aggiuntive contenenti più contenuti della directory.

Le strutture in un elenco di directory hanno uno dei seguenti formati:

7. Attributo di base

L'attributo di base più semplice consiste in un blocco la cui lunghezza è indicata all'inizio.

Di seguito un esempio di un attributo tipico:

a8 00 00 00  28 00 01 00  00 00 00 00  10 01 00 00
10 01 00 00  02 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  a9 d3 a4 c3  27 dd d2 01
5f a0 58 f3  27 dd d2 01  5f a0 58 f3  27 dd d2 01
a9 d3 a4 c3  27 dd d2 01  20 00 00 00  00 00 00 00
00 06 00 00  00 00 00 00  03 00 00 00  00 00 00 00
5c 9a 07 ac  01 00 00 00  19 00 00 00  00 00 00 00
00 00 01 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  01 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00 Copia

Qui è possibile trovare una sezione di lunghezza 0xA8 contenente le seguenti quattro timestamp del file. Vedi più avanti:

a9 d3 a4 c3  27 dd d2 01 - 2017-06-04 07:43:20
5f a0 58 f3  27 dd d2 01 - 2017-06-04 07:44:40
5f a0 58 f3  27 dd d2 01 - 2017-06-04 07:44:40
a9 d3 a4 c3  27 dd d2 01 - 2017-06-04 07:43:20
Copia

È ragionevole assumere che o:

• uno dei primi campi in un dato attributo contenga un identificatore che specifica come deve essere analizzato l'attributo, oppure
• il contesto sia determinato dalla posizione dell'attributo nella lista.
• gli attributi corrispondenti al significato dato sono referenziati da questo indirizzo o identificatore

8. Record

Key / Value pairs – i loro valori sono forniti nei primi 0x20 byte dell'attributo. Questi sono utilizzati per sezioni di metadata associate a file i cui nomi sono registrati nelle chiavi e i cui contenuti sono registrati nel valore.

Di seguito un esempio tipico di Record:

40 04 00 00  10 00 1A 00  08 00 30 00  10 04 00 00  @.........0.....
30 00 01 00  6D 00 6F 00  66 00 69 00  6C 00 65 00  0...m.o.f.i.l.e.
31 00 2E 00  74 00 78 00  74 00 00 00  00 00 00 00  1...t.x.t.......
A8 00 00 00  28 00 01 00  00 00 00 00  10 01 00 00  ¨...(...........
10 01 00 00  02 00 00 00  00 00 00 00  00 00 00 00  ................
00 00 00 00  00 00 00 00  A9 D3 A4 C3  27 DD D2 01  ........©Ó¤Ã'ÝÒ.
5F A0 58 F3  27 DD D2 01  5F A0 58 F3  27 DD D2 01  _ Xó'ÝÒ._ Xó'ÝÒ.
A9 D3 A4 C3  27 DD D2 01  20 00 00 00  00 00 00 00  ©Ó¤Ã'ÝÒ. .......
00 06 00 00  00 00 00 00  03 00 00 00  00 00 00 00  ................
5C 9A 07 AC  01 00 00 00  19 00 00 00  00 00 00 00  ..¬............
00 00 01 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00 00 00 00  00 00 00 00  00 00 00 00  00 00 00 00  ................
00 00 00 00  00 00 00 00  01 00 00 00  00 00 00 00  ................
00 00 00 00  00 00 00 00  20 00 00 00  A0 01 00 00  ........ ... ...
D4 00 00 00  00 02 00 00  74 02 00 00  01 00 00 00  Ô.......t.......
78 02 00 00  00 00 00 00  ...(cutoff)               x....... Copia

Qui vediamo i parametri del Record impostati dalla prima riga:

• lunghezza totale - 4 byte = 0x440
• offset chiave - 2 byte = 0x10
• lunghezza chiave - 2 byte = 0x1A
• flag / identificatore - 2 byte = 0x08
• offset valore - 2 byte = 0x30
• lunghezza valore - 2 byte = 0x410

Il record termina dopo il valore, 0x410 byte dopo l'inizio del valore a 0x30, ovvero 0x440 byte dopo l'inizio del record (il che corrisponde alla lunghezza totale).

Il record corrisponde a un file creato sul disco.

Qui il primo attributo nel valore del record è il semplice attributo discusso sopra, contenente le timestamp del file. È seguito dall'Reference Attribute List Header.

Con quelle timbrature, cerchiamo record con valori '0' o '8' per w/ flag. Il valore '4' si verifica spesso; indica un Record Storico, ovvero un Record che è stato successivamente sostituito da un altro.

Poiché i record sono prefissati con la loro lunghezza totale, possono essere considerati una sottoclasse di Attribute.

AttributeList, o header della lista, contiene il blocco di attributi.

A prima vista, sono attributi semplici di lunghezza 0x20 ma, a un'analisi più approfondita, si osserva consistentemente che contengono la lunghezza di un grande blocco di attributi. Dopo aver parsato l'AttributeList bisogna leggere i byte rimanenti nella Lista prima di passare all'attributo successivo.

20 00 00 00  A0 01 00 00  D4 00 00 00  00 02 00 00 - intestazione dell'elenco che specifica la lunghezza totale (0x1A0) e il padding (0xD4)
74 02 00 00  01 00 00 00  78 02 00 00  00 00 00 00
80 01 00 00  10 00 0E 00  08 00 20 00  60 01 00 00
60 01 00 00  00 00 00 00  80 00 00 00  00 00 00 00
88 00 00 00  ... (cutoff) Copia

9. Rami dell'albero delle directory

I Directory Tree Branches sono Attribute Lists dove ogni Attribute corrisponde a un record il cui valore fa riferimento a una pagina che contiene ulteriori contenuti della directory.

Quando si incontra l'header AttributeList con valore di flag 0x301 si deve:

• iterare sugli attributi nella lista,
• parsarli come record,
• usare il dword in ogni valore come la pagina su cui ripetere il processo di attraversamento della directory (ricorsivamente).

I file aggiuntivi e le sottodirectory trovati nelle pagine referenziate devono essere aggiunti all'elenco dei contenuti correnti della directory.

10. Sottodirectory

SubDirectories sono record nella Attribute List della directory la cui chiave contiene il flag Directory Metadata (0x20030) oltre al nome della sottodirectory.

Il valore di questo record è l'identificatore dell'oggetto corrispondente che può essere usato per cercare la pagina contenente la sottodirectory nella object table.

Un tipico record di sottodirectory:

70 00 00 00  10 00 12 00  00 00 28 00  48 00 00 00
30 00 02 00  73 00 75 00  62 00 64 00  69 00 72 00 - qui vediamo la chiave contenente il flag (30 00 02 00) seguito dal nome della directory ("subdir2")
32 00 00 00  00 00 00 00  03 07 00 00  00 00 00 00 - qui vediamo l'identificatore dell'oggetto come prima qword nel valore (0x730)
00 00 00 00  00 00 00 00  14 69 60 05  28 dd d2 01 - qui vediamo i timestamp della directory
cc 87 ce 52  28 dd d2 01  cc 87 ce 52  28 dd d2 01
cc 87 ce 52  28 dd d2 01  00 00 00 00  00 00 00 00
00 00 00 00  00 00 00 00  00 00 00 10  00 00 00 00 Copia

Queste directory sono record la cui chiave contiene un flag (0x10030) seguito dal nome del file.

Il valore è molto più complicato, tuttavia abbiamo scoperto alcuni attributi di base che ci permettono di estrarre timestamp e contenuto dal file system; rimane ancora da dedurre la semantica completa del valore di questo record.

Il valore del File Record è costituito da multipli attributi che appaiono uno dopo l'altro, senza un List Header. Possiamo comunque analizzarli in sequenza dato che tutti gli attributi sono singolarmente prefissati con le loro lunghezze e la lunghezza del valore del file record ci fornisce la dimensione totale del blocco.

Il primo attributo contiene 4 timestamp del file a un offset dato dal quinto byte dell'attributo (anche se questa posizione potrebbe essere coincidente poiché le timestamp potrebbero risiedere in una posizione fissa in questo attributo).

Il secondo attributo sembra essere l'header di una attribute list contenente il File Reference.

In questa singola attribute list, il primo attributo contiene la lunghezza del file, mentre il secondo è l'header per un'altra lista. Questo attributo contiene anche un record il cui valore contiene un riferimento alla pagina dove risiedono effettivamente i contenuti del file.

----------------------------------------
| ...                                  |
----------------------------------------
| File Entry Record                    |
| Key: 0x10030 [FileName]              |
| Value:                           |
| Attribute1: Timestamps              |
| Attribute2:                      |
|   File Reference List Header         |
|   File Reference List Body(Record)   |
|     Record Key: ?                |
|     Record Value:              |
|       File Length Attribute          |
|       File Content List Header       |
|       File Content Record(s)         |
| Padding                              |
----------------------------------------
| ...                                  |
---------------------------------------- Copia

Nonostante la complessità, ogni livello può essere parsato in modo analogo a tutti gli altri attributi e record, facendo attenzione a interpretare gli attributi nei corretti livelli e strutture.

Per quanto riguarda i valori effettivi, la lunghezza del file è sempre visibile a un offset fisso all'interno del suo attributo (0x3c) e il puntatore al contenuto risiede nel secondo qword del record file. Questo puntatore è semplicemente un riferimento alla pagina i cui contenuti del file possono essere letti in modo diretto.

Nonostante ReFS sia caratterizzato da maggiore sicurezza e funzioni efficienti per l'archiviazione dei dati, non può proteggere completamente le informazioni importanti da cancellazioni accidentali, attacchi malware o altri eventi che possono causare perdita di dati. È necessario valutare la probabilità di tali problemi in futuro e predisporre un'utility affidabile in grado di risolvere i problemi con file cancellati.

11. L'algoritmo di ricerca utilizzato da un noto strumento di recupero dati, Hetman Partition Recovery

La soluzione migliore per risolvere rapidamente tali problemi è uno strumento specializzato di recupero dati.

Vai a vedere

Programmi per leggere un disco con file system BTRFS in Windows

Hetman Partition Recovery consente di analizzare lo storage gestito dal file system ReFS mediante l'algoritmo di analisi per firma (signature analysis). Analizzando il dispositivo di memorizzazione settore per settore, il programma trova determinate sequenze di byte e le presenta all'utente. Il recupero dei dati da uno storage ReFS non differisce da quello in un file system NTFS.

Durante la scansione rapida, il programma cerca l'Volume Header che si trova nel settore 0 (mentre la sua copia si trova nell'ultimo settore). L'header contiene le informazioni necessarie per l'analisi successiva - il numero di byte in un settore e il numero di settori in un cluster. Quando questi dati sono raccolti, il programma trova il Superblock, che è memorizzato nel blocco 30. Il superblock ha due copie - una nel secondo blocco dall'estremità del disco e una nel terzo blocco. Dal superblock il programma rileva i riferimenti ai checkpoint: ci sono due checkpoint e possono essere trovati agli indirizzi specificati nel superblock. Seguendo i due indirizzi, il programma trova il Virtual Allocated Clock e utilizza questi dati per determinare quale dei due checkpoint è rilevante in quel momento. Come noto, Windows modifica inizialmente il primo checkpoint e solo se l'operazione ha successo procede a copiare i dati al secondo checkpoint.

Il checkpoint contiene tabelle generali. Da lì, il nostro programma legge il Page Header e il blocco contenente i dati. Questo blocco fornisce puntatori per ogni tabella (ossia link a tutte le tabelle generali).

Per trasformare gli indirizzi virtuali in indirizzi fisici, è necessario trovare la Container Table. Successivamente, l'indirizzo virtuale è usato per trovare la Object ID Table per ottenere tutte le tabelle.

Dopo di ciò il programma ricerca le informazioni pagina per pagina, cercando di identificarne il livello. Se è una leaf di livello 0, i dati ricercati vengono letti. Se non lo è, il programma cercherà il percorso verso un altro livello fino a raggiungere infine il nodo di livello 0 dove risiedono i dati richiesti.

Anche se uno degli elementi nella struttura del file system è danneggiato o corrotto, l'algoritmo usato per l'analisi completa consente al nostro programma di escludere quei collegamenti rotti e raggiungere le informazioni richieste da recuperare.

Il futuro di questo nuovo file system è abbastanza incerto. Microsoft potrebbe perfezionare ReFS per sostituire l'obsoleto NTFS in tutte le versioni di Windows. Al momento, tuttavia, ReFS non può essere usato ovunque ed è applicato solo a compiti specifici.