La tecnologia Storage Spaces introdotta da Microsoft in Windows 8 per consentire di virtualizzare la memoria fisica, dà modo di far uso del thin provisioning in entrambe le piattaforme del nuovo O.S. di Redmond, sia server che desktop.
Storage Spaces andrà pertanto a sostituire Drive Extender e consentirà una modalità di aggregazione dello spazio disponibile su disco, gestito in maniera maggiormente flessibile e a prova di errore.
La virtualizzazione alla base di questa tecnologia permetterà infatti di utilizzare, in teoria, sino al 50% in più dello spazio fisicamente disponibile sulle unità di memorizzazione installate: ciò renderà la gestione dello storage più semplificata e, al tempo stesso, decisamente più flessibile e robusta di quanto non sia avvenuto in passato.
Microsoft, oltre a sviluppare opportune modalità per replicare i dati tra più dischi, ha ora anche deciso di rompere col passato adottando una nuova soluzione al fine di rafforzare in profondità il sistema di memorizzazione dei file.
L’azienda è giunta negli anni passati alla conclusione di quanto sia importante prevenire e determinare in qualche modo l'insorgere della corruzione dei dati nonché di assicurare, qualora sfortunatamente questa avvenga, che il danneggiamento di un file non sia in grado di estendere il danno anche ad altre strutture di dati.
Nel descrivere la tecnologia alla base di Storage Spaces, Microsoft non si era a suo tempo pronunciata sul modo in cui avesse scelto di affrontare queste importanti esigenze.
La risposta è stata ora resa pubblica: si tratta del nuovo file system che sarà abbreviato in ReFS.
In un primo momento, e sino alla fase finale di sviluppo, si sarebbe dovuto chiamare Protogon File System, mentre, nelle ultimissime battute, le necessità di marketing hanno visto cambiare il suo nome in Resilient File System.
Storage Spaces rende semplici le operazioni per far immediatamente fronte al guasto di un disco, ma non è in grado di aiutarci quando su di esso si produrranno dati errati.
Utilizzando due unità in mirroring (Raid 1), Storage Spaces è infatti in grado solamente di indicare se tali unità mostrino delle differenze, ovvero se il controllo di parità fallisca, ma non ha alcuna possibilità di determinare quale delle due unità custodisca i dati corretti e quale quelli in errore.
In caso di cancellazioni accidentali, inoltre, dove i dati mancano del tutto, tale problematica può essere corretta, mentre in caso si verificassero degli errori, ovvero qualora i dati si mostrassero incoerenti tra le due unità costituenti il mirror, tali problematiche allo stato attuale possono soltanto essere rilevate.
ReFS, in buona sostanza, è stato progettato con l’idea di intervenire proprio dove Storage Spaces termina di rendere la sua utilità.
Per proteggere dalla corruzione la propria struttura interna dei dati, i metadati del file system ed opzionalmente anche i dati degli utenti, ReFS attiva delle operazioni tramite le quali giunge a calcolare e memorizzare i checksum inerenti sia ai dati che ai metadati stessi.
Gli algoritmi di checksum utilizzati sono stati progettati in modo tale che anche un piccolo cambiamento in input determini un sostanziale quanto esteso cambiamento nel controllo risultante in output.
Ogni parte di informazioni protetta dal checksum viene a sua volta introdotta in un ulteriore algoritmo di checksum ed il risultato definitivo sarà un numero, il checksum globale: nel caso di ReFS tale checksum è rappresentato da un numero a 64 bit.
Ogni volta che ReFS leggerà i metadati del file system (o i dati che ha introdotto nella protezione tramite checksum) andrà a calcolare il checksum per ogni informazione letta e terminerà questo primo ciclo operativo effettuando in rapida successione un confronto tra ognuno di questi valori con quelli precedentemente memorizzati.
Se i due valori relativi ad ogni singolo dato si mostreranno corrispondenti significherà che il dato è stato letto correttamente, se invece non dovessero corrispondere allora si riceverà la chiara indicazione di un errore.
Questa protezione tramite checksum permetterà, inoltre, di evitare anche tutta una serie di possibili anomalie fin qui riscontrate.
In genere, infatti, durante la scrittura potrebbero venire a presentarsi due ordini di problematiche: le cosiddette "lost writes", dove i dati non giungono ad esser definitivamente scritti su disco, e le più pericolose "misdirected writes", dove un bug nel driver del file system, nel firmware del drive o nel suo controller, va a finalizzare la scrittura su una posizione completamente errata del disco.
Durante la lettura dei dati, invece, la più grande preoccupazione riguarda la cosiddetta "bit rot", che altro non è se non la corruzione di quei dati che, pur essendo al momento della scrittura memorizzati realmente in modo corretto, subiscono solo successivamente la corruzione a causa di una specifica anomalia di memorizzazione.
Tale imponderabile anomalia va purtroppo a verificarsi a livello magnetico proprio sui settori a livello dello strato superficiale del disco interessato.
L'utilizzo di ReFS risolve in definitiva anche il gravoso problema del non sapere su quale disco, di una coppia usata in mirroring, si trovi memorizzato realmente il dato corretto.
Quando viene utilizzato con un mirroring tramite Storage Spaces, infatti, ReFS sarà sostanzialmente in grado di calcolare in modo del tutto indipendente il checksum di ogni unità del mirroring stesso, e quindi di utilizzare questa circostanza per determinare quale delle due unità sarà quella su cui versano i dati corretti e quale invece non lo sarà.
Per migliorare ulteriormente la protezione contro il "bit rot", ReFS risulta anche in grado di effettuare il cosiddetto scrubbing: avrà modo, infatti, di leggere periodicamente tutti i dati e i metadati di un volume, verificherà che i checksum siano sostanzialmente corretti e, se necessario, utilizzerà le corrette copie di mirror per riparare i dati eventualmente corrotti.
ReFS è stato inoltre progettato per fornire una maggiore protezione contro gli insidiosi guasti di alimentazione verificatisi durante le operazioni di scrittura.
L'attuale file system di Windows, NTFS, esegue gli aggiornamenti delle sue strutture di dati e metadati direttamente nella loro locazione originale.
Se un file venisse rinominato, NTFS andrebbe a leggere il settore del disco contenente il nome del file, calcolerebbe un altro settore con il nuovo nome del file, e solo dopo provvederebbe a scrivere tutto il contenuto del precedente settore su di esso.
Questo sta a significare che un intero settore potrebbe subire un danneggiamento se la scrittura venisse interrotta per una mancanza di energia: un problema noto come "torn writes".
In passato questo significava che quantomeno 512 byte (il minimo blocco logico in uso allo stato attuale) avrebbero potuto subire dei danni.
Sui moderni e capienti hard disk, dove il minimo spazio di allocazione è salito a 4096 byte, ReFS funziona in modo diverso: invece di aggiornare i metadati direttamente sulla loro locazione, provvederà a scrivere direttamente i nuovi metadati in una posizione diversa, in modo da prevenire i danni da "torn writes".
Come NTFS, anche ReFS sarà in grado di evitare i cosiddetti guasti in cascata.
Qualora dovesse verificarsi un problema non correggibile (del tipo di corruzione di dati non in mirroring o non aventi un valido mirroring) ReFS sarà in grado di creare una registrazione del problema, e quindi di inibire l'accesso ai soli dati danneggiati, senza per forza di cose mettere offline l'intero volume, provocando una interruzione nell'accesso anche a tutti gli eventuali dati, sebbene corretti, che si trovino sul medesimo volume.
La decisione di modificare in maniera sostanziale e sostituire, a circa venti anni di distanza, il file system NTFS, è stata valutata a lungo nel corso di questi ultimi anni da parte di Microsoft, ma si è reso necessario non prendere tale attività alla leggera.
Un bug in un file system può causare perdite catastrofiche di dati per milioni di persone.
Le due implementazioni di file systems con il testing assolutamente più reale, sono infatti attualmente entrambe di Microsoft: i propri driver NTFS e FAT32 hanno più utenti rispetto a qualsiasi altro driver di file system al mondo.
Questo aspetto non è da sottovalutare: l'enorme quantità di test reali affrontati sta a significare che i bug e le situazioni insolite potenzialmente verificabili su questi due file systems sarebbero scoperte e fixate prima e meglio rispetto ad ogni altro esistente.
Microsoft ha stabilito, pertanto, di non scartare a priori ed in maniera consistente le parti di codice NTFS già super collaudate ed affidabili.
Il driver ReFS prenderà e riutilizzerà infatti alcune parti esistenti del driver NTFS, comprese le sue API complete nonché la gestione della cache e della sicurezza.
Solo la parte più a basso livello del driver verrà sostanzialmente modificata insieme a quelle interessate alla vera e propria organizzazione dei dati su disco.
Comprensibilmente, Microsoft sta adottando un approccio ampiamente conservativo al roll-out a sostegno di ReFS.
Solo Windows Server 8 includerà ReFS, mentre le versioni desktop-oriented di Windows 8 continueranno ancora, nel primo periodo, ad utilizzare l'affidabile NTFS.
Proprio come per Storage Spaces, ReFS non sarà comunque utilizzabile come unità di avvio, significando che solo le future versioni di Windows estenderanno il supporto ReFS anche al client, ed eventualmente, solo in una fase ancora successiva, potranno renderlo avviabile.
Windows Server 8, purtroppo, non metterà a disposizione alcun tool per la conversione dei volumi NTFS esistenti nel nuovo ReFS: la migrazione dei dati preesistenti sarà dunque possibile solo previa creazione e successiva copia in un volume ReFS completamente scratch.
In maniera però davvero sorprendente, ReFS non conterrà una serie di caratteristiche che lo renderanno, se possibile, penalizzante rispetto a NTFS.
La più notevole è quella di non supportare ulteriormente gli "hard links", una funzionalità presente su NTFS e su tutti i file system UNIX, che consente ad un file la possibilità che gli vengano assegnati nomi e percorsi multipli.
Ciò appare particolarmente sorprendente in quanto Windows ha utilizzato da sempre ed in maniera estensiva gli "hard links" per il proprio storage side-by-side, nonché per le differenti versioni di librerie.
Un'altra nuova caratteristica di Windows, già presente a partire da Vista, non verrà inoltre inclusa in ReFS: quella inerente, in particolare, agli aggiornamenti transazionali sui dati degli utenti.
Windows Vista e Windows 7 permettono infatti di apportare al file system operazioni similari a quelle effettuate sui database, in cui una serie di aggiornamenti al file system possono essere portati a temine in modalità atomica, soluzione questa non più percorribile in ReFS.
La crittografia e la compressione a livello di file, inoltre, non verranno supportate in ReFS, né lo saranno i data streams, utili in quanto predisposti anche per lavorare con i client Mac OS X.
In ultimo, verranno abolite anche le quote di archiviazione.
Non tutte le funzionalità che verranno a mancare saranno però così sorprendenti: due caratteristiche che esistono attualmente solo per retrocompatibilità come la generazione di file con nome abbreviato (8.3) per la compatibilità DOS e come il supporto per gli attributi estesi di OS/2 verranno rimossi dal nuovo file system.
Mentre risulta abbastanza accettabile che le caratteristiche di retrocompatibilità possano tranquillamente esser state abbandonate, sarà invece difficile veder da subito accettato ReFS come un vero e proprio sostituto di NTFS, almeno fino a quando non saranno rimpiazzate o risolte le caratteristiche più importanti esistenti in NTFS e, come dicevamo, mancanti nel nuovo ReFS.
Nonostante il suo limitato set di funzionalità e di disponibilità, Microsoft afferma che ReFS potrà esser pronto per gli ambienti di produzione già al lancio di Windows Server 8, in quanto lo sviluppo allo stato attuale ha decisamente oltrepassato la fase di beta testing.
Infatti, oltre al riutilizzo del codice esistente ed affidabile di NTFS, l'azienda ha anche provveduto a testare ampiamente il nuovo file system sostenendo che ha già raggiunto un "livello di robustezza senza precedenti per un file system di Microsoft".
Sebbene, quindi, abbia mostratot nel passato di continuare a migliorare NTFS sia in Windows Vista che in Windows 7, Microsoft ha dato conferma con queste soluzione di aver guardato comunque sempre oltre e, nello specifico, con particolare occhio di riguardo verso ZFS di Oracle e BtrFS di Linux.
Entrambi questi file system, infatti, si sono mostrati nel recente passato estremamente stabili, offrendo già una gestione altamente flessibile del sistema di memorizzazione e, aspetto ancora più importante, una tolleranza ai guasti integrata ed affidabile tanto da risultare allo stato dell'arte per ricoprire il ruolo di file system di tipo mainstream.
Storage Spaces avrà un lungo cammino verso la fornitura di Windows per la gestione di volumi di capacità elevata e ReFS andrà a colmare la maggior parte delle caratteristiche ancora lacunose, aggiungendo una struttura di file system che è fondamentalmente più robusta e a salvaguardia dei dati, rispetto quella che NTFS è stata in grado di offrire durante il proprio ciclo di vita.
