Il nuovo file system ReFS di Microsoft è apparso originariamente sui server che eseguono Windows 2012. E solo in seguito è stato incluso in Windows 10, dove può essere utilizzato solo come parte della funzione del pool di dischi Storage Spaces (tecnologia di virtualizzazione dello spazio su disco). V Windows Server 2016 Microsoft promette di migliorare significativamente il lavoro con il file system ReFS, inoltre, secondo le voci che vengono stampate, ReFS potrebbe arrivare a sostituire il file system NTFS obsoleto nella nuova versione di Windows 10, che è orgogliosamente chiamato Windows 10 Pro (per PC avanzati).
Ma cos'è esattamente ReFs, in che cosa differisce dal file system NTFS attualmente utilizzato e quali vantaggi comporta?
In breve, è stato progettato come un file system a tolleranza di errore. ReFS è un nuovo file system creato utilizzando il codice ed è essenzialmente un file system NTFS riprogettato e migliorato. Questi includono una migliore affidabilità dell'archiviazione delle informazioni, funzionamento stabile in modalità di stress, dimensioni di file, volumi, directory, il numero di file in volumi e directory è limitato solo dalla dimensione dei caratteri di un numero a 64 bit. Ricordiamo che a questo valore, la dimensione massima del file sarà 16 exbibyte e la dimensione del volume sarà 1 jobibyte.
ReFS attualmente non è un sostituto di NTFS. Ha i suoi vantaggi e svantaggi. Ma non puoi, diciamo, formattare un'unità e installarci una nuova copia di Windows come faresti su NTFS.
ReFS utilizza i checksum per i metadati e può anche utilizzare i checksum per i file di dati. Ogni volta che leggi o scrivi file, ReFS controlla il checksum per assicurarsi che sia corretto. Ciò significa che il filesystem stesso ha uno strumento in grado di rilevare al volo i dati danneggiati.
ReFS è integrato con la funzionalità Spazi di archiviazione. Se configuri il mirroring abilitato per ReFS, Windows rileverà facilmente il danneggiamento del file system e lo risolverà automaticamente copiando i dati con mirroring sull'unità danneggiata. Questa funzionalità è disponibile sia per Windows 10 che per Windows 8.1.
Nel caso in cui ReFS rilevi dati danneggiati e non sia richiesta una copia dei dati da ripristinare, il file system è in grado di eliminare immediatamente i dati danneggiati dal disco. Ciò non richiede un riavvio del sistema, a differenza di NTFS.
ReFS non controlla solo l'integrità dei file durante la scrittura/lettura. Esamina automaticamente l'integrità dei dati controllando regolarmente tutti i file sul disco, identificando e correggendo i dati danneggiati. In questo caso, non è necessario eseguire periodicamente il comando chkdsk per controllare il disco.
Il nuovo file system è anche resistente alla corruzione dei dati in altri modi. Ad esempio, stai aggiornando i metadati di un file (lascia che sia il nome del file). Il file system NTFS modifica direttamente i metadati del file. Se il sistema si arresta in modo anomalo (spegnimento) in questo momento, è molto probabile che il file venga danneggiato. Quando modifichi i metadati, ReFS crea una nuova copia dei metadati. Il file system non sovrascrive i vecchi metadati, ma li scrive in un nuovo blocco. Ciò impedisce che il file venga danneggiato. Questa strategia è chiamata "copia su scrittura" (copia su scrittura, selezione su scrittura). Questa strategia è disponibile in altri file system moderni come ZFS e BtrFS su Linux, nonché nel nuovo file system APFS di Apple.
ReFS è più moderno di NTFS e supporta quantità di dati molto maggiori e nomi di file più lunghi. A lungo termine, questo è molto importante.
Nel file system NTFS, il percorso del file è limitato a 255 caratteri. In ReFS, il numero massimo di caratteri è già di ben 32768 caratteri. Attualmente esiste un'opzione in Windows 10 per disabilitare l'elemento carattere per NTFS. Sui volumi disco ReFS, questo limite è disabilitato per impostazione predefinita.
ReFS non supporta i nomi di file DOS 8.3. Sui volumi NTFS sono disponibili le cartelle “CProgram Files”, “CProgra`1”. Sono necessari per la compatibilità con il vecchio Software. In ReFS, non troverai le cartelle a cui siamo abituati. Sono stati rimossi.
La quantità massima teorica di dati supportata da NTFS è 16 exabyte, ReFS supporta fino a 262144 exabyte. Ora quel numero sembra enorme.
Gli sviluppatori non si sono prefissati l'obiettivo di creare un file system più produttivo. Hanno creato un sistema più ottimizzato.
Ad esempio, se utilizzato con un array, ReFS supporta l'ottimizzazione del livello in tempo reale. Si dispone di un pool di unità composto da due unità. Il primo disco viene selezionato con l'aspettativa di un accesso rapido e ad alta velocità ai dati. Il secondo disco viene selezionato con il criterio dell'affidabilità, per l'archiviazione dei dati a lungo termine. In background, ReFS sposterà automaticamente grandi blocchi di dati su un'unità più lenta, garantendo così l'affidabilità dell'archiviazione dei dati.
In Windows Server 2016, gli sviluppatori hanno aggiunto uno strumento per migliorare le prestazioni attraverso determinate funzionalità macchine virtuali. Ad esempio, ReFS supporta la copia a blocchi, che velocizza il processo di copia delle macchine virtuali e unisce i checkpoint. Per creare una copia di una macchina virtuale, ReFS crea una nuova copia dei metadati su disco e punta a un collegamento ai dati copiati su disco. In questo modo, con ReFS, più file possono fare riferimento agli stessi dati sottostanti su disco. Dopo aver lavorato con la macchina virtuale e aver modificato i dati, questi vengono scritti su disco in una posizione diversa, mentre i dati originali della macchina virtuale rimangono sul disco. Ciò accelera notevolmente il processo di creazione delle copie e riduce il carico sul disco.
ReFS supporta "Sparse VDL" (file sparsi). Un file sparse è un file in cui una sequenza di byte nulli è stata sostituita con informazioni su quella sequenza (un elenco di buchi). I buchi sono una certa sequenza di zero byte all'interno di un file che non vengono scritti su disco. Le informazioni sulla buca stessa sono memorizzate nei metadati del file system.
La tecnologia di supporto dei file sparsi consente di scrivere rapidamente zeri su un file di grandi dimensioni. Ciò accelera notevolmente il processo di creazione di un nuovo file virtuale vuoto. disco rigido dimensione fissa (VHD). La creazione di un tale file in ReFS richiede alcuni secondi, mentre in NTFS tale operazione richiede fino a 10 minuti.
Tutto ciò che abbiamo descritto sopra suona bene, ma non sarai in grado di passare a ReFS da NTFS. Windows non può avviarsi da un file system ReFS mentre richiede NTFS.
ReFS manca di molte delle tecnologie disponibili in NTFS. Ad esempio, compressione e crittografia del file system, collegamenti reali, attributi estesi, deduplicazione dei dati e quote del disco. Allo stesso tempo, a differenza di NTFS, ReFS supporta la tecnologia di crittografia dei dati completa - BitLocker.
Su Windows 10, non sarai in grado di formattare una partizione di unità con ReFS. Il nuovo file system è disponibile solo per i sistemi di archiviazione in cui la sua funzione principale è proteggere i dati dalla corruzione. In Windows Server 2016, sarai in grado di formattare una partizione del disco in ReFS. Potrai usarlo per eseguire macchine virtuali. Ma non sarai in grado di selezionarlo come unità di avvio. Windows si avvia solo dal file system NTFS.
Non è chiaro quale futuro abbia in serbo Microsoft per il nuovo file system. Forse un giorno sostituirà completamente NTFS in tutte le versioni di Windows. Ma per ora, ReFS può essere utilizzato solo per determinate attività.
Molto è stato detto sopra a sostegno del nuovo sistema operativo. Vengono descritti i pro e i contro. Propongo di fermarmi e fare un bilancio. Per quali scopi puoi, e forse devi usare ReFS.
In Windows 10, ReFS è applicabile solo in combinazione con il componente Spazi di archiviazione. Assicurati di formattare il tuo disco dedicato per l'archiviazione dei dati in ReFS, non NTFS. In questo caso, puoi apprezzare appieno l'affidabilità dell'archiviazione dei dati.
In Windows Server, sarai in grado di formattare la partizione in ReFS utilizzando lo strumento standard di Windows nella Console di gestione del disco. Si consiglia di formattarlo in ReFS se si utilizzano server virtuali. Ma ricorda che l'unità di avvio deve essere formattata come NTFS. L'avvio dal file system ReFS non è supportato dai sistemi operativi Windows.
Il nuovo file system ReFS e Windows 10| 2017-06-28 06:34:15 | Super utente | Software di sistema | https://site/media/system/images/new.png | Il nuovo file system di Microsoft ReFS sostituisce l'obsoleto NTFS Quali sono i vantaggi di ReFS e come si differenzia da NTFS | refs, refs o ntfs, refs windows 10, refs file system, nuovi file system, ntfs system, ntfs file system
Perché uno smartphone non può eseguire programmi da una scheda di memoria? In che modo ext4 è fondamentalmente diverso da ext3? Perché un'unità flash dura più a lungo se è formattata in NTFS e non in FAT? Qual è il problema principale con F2FS? Le risposte si trovano nella struttura dei file system. Parleremo di loro.
I file system definiscono come vengono archiviati i dati. Determinano quali limitazioni incontrerà l'utente, quanto saranno veloci le operazioni di lettura e scrittura e per quanto tempo l'unità funzionerà senza guasti. Ciò è particolarmente vero per gli SSD economici e i loro fratelli minori: le unità flash. Conoscendo queste funzionalità, puoi ottenere il massimo da qualsiasi sistema e ottimizzarne l'utilizzo per attività specifiche.
Devi scegliere il tipo e i parametri del file system ogni volta che devi fare qualcosa di non banale. Ad esempio, vuoi velocizzare le operazioni sui file più frequenti. A livello di filesystem, questo può essere ottenuto in vari modi: l'indicizzazione fornirà ricerche veloci e la pre-prenotazione dei blocchi liberi renderà più facile sovrascrivere i file che cambiano frequentemente. Pre-ottimizzazione dei dati in memoria ad accesso casuale ridurrà la quantità di I/O richiesta.
Tali proprietà dei moderni file system come la scrittura pigra, la deduplicazione e altri algoritmi avanzati aiutano ad aumentare il tempo di attività del funzionamento. Sono particolarmente rilevanti per SSD economici con chip di memoria TLC, unità flash e schede di memoria.
Esistono ottimizzazioni separate per array di dischi di diversi livelli: ad esempio, il file system può supportare il mirroring del volume semplificato, gli snapshot istantanei o il ridimensionamento dinamico senza disabilitare il volume.
Gli utenti lavorano principalmente con il file system offerto per impostazione predefinita dal sistema operativo. Raramente creano nuove partizioni del disco e ancor meno spesso pensano alle loro impostazioni: basta usare le impostazioni consigliate o persino acquistare supporti preformattati.
Per i fan di Windows, tutto è semplice: NTFS su tutte le partizioni del disco e FAT32 (o lo stesso NTFS) sulle unità flash. Se è presente un NAS e in esso viene utilizzato un altro file system, per la maggior parte questo rimane oltre la percezione. Si collegano semplicemente ad esso tramite la rete e scaricano i file, come da una scatola nera.
Sui gadget mobili con Android, ext4 si trova più spesso nella memoria interna e FAT32 su schede microSD. A Yabloko non importa affatto che tipo di file system hanno: HFS+, HFSX, APFS, WTFS... per loro ci sono solo bellissime icone di cartelle e file disegnate dai migliori designer. Gli utenti Linux hanno la scelta più ricca, ma puoi collegare il supporto per i file system del sistema operativo non nativi sia in Windows che in macOS, ne parleremo più avanti.
Sono stati creati oltre cento diversi file system, ma poco più di una dozzina possono essere definiti rilevanti. Sebbene fossero tutti progettati per le loro applicazioni specifiche, molti sono finiti per essere correlati a livello concettuale. Sono simili perché usano lo stesso tipo di struttura di rappresentazione dei (meta)dati - B-trees ("b-trees").
Come ogni sistema gerarchico, il B-tree inizia con una voce radice e poi si ramifica fino agli elementi finali: voci individuali sui file e sui loro attributi, o "foglie". Il punto principale della creazione di una tale struttura logica era accelerare la ricerca di oggetti del file system su grandi array dinamici, come dischi rigidi con una capacità di diversi terabyte o array RAID ancora più impressionanti.
Gli alberi B richiedono molti meno accessi al disco rispetto ad altri tipi di alberi bilanciati per eseguire le stesse operazioni. Ciò si ottiene grazie al fatto che gli oggetti finali negli alberi B sono posizionati gerarchicamente alla stessa altezza e la velocità di tutte le operazioni è semplicemente proporzionale all'altezza dell'albero.
Come altri alberi equilibrati, gli alberi B hanno la stessa lunghezza di percorsi dalla radice a qualsiasi foglia. Invece di crescere, si ramificano di più e si allargano: tutti i punti di diramazione in un albero B memorizzano molti riferimenti a oggetti figlio, rendendoli facili da trovare in meno colpi. Un gran numero di puntatori riduce il numero di operazioni sul disco più lunghe: posizionamento della testina durante la lettura di blocchi arbitrari.
Il concetto di B-tree è stato formulato negli anni Settanta e da allora è stato oggetto di vari miglioramenti. In una forma o nell'altra, è implementato in NTFS, BFS, XFS, JFS, ReiserFS e una varietà di DBMS. Tutti loro sono parenti in termini di principi di base dell'organizzazione dei dati. Le differenze riguardano dettagli, spesso piuttosto importanti. Anche lo svantaggio dei file system correlati è comune: sono stati tutti creati per funzionare con i dischi anche prima dell'avvento degli SSD.
Le unità a stato solido stanno gradualmente sostituendo le unità disco, ma finora sono costrette a utilizzare file system legacy a loro estranei. Sono costruiti su array di memoria flash, i cui principi differiscono da quelli dei dispositivi a disco. In particolare, la memoria flash deve essere cancellata prima di essere scritta e questa operazione nei chip NAND non può essere eseguita a livello di singola cella. È possibile solo per blocchi di grandi dimensioni nel loro insieme.
Questa limitazione è dovuta al fatto che nella memoria NAND tutte le celle sono combinate in blocchi, ognuno dei quali ha una sola connessione comune al bus di controllo. Non entreremo nei dettagli dell'organizzazione della pagina e dipingeremo l'intera gerarchia. Ciò che è importante è il principio delle operazioni di gruppo con le celle e il fatto che le dimensioni dei blocchi di memoria flash sono generalmente maggiori dei blocchi indirizzati in qualsiasi file system. Pertanto, tutti gli indirizzi e i comandi per le unità con flash NAND devono essere tradotti attraverso il livello di astrazione FTL (Flash Translation Layer).
I controller di memoria flash forniscono compatibilità con la logica dei dispositivi disco e supporto per i comandi dell'interfaccia nativa. Di solito FTL è implementato nel loro firmware, ma può (parzialmente) essere eseguito sull'host, ad esempio Plextor scrive driver per la velocità di scrittura per i suoi SSD.
Non si può assolutamente fare a meno di FTL, poiché anche scrivere un bit in una cella specifica porta al lancio di tutta una serie di operazioni: il controllore trova il blocco contenente la cella desiderata; il blocco viene letto per intero, scritto nella cache o nello spazio libero, quindi cancellato nella sua interezza, dopodiché viene sovrascritto con le modifiche necessarie.
Questo approccio ricorda la vita quotidiana dell'esercito: per dare un ordine a un soldato, il sergente forma una formazione generale, chiama il poveretto fuori dai giochi e ordina agli altri di disperdersi. Nell'ormai rara memoria NOR, l'organizzazione era spetsnaz: ogni cellula era controllata indipendentemente (ogni transistor aveva un contatto individuale).
I controller hanno sempre più compiti, perché con ogni generazione di memoria flash, il processo di produzione della sua produzione diminuisce per aumentare la densità e ridurre il costo di archiviazione dei dati. Insieme agli standard tecnologici, si riduce anche la vita stimata dei chip.
I moduli con celle SLC a livello singolo avevano una risorsa dichiarata di 100mila cicli di riscrittura e anche di più. Molti di loro funzionano ancora in vecchie unità flash e schede CF. Un MLC di classe enterprise (eMLC) ha richiesto una risorsa compresa tra 10 e 20 mila, mentre per un normale MLC di livello consumer è stimato a 3-5 mila. Questo tipo di memoria viene attivamente spremuto dalle TLC ancora più economiche, la cui risorsa raggiunge a malapena i mille cicli. Mantenere la durata della memoria flash a un livello accettabile è dovuto a trucchi software e i nuovi file system stanno diventando uno di questi.
Inizialmente, i produttori presumevano che il file system non fosse importante. Il controller stesso deve servire un array di breve durata di celle di memoria di qualsiasi tipo, distribuendo il carico tra di loro in modo ottimale. Per il driver del file system, imita un normale disco ed esegue esso stesso ottimizzazioni di basso livello su qualsiasi accesso. Tuttavia, in pratica, l'ottimizzazione per diversi dispositivi varia da magica a fittizia.
Negli SSD aziendali, il controller integrato è un piccolo computer. Ha un enorme buffer di memoria (mezzo gig o più) e supporta molti metodi per migliorare l'efficienza del lavoro con i dati, il che consente di evitare cicli di scrittura non necessari. Il chip organizza tutti i blocchi nella cache, esegue scritture pigre, esegue la deduplicazione al volo, riserva alcuni blocchi e ne cancella altri in background. Tutta questa magia avviene in modo assolutamente impercettibile per il sistema operativo, i programmi e l'utente. Con un tale SSD, non importa quale file system viene utilizzato. Le ottimizzazioni interne hanno un impatto molto maggiore sulle prestazioni e sulle risorse rispetto a quelle esterne.
Negli SSD economici (e ancor di più nelle unità flash) mettono controller molto meno intelligenti. La cache al loro interno è troncata o assente e le tecnologie server avanzate non vengono affatto utilizzate. Nelle schede di memoria, i controller sono così primitivi che spesso si afferma che non esistono affatto. Pertanto, per i dispositivi economici con memoria flash, i metodi esterni di bilanciamento del carico rimangono rilevanti, principalmente con l'aiuto di file system specializzati.
Uno dei primi tentativi di scrivere un file system che tenesse conto dei principi di organizzazione della memoria flash è stato JFFS - Journaling Flash File System. Inizialmente, questo sviluppo della società svedese Axis Communications era incentrato sul miglioramento dell'efficienza della memoria dei dispositivi di rete prodotti da Axis negli anni Novanta. La prima versione di JFFS supportava solo la memoria NOR, ma già nella seconda versione faceva amicizia con la NAND.
JFFS2 è attualmente di uso limitato. È ancora utilizzato principalmente nelle distribuzioni Linux per sistemi embedded. Può essere trovato in router, telecamere IP, NAS e altri habitué dell'Internet delle cose. In generale, ovunque sia richiesta una piccola quantità di memoria affidabile.
Un ulteriore sviluppo di JFFS2 è stato LogFS, che ha mantenuto i suoi inode in un file separato. Gli autori di questa idea sono un dipendente della divisione tedesca di IBM Jörn Engel e un insegnante presso l'Università di Osnabrück Robert Mertens. Il codice sorgente per LogFS è disponibile su GitHub. A giudicare dal fatto che l'ultima modifica è stata apportata quattro anni fa, LogFS non ha guadagnato popolarità.
Ma questi tentativi hanno stimolato l'emergere di un altro file system specializzato: F2FS. È stato sviluppato da Samsung Corporation, che rappresenta gran parte della memoria flash prodotta nel mondo. Samsung produce chip NAND Flash per i propri dispositivi e su ordinazione di altre aziende, e sviluppa anche SSD con interfacce fondamentalmente nuove invece di dischi legacy. La creazione di un file system specializzato ottimizzato per la memoria flash era una necessità attesa da tempo dal punto di vista di Samsung.
Quattro anni fa, nel 2012, Samsung ha creato F2FS (Flash Friendly File System). La sua idea è buona, ma l'esecuzione è stata un po' grossolana. Il compito principale durante la creazione di F2FS era semplice: ridurre il numero di operazioni di riscrittura delle celle e distribuire il carico su di esse nel modo più uniforme possibile. Ciò richiede l'esecuzione di operazioni su più celle all'interno dello stesso blocco contemporaneamente, anziché forzarle una alla volta. Ciò significa che non è necessaria la sovrascrittura istantanea dei blocchi esistenti alla prima richiesta del sistema operativo, ma la memorizzazione nella cache di comandi e dati, l'aggiunta di nuovi blocchi allo spazio libero e la cancellazione posticipata delle celle.
Ad oggi il supporto a F2FS è già stato ufficialmente implementato in Linux (e, quindi, in Android), ma nella pratica non dà ancora particolari vantaggi. La caratteristica principale di questo file system (sovrascrittura ritardata) ha portato a conclusioni premature sulla sua efficacia. Il vecchio trucco della memorizzazione nella cache ha persino ingannato le versioni precedenti dei benchmark, in cui F2FS ha mostrato un vantaggio immaginario non di pochi punti percentuali (come previsto) e nemmeno più volte, ma di ordini di grandezza. È solo che il driver F2FS ha riportato l'operazione che il controller aveva appena pianificato di eseguire. Tuttavia, se il reale guadagno di prestazioni di F2FS è piccolo, l'usura delle celle sarà sicuramente inferiore rispetto a quando si utilizza lo stesso ext4. Quelle ottimizzazioni che un controller economico non può fare verranno eseguite a livello del file system stesso.
Mentre F2FS è percepito come esotico per i geek. Anche nel loro Smartphone Samsung ext4 si applica ancora. Molti lo considerano un ulteriore sviluppo di ext3, ma questo non è del tutto vero. Si tratta più di una rivoluzione che di rompere la barriera dei 2 TB per file e semplicemente aumentare altri indicatori quantitativi.
Quando i computer erano grandi e i file piccoli, l'indirizzamento era facile. Ad ogni file è stato assegnato un certo numero di blocchi, i cui indirizzi sono stati inseriti nella tabella delle corrispondenze. Ecco come funzionava il file system ext3, che è rimasto in servizio fino ad ora. Ma ext4 ha introdotto un modo fondamentalmente diverso di affrontare: le estensioni.
Le estensioni possono essere pensate come estensioni di inode come insiemi separati di blocchi che vengono indirizzati nel loro insieme come sequenze contigue. Un'estensione può contenere un intero file di medie dimensioni e per file di grandi dimensioni è sufficiente allocare una dozzina o due estensioni. Questo è molto più efficiente dell'indirizzamento di centinaia di migliaia di piccoli blocchi di quattro kilobyte.
Modificato in ext4 e il meccanismo di registrazione stesso. Ora la distribuzione dei blocchi avviene immediatamente in una richiesta. E non in anticipo, ma immediatamente prima di scrivere i dati su disco. L'allocazione multiblocco differita consente di eliminare le operazioni non necessarie che ext3 ha peccato: in esso, i blocchi per un nuovo file sono stati allocati immediatamente, anche se si adattava completamente alla cache ed era pianificato per essere eliminato come temporaneo.
Oltre agli alberi bilanciati e alle loro modifiche, ci sono altre strutture logiche popolari. Esistono file system con un tipo di organizzazione fondamentalmente diverso, ad esempio lineare. Probabilmente ne usi almeno uno spesso.
Indovina l'enigma: a dodici anni cominciò a ingrassare, a sedici era stupidamente grassa, a trentadue divenne grassa, e rimase semplice. Chi è lei?
Esatto, questa è una storia sul file system FAT. I requisiti di compatibilità le assicuravano una cattiva eredità. Sui floppy disk, era a 12 bit, sui dischi rigidi - all'inizio a 16 bit e ha raggiunto i nostri giorni come 32 bit. In ogni versione successiva, il numero di blocchi indirizzabili è aumentato, ma in sostanza non è cambiato nulla.
L'ancora popolare file system FAT32 è apparso già vent'anni fa. Oggi è ancora primitivo e non supporta elenchi di controllo di accesso, quote disco, compressione in background o altre moderne tecnologie di ottimizzazione dei dati.
Perché è necessario FAT32 in questi giorni? Ancora solo per compatibilità. I produttori credono giustamente che qualsiasi sistema operativo possa leggere una partizione FAT32. Pertanto, lo creano su dischi rigidi esterni, flash USB e schede di memoria.
Le schede microSD(HC) utilizzate negli smartphone sono formattate in FAT32 per impostazione predefinita. Questo è l'ostacolo principale all'installazione di applicazioni su di essi e al trasferimento dei dati dalla memoria interna. Per superarlo, è necessario creare una partizione sulla scheda con ext3 o ext4. Tutti gli attributi del file (inclusi proprietario e diritti di accesso) possono essere trasferiti su di esso, quindi qualsiasi applicazione può funzionare come se fosse stata avviata dalla memoria interna.
Windows non sa come creare più di una partizione su unità flash, ma per questo puoi eseguire Linux (almeno in una macchina virtuale) o un'utilità avanzata per lavorare con il partizionamento logico, ad esempio MiniTool Partition Wizard Free. Avendo trovato una partizione primaria aggiuntiva con ext3 / ext4 sulla scheda, l'applicazione Link2SD e applicazioni simili offriranno molte più opzioni rispetto al caso di una singola partizione FAT32.
Come altro argomento a favore della scelta di FAT32, viene spesso chiamata la mancanza di accesso, il che significa operazioni di scrittura più veloci e minore usura delle celle di memoria NAND Flash. In pratica, l'uso di FAT32 porta al contrario e dà origine a molti altri problemi.
Le unità flash e le schede di memoria muoiono rapidamente a causa del fatto che qualsiasi modifica in FAT32 provoca la sovrascrittura degli stessi settori in cui si trovano due catene di tabelle di file. Ho salvato l'intera pagina Web ed è stata sovrascritta cento volte, con ogni aggiunta di un'altra piccola gif all'unità flash. Lanciato un software portatile? Ha creato file temporanei e li cambia costantemente mentre lavora. Pertanto, è molto meglio utilizzare NTFS su unità flash con la sua tabella $MFT a tolleranza di errore. I file di piccole dimensioni possono essere archiviati direttamente nella tabella dei file principale e le sue estensioni e copie vengono scritte in diverse aree della memoria flash. Inoltre, grazie all'indicizzazione su NTFS, le ricerche sono più veloci.
Un altro problema che la maggior parte degli utenti deve affrontare è che è impossibile scrivere un file più grande di 4 GB su una partizione FAT32. Il motivo è che in FAT32 la dimensione del file è descritta da 32 bit nella tabella di allocazione del file e 2^32 (meno uno, per essere precisi) è esattamente quattro gigabyte. Si scopre che né un film di qualità normale né un'immagine DVD possono essere scritti su un'unità flash appena acquistata.
Copiare file di grandi dimensioni non è poi così male: quando si tenta di farlo, l'errore è almeno immediatamente visibile. In altre situazioni, FAT32 agisce come una bomba a orologeria. Ad esempio, hai copiato un software portatile su un'unità flash e all'inizio lo usi senza problemi. Dopo molto tempo, uno dei programmi (ad esempio contabilità o posta) ha un database che si gonfia e ... semplicemente interrompe l'aggiornamento. Il file non può essere sovrascritto perché ha raggiunto il limite di 4 GB.
Un problema meno ovvio è che, in FAT32, la data di creazione di un file o di una directory può essere fornita fino a due secondi. Questo è insufficiente per molte applicazioni crittografiche che utilizzano timestamp. La bassa precisione dell'attributo "data" è un altro motivo per cui FAT32 non è considerato un file system completo dal punto di vista della sicurezza. Tuttavia, i suoi punti deboli possono essere utilizzati per i propri scopi. Ad esempio, se si copiano file da una partizione NTFS a un volume FAT32, verranno eliminati tutti i metadati, nonché le autorizzazioni ereditate e appositamente impostate. FAT semplicemente non li supporta.
A differenza di FAT12/16/32, exFAT è stato progettato specificamente per USB Flash e schede di memoria di grandi dimensioni (≥ 32 GB). La FAT estesa elimina lo svantaggio di FAT32 menzionato sopra: sovrascrivendo gli stessi settori con qualsiasi modifica. Essendo un sistema a 64 bit, non ha limiti pratici alle dimensioni di un singolo file. In teoria, può essere lungo 2 ^ 64 byte (16 EB) e le schede di queste dimensioni non appariranno presto.
Un'altra differenza fondamentale tra exFAT è il supporto per gli elenchi di controllo di accesso (ACL). Questa non è più la stessa cosa semplice degli anni Novanta, tuttavia, la vicinanza del formato impedisce l'introduzione di exFAT. Il supporto ExFAT è pienamente e legalmente implementato solo in Windows (a partire da XP SP2) e OS X (a partire da 10.6.5). Su Linux e *BSD, è supportato in modo limitato o supportato illegalmente. Microsoft richiede licenze per utilizzare exFAT e ci sono molte controversie legali in questo settore.
Un altro importante filesystem B-tree è chiamato Btrfs. Questo FS è apparso nel 2007 ed è stato originariamente creato in Oracle con l'obiettivo di lavorare con SSD e RAID. Ad esempio, può essere ridimensionato dinamicamente: creare nuovi inode direttamente sul sistema in esecuzione o dividere un volume in sottovolumi senza allocare loro spazio libero.
Il meccanismo copy-on-write implementato in Btrfs e la piena integrazione con il modulo del kernel Device mapper consentono di creare snapshot quasi istantanei tramite dispositivi a blocchi virtuali. La precompressione dei dati (zlib o lzo) e la deduplicazione velocizzano le operazioni di base, prolungando la durata della memoria flash. Ciò è particolarmente evidente quando si lavora con database (si ottiene una compressione di 2-4 volte) e piccoli file (sono scritti in blocchi ordinati di grandi dimensioni e possono essere archiviati direttamente nelle "foglie").
Btrfs supporta anche la registrazione completa (dati e metadati), il controllo del volume senza smontare e molte altre funzionalità moderne. Il codice Btrfs è pubblicato sotto licenza GPL. Questo file system è stato supportato come stabile su Linux dalla versione del kernel 4.3.1.
Quasi tutti i file system più o meno moderni (ext3 / ext4, NTFS, HFSX, Btrfs e altri) appartengono al gruppo generale di quelli journal, poiché tengono traccia delle modifiche apportate in un log separato (journal) e controllano con esso nel caso di guasto durante le operazioni del disco. Tuttavia, la granularità della registrazione e la tolleranza agli errori variano tra questi file system.
ext3 supporta tre modalità di registrazione: loopback, ordinato e registrazione completa. La prima modalità prevede la scrittura delle sole modifiche generali (metadati), eseguite in modo asincrono rispetto alle modifiche dei dati stessi. La seconda modalità esegue la stessa scrittura dei metadati, ma rigorosamente prima che vengano apportate modifiche. La terza modalità equivale alla registrazione completa (modifiche sia nei metadati che nei file stessi).
Solo l'ultima opzione fornisce l'integrità dei dati. I restanti due velocizzano solo il rilevamento degli errori durante il controllo e garantiscono il ripristino dell'integrità del file system stesso, ma non del contenuto dei file.
Il journaling in NTFS è simile alla seconda modalità di registrazione in ext3. Vengono registrate solo le modifiche ai metadati e i dati stessi potrebbero andare persi in caso di errore. Questo metodo di registrazione in NTFS non è stato concepito come un modo per ottenere la massima affidabilità, ma solo come un compromesso tra velocità e tolleranza ai guasti. Questo è il motivo per cui le persone che sono abituate a lavorare con sistemi completamente journaling considerano NTFS come pseudo-journaled.
L'approccio implementato in NTFS è per certi versi addirittura migliore dell'impostazione predefinita in ext3. NTFS crea inoltre punti di controllo periodicamente per garantire che tutte le operazioni su disco in sospeso in precedenza siano state completate. I checkpoint non hanno nulla a che fare con i punti di ripristino in \System Volume Information\ . Queste sono solo voci di servizio nel registro.
La pratica mostra che nella maggior parte dei casi tale inserimento nel journal NTFS parziale è sufficiente per un funzionamento senza problemi. Dopotutto, anche con una brusca interruzione di corrente, i dispositivi disco non si diseccitano all'istante. L'alimentatore e numerosi condensatori nelle unità stesse forniscono solo la quantità minima di energia sufficiente per completare l'operazione di scrittura in corso. Con i moderni SSD, con la loro velocità ed efficienza, la stessa quantità di energia è generalmente sufficiente per eseguire operazioni in sospeso. Un tentativo di passare alla registrazione completa ridurrebbe a volte la velocità della maggior parte delle operazioni.
L'uso dei file system è limitato dal loro supporto a livello di sistema operativo. Ad esempio, Windows non comprende ext2/3/4 e HFS+, ma a volte è necessario utilizzarli. Puoi farlo aggiungendo il driver appropriato.
Un driver open source per leggere e scrivere partizioni ext2/3 con supporto parziale per ext4. L'ultima versione supporta estensioni e partizioni fino a 16 TB. LVM, elenchi di controllo di accesso e attributi estesi non sono supportati.
C'è un plugin gratuito per Total Commander. Supporta la lettura di partizioni ext2/3/4.
coLinux è un port aperto e gratuito del kernel Linux. Insieme a un driver a 32 bit, ti consente di eseguire Linux in Ambiente Windows dal 2000 al 7 senza l'utilizzo di tecnologie di virtualizzazione. Supporta solo versioni a 32 bit. Lo sviluppo della modifica a 64 bit è stato annullato. coLinux consente, tra le altre cose, di organizzare da Accesso a Windows alle partizioni ext2/3/4. Il sostegno al progetto è stato sospeso nel 2014.
Windows 10 potrebbe già avere il supporto integrato per i file system specifici di Linux, è solo nascosto. Questi pensieri sono suggeriti dal driver a livello di kernel Lxcore.sys e dal servizio LxssManager, che viene caricato come libreria dal processo Svchost.exe. Per ulteriori informazioni, vedere il discorso di Alex Ionescu "The Linux Kernel Hidden Inside Windows 10" al Black Hat 2016.
ExtFS per Windows è un driver a pagamento rilasciato da Paragon. Funziona su Windows da 7 a 10, supporta l'accesso in lettura/scrittura a volumi ext2/3/4. Fornisce un supporto quasi completo per ext4 su Windows.
HFS+ per Windows 10 è un altro driver proprietario di Paragon Software. Nonostante il nome, funziona in tutte le versioni di Windows a partire da XP. Fornisce l'accesso completo ai file system HFS+/HFSX su dischi con qualsiasi layout (MBR/GPT).
WinBtrfs è uno dei primi sviluppi del driver Btrfs per Windows. Già nella versione 0.6, supporta sia l'accesso in lettura che in scrittura ai volumi Btrfs. Può gestire collegamenti fisici e simbolici, supporta flussi di dati alternativi, ACL, due tipi di compressione e modalità di lettura/scrittura asincrona. Sebbene WinBtrfs non sappia come utilizzare mkfs.btrfs, btrfs-balance e altre utilità per mantenere questo file system.
| File system | Volume maxi-piccolo | Limita la dimensione di un file | Lunghezza del proprio nome file | Mezza lunghezza del nome del file (incluso il percorso dalla radice) | Limita il numero di file e/o directory | Precisione di indicazione della data del file/catalogo | Diritti di Dos-tu-Pa | Collegamenti reali | Collegamenti simbolici | Colpi di vena istantanei (istantanee) | Compressione dei dati in background | Dati Cipher-ro-va-nie in background | Dedu-pli-ka-tion dati |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| FAT16 | 2 GB in settori da 512 byte o 4 GB in cluster da 64 KB | 2 GB | 255 byte con LFN | - | - | - | - | - | - | - | - | - | - |
| FAT32 | 8 TB in settori da 2 KB | 4 GB (2^32 - 1 byte) | 255 byte con LFN | fino a 32 sottodirectory con CDS | 65460 | 10 ms (crea) / 2 s (modifica) | No | No | No | No | No | No | No |
| exFAT | ≈ 128 PB (2^32-1 cluster di 2^25-1 byte) teorici / 512 TB a causa di limiti di terze parti | 16 EB (2^64 - 1 byte) | 2796202 in catalogo | 10 ms | ACL | No | No | No | No | No | No | ||
| NTFS | 256 TB in cluster da 64 KB o 16 TB in cluster da 4 KB | 16 TB (Vin 7) / 256 TB (Vin 8) | 255 caratteri Unicode (UTF-16) | 32760 caratteri Unicode, ma non più di 255 caratteri in ogni elemento | 2^32-1 | 100 ns | ACL | sì | sì | sì | sì | sì | sì |
| HFS+ | 8 EB (2^63 byte) | 8 EB | 255 caratteri Unicode (UTF-16) | non limitato separatamente | 2^32-1 | 1 s | Unix ACL | sì | sì | No | sì | sì | No |
| APFS | 8 EB (2^63 byte) | 8 EB | 255 caratteri Unicode (UTF-16) | non limitato separatamente | 2^63 | 1 ns | Unix ACL | sì | sì | sì | sì | sì | sì |
| Est3 | 32 TB (teoricamente) / 16 TB in cluster da 4 KB (a causa delle limitazioni delle utilità dei programmi e2fs) | 2 TB (in teoria) / 16 GB per i programmi meno recenti | 255 caratteri Unicode (UTF-16) | non limitato separatamente | - | 1 s | Unix ACL | sì | sì | No | No | No | No |
| Est4 | 1 EB (teoricamente) / 16 TB in cluster da 4 KB (a causa delle limitazioni delle utilità dei programmi e2fs) | 16 TB | 255 caratteri Unicode (UTF-16) | non limitato separatamente | 4 miliardi | 1 ns | POSIX | sì | sì | No | No | sì | No |
| F2FS | 16 TB | 3,94 TB | 255 byte | non limitato separatamente | - | 1 ns | POSIX, ACL | sì | sì | No | No | sì | No |
| BTRFS | 16 EB (2^64 - 1 byte) | 16 EB | 255 caratteri ASCII | 2^17 byte | - | 1 ns | POSIX, ACL | sì | sì | sì | sì | sì | sì |
L'ho già annunciato una volta nel mio blog, poi non se ne sapeva nulla, e ora è il momento di una breve ma più coerente conoscenza con il ReFS appena coniato.
Tuttavia, tutto ha un limite, così come le capacità dei file system. Oggi le capacità di NTFS hanno raggiunto i loro limiti: il controllo di supporti dati capienti richiede troppo tempo, il "Journal" rallenta l'accesso e la dimensione massima del file è quasi stata raggiunta. Rendendosi conto di ciò, Microsoft ha implementato un nuovo file system in Windows 8 - ReFS (Resilient File System - file system a tolleranza di errore). Si ritiene che ReFS fornisca la migliore protezione dei dati su dischi rigidi capienti e veloci. Sicuramente ha i suoi inconvenienti, ma prima dell'inizio di un utilizzo davvero massiccio in Windows 8, è difficile parlarne.
Quindi, per ora, proviamo a capire la struttura interna e i vantaggi di ReFS.
ReFS era originariamente conosciuto con il nome in codice "Protogon". Per la prima volta, ha detto al grande pubblico circa un anno fa Stefano Sinofsky- Presidente della divisione Windows di Microsoft, responsabile dello sviluppo e del marketing di Windows e Internet Explorer.
Detto con queste parole:
“Oggi NTFS è il file system più utilizzato, avanzato e ricco di funzionalità. Ma ripensando a Windows, e attualmente stiamo sviluppando Windows 8, non ci fermiamo qui. Pertanto, insieme a Windows 8, stiamo introducendo anche un file system completamente nuovo. ReFS si basa su NTFS, quindi mantiene le caratteristiche di compatibilità critiche pur essendo progettato e progettato per soddisfare le esigenze di una nuova generazione di tecnologie e scenari di storage.
In Windows 8, ReFS verrà introdotto solo come parte di Windows Server 8, lo stesso approccio utilizzato per introdurre tutti i file system precedenti. Naturalmente, a livello di applicazione, ai client verrà concesso l'accesso ai dati ReFS allo stesso modo dei dati NTFS. Non dimentichiamo che NTFS è ancora la tecnologia di file system leader del settore per PC".
In effetti, per la prima volta abbiamo visto ReFS nel sistema operativo del server Windows Server 8. Il nuovo file system non è stato sviluppato da zero. Ad esempio, ReFS utilizza le stesse API di NTFS per aprire, chiudere, leggere e scrivere file. Inoltre, molte funzionalità note sono migrate da NTFS, ad esempio la crittografia del disco bitlocker e collegamenti simbolici per le biblioteche. Ma scomparso, per esempio, compressione dati e una serie di altre funzioni.
Le principali innovazioni di ReFS si concentrano nell'area della creazione e gestione di strutture di file e cartelle. Il loro compito è fornire correzione automatica errori, scalabilità massima e funzionamento in modalità Always Online.
L'implementazione del disco delle strutture ReFS è fondamentalmente diversa da altri file system Microsoft. Gli sviluppatori Microsoft sono stati in grado di realizzare le loro idee applicando il concetto di B±trees in ReFS, che è ben noto dai database. Le cartelle nel file system sono strutturate come tabelle con file come voci. Questi a loro volta ricevono determinati attributi aggiunti come sottotabelle, creando una struttura ad albero gerarchica. Anche lo spazio libero su disco è organizzato in tabelle.
Insieme alla vera numerazione a 64 bit di tutti gli elementi del sistema, questo elimina la comparsa di "colli di bottiglia" durante il suo ulteriore ridimensionamento
Di conseguenza, il cuore del sistema in ReFS è la tabella degli oggetti, un catalogo centrale che elenca tutte le tabelle nel sistema. Questo approccio ha un vantaggio importante: ReFS ha abbandonato la complessa gestione del journal e corregge le nuove informazioni sul file nello spazio libero, impedendo che venga sovrascritto.
« Catalogo Foglie' sono record digitati. Esistono tre tipi fondamentali di voci per un oggetto cartella: un descrittore di directory, una voce di indice e un descrittore di oggetto nidificato. Tutti questi record sono impacchettati come un B±tree separato con un identificatore di cartella; la radice di questo albero è la foglia B ± dell'albero "Directory", che consente di comprimere quasi un numero qualsiasi di record in una cartella. Al livello inferiore nei fogli B± dell'albero delle cartelle c'è principalmente una voce del descrittore di directory contenente i dati di base sulla cartella (nome, "informazioni standard", attributo del nome del file, ecc.).
Più avanti nel catalogo sono inseriti record di indice: brevi strutture contenenti dati sugli elementi contenuti nella cartella. Questi record sono molto più brevi rispetto a NTFS: ciò ingombra il volume con i metadati in misura minore.
Alla fine ci sono le voci delle voci di directory. Per le cartelle, questi elementi contengono il nome del pacchetto, l'ID della cartella nella "Directory" e la struttura delle "informazioni standard". Non esiste un identificatore per i file, ma la struttura contiene tutti i dati di base sul file, inclusa la radice B dell'albero del frammento di file. Di conseguenza, un file può essere costituito da quasi un numero qualsiasi di frammenti.
Come NTFS, ReFS distingue fondamentalmente tra le informazioni sui file (metadati) e il contenuto dei file (dati utente). ma funzioni protettive sono dati ad entrambi allo stesso modo. I metadati sono protetti per impostazione predefinita con checksum: la stessa protezione può (facoltativamente) essere fornita ai dati dell'utente. Questi checksum si trovano sul disco a una distanza di sicurezza l'uno dall'altro, quindi sarà più facile recuperare i dati in caso di errore.
La dimensione dei metadati di un file system vuoto è circa lo 0,1% della dimensione del file system stesso (ovvero, circa 2 GB per un volume di 2 TB). Alcuni metadati principali vengono duplicati per una maggiore resilienza
La variante ReFS in cui abbiamo visto Windows Server 8 Beta, supporta solo cluster di dati da 64 KB e cluster di metadati da 16 KB. Per ora, il parametro Cluster Size viene ignorato durante la creazione di un volume ReFS e viene sempre considerato l'impostazione predefinita. Quando si formatta un file system, anche l'unica opzione disponibile per selezionare la dimensione del cluster è 64 KB.
Lo ammettiamo: questa dimensione del cluster è più che sufficiente per organizzare file system di qualsiasi dimensione. Un effetto collaterale, tuttavia, è una notevole ridondanza nell'archiviazione dei dati (un file da 1 byte su disco occuperà un blocco completo di 64 KB).
In termini di architettura del file system, ReFS dispone di tutti gli strumenti necessari per ripristinare in sicurezza i file anche dopo un grave guasto hardware. Lo svantaggio principale del sistema di journaling nel file system NTFS e simili è che l'aggiornamento di un disco può danneggiare i metadati registrati in precedenza in caso di interruzione di corrente durante la registrazione: questo effetto ha già ricevuto un nome stabile: il cosiddetto. " record battuto».
Impedire record rotti, gli sviluppatori di Microsoft hanno scelto un nuovo approccio, in cui parti delle strutture di metadati contengono i propri identificatori, che consente di verificare la proprietà delle strutture; i riferimenti ai metadati contengono checksum a 64 bit dei blocchi a cui si fa riferimento.
Qualsiasi cambiamento nella struttura dei metadati avviene in due fasi. Innanzitutto, viene creata una nuova copia (modificata) dei metadati nello spazio libero su disco e solo dopo, in caso di esito positivo, il collegamento viene trasferito dalla vecchia (non modificata) alla nuova area dei metadati (modificata) mediante un'operazione di aggiornamento atomico. Qui evita la registrazione preservando automaticamente l'integrità dei dati.
Tuttavia, lo schema descritto non si applica ai dati dell'utente, quindi eventuali modifiche al contenuto di un file vengono scritte direttamente nel file. L'eliminazione di un file viene eseguita ricostruendo la struttura dei metadati, che mantiene la versione precedente del blocco dei metadati su disco. Questo approccio consente di recuperare i file eliminati fino a quando non vengono sovrascritti con i nuovi dati utente.
Un argomento separato è la tolleranza agli errori ReFS in caso di danni al disco. Il sistema è in grado di rilevare tutte le forme di danneggiamento del disco, inclusi i record persi o archiviati nel posto sbagliato, così come i cosiddetti. un po' di decadimento(deterioramento dello stato dei dati sui media)
Quando l'opzione "stream integrali" è abilitata, ReFS esegue anche il checksum del contenuto dei file e scrive sempre le modifiche ai file in una posizione di terze parti. Ciò garantisce che i dati preesistenti non vengano persi quando sovrascritti. I checksum vengono aggiornati automaticamente quando i dati vengono scritti, in modo che se la scrittura non riesce, l'utente avrà ancora una versione del file disponibile per la verifica.
Un altro argomento interessante nel problema della sicurezza ReFS è l'interazione con Spazi di archiviazione. Rif e Spazi di archiviazione progettati per completarsi a vicenda come due componenti sistema unificato archivio dati. Oltre a migliorare le prestazioni Spazi di archiviazione proteggere i dati da guasti parziali e completi del disco archiviando copie su più dischi. Durante gli errori di lettura Spazi di archiviazioneè in grado di leggere copie e, in caso di errori di scrittura (anche con una perdita completa dei dati del supporto durante la lettura/scrittura), è possibile ridistribuire i dati in modo “trasparente”. Come mostra la pratica, molto spesso un tale errore non è correlato al supporto: si verifica a causa della corruzione dei dati o della perdita di dati o del salvataggio nel posto sbagliato.
Questi sono i tipi di errori che ReFS può rilevare utilizzando i checksum. Dopo aver rilevato un errore, ReFS contatta Spazi di archiviazione al fine di leggere tutte le possibili copie dei dati, e seleziona la copia corretta in base alla verifica del checksum. Dopodiché, il sistema cede Spazi di archiviazione un comando per ripristinare le copie danneggiate in base alle copie corrette. Tutto ciò avviene in modo trasparente dal punto di vista applicato.
Come affermato sul sito Web di Microsoft Windows Server 8, i checksum sono sempre abilitati per i metadati ReFS e presupponendo che il volume sia ospitato su mirroring Spazi di archiviazione, è abilitata anche la correzione automatica. Tutti i flussi integrali sono protetti allo stesso modo. Ciò crea una soluzione end-to-end con un elevato grado di integrità per l'utente, grazie alla quale uno storage relativamente inaffidabile può essere reso molto affidabile.
Detti flussi di integrità proteggono il contenuto di un file da tutti i tipi di danneggiamento dei dati. Tuttavia, questa caratteristica non è applicabile in alcuni casi.
Ad esempio, per alcune applicazioni, è preferibile gestire con attenzione l'archiviazione dei file con un certo ordinamento dei file su disco. Poiché flussi coerenti riallocano i blocchi ogni volta che il contenuto di un file cambia, il layout dei file per queste applicazioni è troppo imprevedibile. I sistemi di database ne sono un ottimo esempio. Di norma, tali applicazioni tengono autonomamente una registrazione dei checksum dei contenuti dei file e hanno la possibilità di controllare e correggere i dati interagendo direttamente con le API.
Il modo in cui ReFS funziona in caso di danneggiamento del disco o errore di archiviazione, penso, sia chiaro. Può essere più difficile identificare e superare la perdita di dati associata a " un po' di decadimento”, quando i danni a parti del disco lette raramente che non sono state rilevate in tempo iniziano a crescere rapidamente. Nel momento in cui questi danneggiamenti vengono letti e rilevati, le copie potrebbero già essere interessate o i dati potrebbero essere andati persi a causa di altri errori.
Per superare il processo un po' di decadimento, Microsoft ha aggiunto un'attività di sistema in background che pulisce periodicamente i metadati e trasmette i dati di integrità su un volume ReFS che si trova in uno spazio di archiviazione con mirroring. La pulizia avviene leggendo tutte le copie ridondanti e verificandone la correttezza utilizzando i checksum ReFS. Se i checksum non sono d'accordo, le copie con errori vengono corrette con buone copie.
Rimane una minaccia che può essere definita condizionatamente "l'incubo dell'amministratore di sistema". Ci sono casi, anche se rari, in cui anche un volume su uno spazio speculare può essere danneggiato. Ad esempio, la memoria di un sistema guasto può danneggiare i dati, che possono quindi finire su disco e danneggiare le copie ridondanti. Inoltre, molti utenti potrebbero decidere di non utilizzare gli spazi di archiviazione con mirroring in ReFS.
In questi casi, quando il volume viene danneggiato, ReFS esegue una "riparazione", una funzione che rimuove i dati dallo spazio dei nomi nel volume di lavoro. Il suo scopo è prevenire danni irreparabili che potrebbero pregiudicare la disponibilità di dati validi. Ad esempio, se un singolo file in una directory è danneggiato e non può essere riparato automaticamente, ReFS rimuoverà quel file dallo spazio dei nomi del file system, ripristinando il resto del volume.
Siamo abituati al fatto che il file system non può aprire o eliminare un file danneggiato e l'amministratore non può fare nulla al riguardo.
Ma poiché ReFS può recuperare i dati danneggiati, l'amministratore può ripristinare questo file da un backup o utilizzare l'applicazione per crearlo di nuovo senza dover spegnere il sistema. Ciò significa che l'utente o l'amministratore non dovranno più controllare e riparare l'unità offline. Per i server, ciò consente di distribuire grandi volumi di dati senza il rischio di lunghi periodi. durata della batteria a causa di danni.
Naturalmente, la praticità e la comodità (o le qualità inverse) di ReFS possono essere giudicate solo dopo che i computer con Windows 8 si sono diffusi e sono trascorsi almeno sei mesi di lavoro attivo con essi. Finora, i potenziali utenti del G8 hanno più domande che risposte.
Ad esempio, questo: sarà possibile in Windows 8 convertire facilmente e facilmente i dati da NTFS a ReFS e viceversa? I rappresentanti di Microsoft affermano che non esiste una funzione integrata per la conversione dei formati, ma le informazioni possono comunque essere copiate. Lo scopo di ReFS è ovvio: all'inizio può essere utilizzato solo come un grande data manager per il server (in effetti, è già in uso). Non ci saranno ancora unità esterne con ReFS - solo quelle interne. Ovviamente, nel tempo, ReFS sarà dotato di più funzionalità e potrà sostituire il sistema legacy.
Microsoft afferma che molto probabilmente accadrà con il rilascio del primo service pack per Windows 8
Microsoft afferma anche di aver testato ReFS:
“utilizzando una suite sofisticata e completa di decine di migliaia di test che sono stati creati per NTFS in più di due decenni. Questi test ricreano le complesse condizioni di implementazione che riteniamo possano verificarsi nel sistema, come interruzioni di corrente, problemi spesso associati alla scalabilità e alle prestazioni. Pertanto, possiamo dire che il sistema ReFS è pronto per l'implementazione di test in un ambiente gestito".
Allo stesso tempo, tuttavia, gli sviluppatori ammettono che, essendo la prima versione di un file system di grandi dimensioni, è probabile che ReFS richieda un'attenta gestione:
“Non definiamo ReFS per Windows 8 come beta. Il nuovo file system sarà pronto per il rilascio quando Windows 8 uscirà dalla versione beta, perché nulla è più importante dell'affidabilità dei dati. Quindi, a differenza di qualsiasi altro aspetto del sistema, qui è necessario un approccio conservativo all'uso iniziale e ai test".
In gran parte per questo motivo, ReFS sarà introdotto in uso secondo un piano graduale. Prima - come sistema di archiviazione per Windows Server, poi - come spazio di archiviazione per gli utenti e, alla fine, come volume di avvio. Tuttavia, un simile "approccio prudente" al rilascio di nuovi file system è stato utilizzato in precedenza.
In questo articolo capiremo quali funzionalità fornisce ReFS e perché è migliore del file system NTFS. Come recuperare i dati dallo spazio su disco ReFS. Il nuovo file system ReFS di Microsoft è stato originariamente introdotto in Windows Server 2012. È incluso anche in Windows 10 come parte dello strumento Spazio su disco. ReFS può essere utilizzato per un lotto di dischi. Con il rilascio di Windows Server 2016 il file system è stato migliorato, sarà presto disponibile nella nuova versione di Windows 10.
Quali funzionalità offre ReFS e in che modo è migliore dell'attuale sistema NTFS?
Contenuto:Corto per File system resiliente, ReFS è un nuovo sistema basato su NTFS. In questa fase, ReFS non offre un sostituto completo di NTFS per l'uso dell'unità da parte degli utenti domestici. Il file system ha i suoi vantaggi e svantaggi.
ReFS è progettato per risolvere i problemi di base di NTFS. È più resistente al danneggiamento dei dati, è in grado di gestire meglio carichi di lavoro pesanti e si adatta facilmente a file system molto grandi. Diamo un'occhiata a cosa significa?
Il file system utilizza i checksum per i metadati e può anche utilizzare i checksum per i dati dei file. Durante la lettura o la scrittura di un file, il sistema controlla il checksum per assicurarsi che sia corretto. Pertanto, viene eseguito il rilevamento in tempo reale dei dati danneggiati.
ReFS è integrato con la funzione Spazio su disco. Se imposti un archivio dati con mirroring, con l'aiuto di ReFS, Windows rileverà e riparerà automaticamente il danneggiamento del file system copiando i dati da un altro disco. Questa funzionalità è disponibile sia in Windows 10 che in Windows 8.1.
Se il file system rileva dati danneggiati che non dispongono di una copia alternativa per il ripristino, ReFS elimina immediatamente tali dati dal disco. Ciò non richiede il riavvio del sistema o la disabilitazione del dispositivo di archiviazione, come nel caso di NTFS.
La necessità di utilizzare l'utilità chkdsk scompare completamente, poiché il file system viene corretto automaticamente immediatamente al momento dell'errore. Nuovo sistema resistente ad altri tipi di danneggiamento dei dati. NTFS scrive i metadati del file direttamente quando lo scrive. Se durante questo periodo si verifica un'interruzione di corrente o un arresto anomalo del computer, i dati verranno danneggiati.
Durante una modifica dei metadati, ReFS crea una nuova copia dei dati e associa i dati al file solo dopo che i metadati sono stati scritti sul disco. Ciò elimina la possibilità di danneggiamento dei dati. Questa funzionalità è chiamata copy-on-write ed è presente anche in altri popolari sistemi operativi Linux: ZFS, BtrFS e il file system Apple APFS.
ReFS è più moderno e supporta volumi molto più grandi e nomi di file più lunghi rispetto a NTFS. A lungo termine, si tratta di miglioramenti importanti. Nel file system NTFS, il nome del file è limitato a 255 caratteri, in ReFS il nome del file può contenere fino a 32768 caratteri. Windows 10 ti consente di disabilitare il limite di caratteri per i file system NTFS, ma è sempre disabilitato sui volumi ReFS.
ReFS non supporta più nomi di file brevi DOS 8.3. Su un volume NTFS, puoi accedere C:\Programmi\ v C:\PROGRAMMA~1\ per garantire la compatibilità con il software precedente.
NTFS ha un massimo teorico di 16 exabyte, mentre ReFS ha un massimo teorico di 262144 exabyte. Anche se ora non importa molto, ma il computer è in continua evoluzione.
ReFS non è stato progettato per migliorare le prestazioni del file system su NTFS. Microsoft ha reso il sistema ReFS molto più efficiente in casi molto specifici.
Ad esempio, se utilizzato con Storage Space, ReFS supporta "ottimizzazione in tempo reale". Supponiamo che tu abbia un pool di unità con due unità, una per le massime prestazioni, l'altra per il volume. ReFS scriverà sempre i dati su un'unità più veloce, garantendo le massime prestazioni. In background, il file system sposterà automaticamente grandi quantità di dati su unità più lente per l'archiviazione a lungo termine.
In Windows Server 2016, Microsoft ha migliorato ReFS per fornire prestazioni migliori per le funzionalità della macchina virtuale. La macchina virtuale Microsoft Hyper-V sfrutta questi vantaggi (teoricamente, qualsiasi macchina virtuale può sfruttare ReFS).
Ad esempio, ReFS supporta la clonazione dei blocchi, che accelera il processo di clonazione delle macchine virtuali e le operazioni di unione dei checkpoint. Per creare una copia di una macchina virtuale, ReFS deve solo scrivere i nuovi metadati su disco e fornire un collegamento ai dati esistenti. Questo perché in ReFS più file possono puntare agli stessi dati sottostanti su disco.
Quando la macchina virtuale scrive nuovi dati su disco, vengono scritti in una posizione diversa, mentre i dati della macchina virtuale originale rimangono su disco. Ciò accelera notevolmente il processo di clonazione e richiede una larghezza di banda del disco molto inferiore.
ReFS offre anche una nuova funzionalità "VDL raro", che consente a ReFS di scrivere rapidamente zeri su un file di grandi dimensioni. Ciò velocizza notevolmente la creazione di un nuovo file di disco rigido virtuale (VHD) vuoto a dimensione fissa. Su NTFS questa operazione può richiedere 10 minuti, su ReFS può richiedere alcuni secondi.
Nonostante una serie di vantaggi, ReFS non può ancora sostituire NTFS. Windows non può avviarsi da una partizione ReFS e richiede NTFS. ReFS non supporta le funzionalità NTFS come compressione dei dati, crittografia del file system, collegamenti reali, attributi estesi, deduplicazione dei dati e quote del disco. Ma a differenza di NTFS, ReFS consente di eseguire la crittografia completa del disco utilizzando BitLocker, comprese le strutture del disco di sistema.
Windows 10 non ti consente di formattare una partizione in ReFS, questo file system è disponibile solo all'interno di Spazio su disco. ReFS protegge i dati utilizzati su pool di più dischi rigidi dalla corruzione. In Windows Server 2016 è possibile formattare i volumi con ReFS anziché NTFS. Tale volume può essere utilizzato per archiviare macchine virtuali, ma il sistema operativo può comunque avviarsi solo da NTFS.
Hetman Partition Recovery consente di analizzare lo spazio su disco gestito dal file system ReFS utilizzando un algoritmo di analisi della firma. Analizzando il dispositivo settore per settore, il programma trova determinate sequenze di byte e le mostra all'utente. Il ripristino dei dati dallo spazio su disco ReFS non è diverso dall'utilizzo del file system NTFS:
Il futuro del nuovo file system è piuttosto vago. Microsoft potrebbe finalizzare ReFS per sostituire il legacy NTFS in tutte le versioni di Windows. Al momento, ReFS non può essere utilizzato universalmente e serve solo per determinati compiti.
Se hai già installato e lavorato con i nuovi sistemi operativi di Microsoft: Windows Server 2012 e Windows 8, probabilmente avrai già notato che ora è possibile formattare nuovi volumi nel file system ReFS. Che cos'è un file system Rif? L'abbreviazione ReFS sta per File system resiliente, cioè. in russo "File system a tolleranza di errore".
Microsoft leggerà il file system ReFS come il successore del più popolare file system NTFS al momento, le cui capacità tecnologiche hanno già raggiunto i loro limiti. In particolare, quando si lavora con supporti dati di grandi dimensioni, ci sono difficoltà con il loro lavoro: è troppo lungo quando si esegue un'operazione di controllo degli errori e il journal è lento e raggiunge i limiti della dimensione massima del file sul file system NTFS.
La maggior parte delle innovazioni di ReFS risiedono nell'area della creazione e della gestione di strutture di file e cartelle. Queste funzionalità sono implementate per la correzione automatica degli errori, l'elevata scalabilità e il funzionamento sempre in linea. Le cartelle nel file system ReFS sono strutturate come tabelle con file come voci, che a loro volta possono avere i propri attributi organizzati come sottotabelle, implementando la struttura ad albero gerarchica degli alberi B+ a noi familiari dai database. Anche lo spazio libero su disco è organizzato in tabelle.
Durante lo sviluppo di ReFS, sono stati perseguiti i seguenti obiettivi:
Caratteristiche principali di ReFS
Limitazioni del file system ReFS
ReFS ha ereditato molte delle caratteristiche e della semantica del suo predecessore, NTFS, tra cui:
Tutti i dati su un file system ReFS saranno accessibili tramite le stesse API attualmente utilizzate per accedere alle partizioni NTFS.
ReFS ha rimosso le seguenti funzionalità NTFS:
Il supporto ReFS è stato introdotto in Windows 8 e Windows Server 2012 e solo per i volumi di dati. Cioè, le partizioni con ReFS non possono essere utilizzate per installare il sistema operativo e avviarlo da esso. Nel tempo, ReFS sarà dotato di più funzionalità e sarà in grado di sostituire completamente il sistema NTFS legacy. Probabilmente, tutte le nuove funzionalità appariranno nel primo Service Pack per Windows 8.
Inoltre, ReFS non può ancora essere applicato a dispositivi di archiviazione rimovibili e portatili (ReFS attualmente è applicato solo ai supporti interni).
Un momento spiacevole è il fatto che i volumi NTFS esistenti non possono essere convertiti in ReFS al volo. I dati dovranno essere trasferiti mediante regolare copia.
Il volume può essere formattato nel file system ReFS tramite la console Gestione disco. Ma Opzioni extra, come l'abilitazione del controllo dell'integrità, può essere abilitato solo dalla riga di comando.
Ad esempio, puoi abilitare il controllo di integrità ReFS con il comando:
Formato /fs:refs /q /i:abilita
Disabilita il controllo dell'integrità.
