Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
La clonazione di blocchi indica al file system di copiare un intervallo di byte di file per conto di un'applicazione, in cui il file di destinazione può essere uguale o diverso dal file di origine. Le operazioni di copia tradizionali, purtroppo, sono costose poiché attivano costose operazioni di lettura e scrittura sui dati fisici sottostanti.
La clonazione di blocchi in ReFS, tuttavia, esegue copie come operazione di metadati a basso costo anziché attività di lettura e scrittura nei dati dei file. Poiché ReFS consente a più file di condividere gli stessi cluster logici (percorsi fisici all’interno di un volume), le operazioni di copia devono solo eseguire il nuovo mapping di un'area di un file in una posizione fisica separata, convertendo un'operazione fisica costosa in un'operazione rapida e logica. In questo modo le copie possono essere completate più velocemente e generare meno I/O nella risorsa di archiviazione sottostante. Questo miglioramento avvantaggia anche i carichi di lavoro di virtualizzazione, poiché le operazioni di unione dei checkpoint .vhdx vengono notevolmente accelerate quando si utilizzano operazioni di clonazione a blocchi. Inoltre, poiché più file possono condividere gli stessi cluster logici, i dati identici non vengono archiviati fisicamente più volte, migliorando la capacità di archiviazione.
Funzionamento
La clonazione di blocchi in ReFS converte un'operazione di dati di file in un'operazione di metadati. Per eseguire questa ottimizzazione, ReFS introduce i conteggi dei riferimenti nei relativi metadati per le aree copiate. Questo conteggio dei riferimenti registra il numero di aree di file distinte che fanno riferimento alle stesse aree fisiche. Ciò consente a più file di condividere gli stessi dati fisici:
Mantenendo un conteggio dei riferimenti per ogni cluster logico, ReFS non interrompe l'isolamento tra i file: le scritture nelle aree condivise attivano un meccanismo di allocazione in scrittura, in cui ReFS alloca una nuova area per la scrittura in ingresso. Questo meccanismo mantiene l'integrità dei cluster logici condivisi.
Esempio
Si supponga che siano presenti due file, X e Y, in cui ogni file è composto da tre aree e ogni area è mappata a cluster logici separati.
Due file ciascuno con tre aree distinte che mappano su aree che hanno un conteggio dei riferimenti pari a 1.
Si supponga ora che un'applicazione esegua un'operazione di clonazione di blocchi dal file X al file Y, per le aree A e B da copiare in corrispondenza dell'offset dell'area E. Il risultato sarebbe il seguente stato del file system:
Questo stato del file system rivela una duplicazione riuscita dell'area clonata del blocco. Poiché ReFS esegue questa operazione di copia aggiornando solo i mapping VCN a LCN, non è stato letto alcun dato fisico così come non sono stati sovrascritti i dati fisici nel file Y. I file X e Y condividono ora cluster logici, riflessi dai conteggi dei riferimenti nella tabella. Poiché non sono stati copiati dati fisicamente, ReFS riduce il consumo di capacità nel volume.
Si supponga ora che l'applicazione tenti di sovrascrivere l'area A nel file X. ReFS duplica l'area condivisa, aggiorna i conteggi dei riferimenti in modo appropriato ed esegue la scrittura in ingresso nell'area appena duplicata. In questo modo si garantisce che l'isolamento tra i file venga mantenuto.
Dopo la modifica della scrittura, l'area B è ancora condivisa da entrambi i file. Se l'area A era più grande di un cluster, solo il cluster modificato sarebbe stato duplicato e la parte rimanente sarebbe rimasta condivisa.
Restrizioni e osservazioni sulle funzionalità
- L'area di origine e di destinazione deve iniziare e terminare in corrispondenza di un limite del cluster.
- L'area clonata deve avere una lunghezza inferiore a 4 GB.
- Il numero massimo di aree di file che possono essere mappate alla stessa area fisica è 8175.
- L'area di destinazione non deve estendersi oltre la fine del file. Se l'applicazione vuole estendere la destinazione con dati clonati, deve prima richiamare SetEndOfFile.
- Se le aree di origine e di destinazione si trovano nello stesso file, non devono sovrapporsi. (l'applicazione potrebbe essere in grado di procedere suddividendo l'operazione di clonazione del blocco in più cloni di blocchi che non si sovrappongono più).
- I file di origine e di destinazione devono trovarsi nello stesso volume ReFS.
- I file di origine e di destinazione devono avere la stessa impostazione dei Flussi di integrità.
- Se il file di origine è di tipo sparse, anche il file di destinazione deve essere di tipo sparse.
- L'operazione di clonazione del blocco interrompe i blocchi opportunistici condivisi (noti anche come blocchi opportunistici di livello 2).
- Il volume ReFS deve essere stato formattato con Windows Server 2016 e, se è in uso il clustering di failover, il livello di funzionalità del clustering deve essere Windows Server 2016 o versione successiva al momento della formattazione.
- A partire dalle build di Windows 11 24H2 e Windows Server 2025, la clonazione dei blocchi viene eseguita in modo nativo nelle operazioni di copia di Windows supportate.