Inside NTFS
Informazioni di base sul file System NTFS
Quando Microsoft rilascio Windows NT, esso supportava tre file system: FAT, HPFS, e NTFS. Microsoft originariamente sviluppo il file system FAT per il sistema operativo DOS, IBM introdusse HPFS per OS/2, e Microsoft creò NTFS per Windows NT. NTFS è il file system nativo di NT, esso supporta inoltre i formati FAT e HPFS per fornire delle possibili forme di migrazione dagli altri sistemi operativi (sebbene Microsoft non incluse il supporto per HPFS in NT 4.0).
L’obiettivo per cui Microsoft decise di implementare NTFS era quello di superare le limitazioni degli altri due file system, compatibili con NT, e di fornire caratteristiche avanzate che un sistema operativo a livello aziendale richiede. Per esempio, NTFS supporta un sistema di sicurezza a livello di file e directory molto granulare, mentre FAT e HPFS non hanno caratteristiche di sicurezza. In aggiunta, lo schema di allocazione di NTFS può indirizzare efficacemente dischi rigidi di notevoli dimensioni. FAT e HPFS sono invece entrambi limitati dalla dimensione dei dischi. Infine, dei tre file system, NTFS è l’unico che supporta la codifica Unicode per gli ambiti internazionali e ha caratteristiche per prevenire la corruzione di file e del file system in caso di guasto.
NTFS Capabilities
Alla fine degli anni ’80 Microsoft progetto NTFS parallelamente allo sviluppo iniziale di Windows NT. Quando l’infrastruttura di base di NTFS fu realizzata e verificata la sua funzionalità, Microsoft diede come direttiva al team che stava sviluppando NT di usare NTFS come sistema di sviluppo del file system.
Dato che NTFS doveva essere un nuovo file system, progettato da zero, il suo progetto poteva incorporare caratteristiche che potevano superare le limitazioni poste dall’hardware e dai file system dei PC attuali (allo sviluppo di NTFS) e anticipare le richieste degli utilizzatori aziendali del sistema. La cosa più ovvia fu quella di fornire un adeguato supporto ai dischi rigidi che aumentano costantemente le loro dimensioni. Tutti i file system Windows dividono le partizioni dei dischi in unità logiche dette clusters. Il file system FAT usa 16 bit (nella versione classica) per indirizzare clusters, così può indirizzare al più 216 o 65536 cluster diversi. I cluster possono variare in dimensione a seconda della dimensione del disco, ma cluster molto grandi possono portare come risultato a un problema di frammentazione interna oppure parecchio spazio sprecato all’interno del cluster stesso.
Per esempio, se un file ha solamente 250 bytes di dati, esso richiede un intero cluster di spazio allocato su disco il che risulta che più di 15Kb di spazio vanno sprecati in caso di cluster di dimensione 16Kb.
Con solo 65536 cluster indirizzabili, un disco FAT con 1Kb di spazio per cluster potrebbe indirizzare al massimo un disco di 65Mb. Un disco di 4Gb, per esempio, richiederebbe quindi una dimensione di 64Kb per cluster con i relativi svantaggi che abbiamo visto prima per cluster di così grandi dimensioni. Un disco NTFS invece indirizza i cluster con un indirizzamento a 64 bit. Così anche con 512 bytes per cluster NTFS non dovrebbe aver difficoltà ad indirizzare dischi con dimensioni che probabilmente non vedremo ancora per anni.
Gli sviluppatori di FAT e HPFS non considerarono il fatto della sicurezza all’interno del file system mentre NTFS usa lo stesso modello di sicurezza di NT. Discretionary access control lists (DACLs) e system access control lists (SACLs), controllano chi può fare operazioni sui file e quando un evento deve essere loggato, esse sono registrate nel formato nativo di NT all’interno della NTFS. Questo approccio fa diventare la gestione della sicurezza di NTFS un naturale adattamento con l’amministrazione della sicurezza di NT in generale.
Il file system FAT usa i caratteri ASCII a 8 bit per nominare i file e le directory. Impiegando quindi set di caratteri ASCII mettiamo una limitazione ai nomi usabili con FAT che equivalgono a quelli Inglesi (in generale simbolici). NT e NTFS usano entrambi il set di caratteri a 16 bit Unicode per i nomi. Questo attributo di NTFS permette agli utilizzatori di NT sparsi per il mondo di organizzare i loro file usando la loro lingua madre.
Nel modello FAT i dati immagazzinati all’interno di un file vengono registrati con l’approccio di un’unica unità. In contrasto con questa filosofia, NTFS usa diversi data stream per formare un file. Il data stream senza nome è equivalente alla tradizionale vista di un file per il file system FAT, ma i data stream con nome sono viste come unità alternative di dati. Il modello a data stream non è praticamente usato con NTFS (non ci sono ancora API WIn32 per la loro gestione), ma Services for Macintosh (SFM) che si riferisce ai data stream con nomi per lasciar usare agli utenti (client su rete) Macintosh data stream con nome su drive NTFS di rete come fossero sul loro file system nativo HFS (Hierarchical File System).
Infine FAT non prevede nulla per la salvaguardia dei file e del file system in caso di guasti. Se un sistema va in crash quando stiamo creando, aggiornando file e/o directory la struttura FAT sul disco può diventare inconsistente. La situazione può risultare in una perdita dell informazioni modificate oppure una totale corruzione del disco e conseguente perdita di parecchie informazioni residenti sul disco. Questo rischio è inaccettabile per il mercato a cui Windows NT è rivolto. NTFS ha quindi integrato un sistema di logging di transazioni in modo tale che quando una modifica deve essere implementata, NTFS si fa una nota della modifica da fare in un file speciale di log. Se il sistema va in crash, NTFS può esaminare il file di log e usarlo per ripristinare ad uno stato consistente il sistema con il minimo possibile di dati persi.
NTFS Disk Management
I vari tool per la formattazione (inizializzazione) dei dischi in NTFS fanno una stima automatica della dimensione delle unità d’allocazione in funzione della dimensione del disco. Queste stime possono anche essere modificate manualmente dall’amministratore del sistema. Le stime fatte direttamente prendono in considerazione il discorso dello spazio sprecato, frammentazione interna e quindi prestazioni generali e cercano di ottimizzarle tutte con un compromesso.
Le informazioni associate al disk management sono registrate all’interno del disco come file speciali. I dati registrati all’interno di questi file e tutte le informazioni inerenti all’NTFS all’interno dei file utente e delle directory vengono detti metadata. Quando si inizializza un disco con file system NTFS, esso inserisce al suo interno 11 metadata files. Questi file sono generalmente invisibili quando esploriamo un volume NTFS con i tool classici come Explorer.
In aggiunta al sistema di log per evitare perdite di dati sui volumi NTFS, esso protegge i suoi dati su disco con un sistema di firme. Quando in una lettura capita un errore, NTFS identifica il cluster come danneggiato e quindi procede alla rilocazione dei dati presenti su quel cluster e poi all’aggiornamento del metadata file $BADCLUS in modo tale da evitare di riutilizzare lo stesso cluster in futuro.
Il metadata file $BITMAP è un grande array di bit in cui ogni bit corrisponde a un cluster sul disco. Se il bit è off allora il cluster risulta libero altrimenti, è in uso. Questo file è mantenuto per tener traccia dei cluster liberi su disco per l’allocazione di nuovo spazio.
La Master File Table
Il centro di comando del file system NTFS è la MFT. Essa è analoga alla file allocation table nel file system FAT perché MFT mappa tutti i file e le directory sul disco, inclusi i metadata files dell’NTFS stesso. La MFT è divisa in unità discrete chiamate records. In uno o più record, NTFS registra i metadati che descrivono un file o le caratteristiche di una direcory (informazioni sulla sicurezza e altri attributi come sola lettura o nascosto) e la loro locazione sul disco. Sorprendentemente la MFT è un file che NTFS mappa usando dei record all’interno della MFT stessa. Questa struttura lascia la possibilità alla MFT di espandersi oppure di restringersi.
NTFS internamente identifica i file e le directory usando la loro posizione del record che descrive l’inizio dei loro metadati all’interno della MFT. Per esempio, i file metadata che compaiono nella Tabella 1 hanno un preassegnato indirizzo di partenza (base) per il record che li identifica nella MFT.
I record sono solitamente di dimensione 1Kb in un disco formattato con Windows NT 4.0, ma possono essere anche più grandi.
Il file $MFTMIRR è un file di complemento, in caso di disastri al file system, per la prevenzione di perdita di dati. Esso contiene la copia dei primi 16 record della MFT. NTFS lo registra a metà del disco circa mentre la MFT è all’inizio dello stesso. Se NTFS ha un problema nella lettura di MFT, esso si riferisce ad un duplicato. La locazione della MFT e della sua copia sono registrate nel boot record del disco, un file da 512 bytes posto all’inizio del disco stesso.
L’accesso ai dati della MFT gioca un ruolo base sul discorso performance su un disco NTFS, così NTFS cerca delle soluzioni per accedere alla MFT in modo più rapido possibile. Dato che la MFT è un file residente su volume NTFS esso può ingrandirsi e rimpicciolirsi e quindi frammentarsi. Questa frammentazione si verifica perché NTFS non può allocare in anticipo lo spazio che la MFT occuperà. Quando la MFT cresce e qualche altro file occupa lo spazio oltre la sua fine, la MTF deve guardare altrove sul disco per avere dello spazio libero.
L’accesso più veloce si realizza quando vengono fatte delle operazioni sul disco in maniera sequenziale ma, una MFT frammentata significa che NTFS ha bisogno di più letture per accedere, ad esempio, ad un record e questo può portare ad un abbassamento delle performance. Per evitare questo, NTFS crea una regione di cluster attorno alla fine della MFT dove file e directory non possono essere memorizzati. In questo modo si dà la possibilità alla MFT di crescere e/o ridursi senza troppe difficoltà. Quando lo spazio libero sul disco comincia a scarseggiare, NTFS rilascia un po’ dello spazio attorno alla fine della MFT per altri usi. Questo però porta la MFT ad correre un grosso rischio di frammentazione in un disco che peraltro è già al limite delle sue capacità. C’è da dire inoltre che NTFS non lascia deframmentare a tool appositi la MFT.
MFT Records
I record della MFT consistono di una piccola intestazione (header) che contiene informazioni di base sul record, seguite da uno o più attributi che descrivono le caratteristiche del file o della directory che corrispondono al record. La figura 1 mostra la struttura di base di un record della MFT. I dati presenti nell’header includono numeri di sequenza che NTFS usa per una verifica di integrità, un puntatore al primo attributo nel record, un puntatore al primo byte libero nel record, e il numero del record di base della MFT del file in esame, se il record esaminato non è il primo.
NTFS usa gli attributi per immagazzinare tutte le informazioni sui file e sulle directory. L’NTFS di NT 4.0 ha ben 14 tipi di attributi elencati nella tabella 2. Sul disco gli attributi sono divisi in due componenti logiche: un header e la parte dati. Nell’header è registrato il tipo di attributo, il nome ed eventuali flag ed esso identifica la locazione della parte dati dell’attributo. NTFS usa un sistema per ottimizzare le performance: esso registra la parte dati dell’attributo, all’interno dei record della MFT quando possibile, invece che allocare cluster da qualche parte sul disco. Quando un attributo ha la sua parte dati memorizzata all’interno della MFT, l’attributo si dice residente, altrimenti, è detto non residente. Un attributo residente è possibile solo quando la sua parte dati stà all’interno del record assieme all’header dell’attributo, l’header del record e altri header dell’attributo. Così, un limite superiore di 1Kb (la dimensione tipica di un record della MFT) esiste per la dimensione di informazioni in un disco formattato con NT 4.0. Se la parte dati di un attributo è residente, l’header dell’attributo punta alla posizione dei dati all’interno del record della MFT. Per definizione, il nome del file, informazioni standard, e gli attributi di sicurezza sono sempre residenti.
Se NTFS deve memorizzare la parte dati di un attributo al di fuori della MFT, l’header dell’attributo, che è contenuto in un record della MFT associato con gli attributi dei file o directory, contiene informazioni che localizzano le informazioni sul disco. Le informazioni di data-mapping sono dette run-information perché pezzi contigui di dati formano una serie fatta da un cluster di partenza e una lunghezza. Le run-information, come molte strutture dati NTFS, hanno un header che identifica quale cluster della parte dati dell’attributo è mappata nella run-information.
Questo approccio è necessario perché attributi con grandi quantitativi di dati possono avere delle run-information divise in più record della MFT (ogni parte della run-information copre differenti parti del file).
Uno di questi punti contiene: un VCN (virtual cluster number), che è un offset relativo a cluster all’interno della parte dati dell’attributo; a LCN (logical cluster number), è la locazione sul disco dove risiedono i dati; e il numero di clusters contigui a quella posizione sul disco.
I file compressi sono un caso speciale. NTFS supporta la compressione solo sul data stream del file, e applica l’algoritmo di compressione a blocchi di 16 cluster. NTFS registra le informazioni compresse sul disco e per farlo richiede dei cluster, ma lo spazio salvato in un blocco di 16 cluster è essenzialmente registrato nella porzione compressa. I VCN per questi cluster compressi hanno gli LCN inesistenti, che NTFS rappresenta con un LCN pari a 1 nelle run-informations dei clusters compressi.
Se un file ha troppi attributi che non possono essere quindi registrati all’interno di un singolo record della MFT, NTFS alloca record addizionali e registra la lista degli attributi nel record base. La lista degli attributi punta alla locazione degli attributi nei record addizionali e consiste di un valore per ogni attributo.
Direcory
Una directory per NTFS è un attributo indice. NTFS usa gli attributi indice per collocare i nomi dei file. Una directory contiene il nome del file e una copia delle informazioni dell’attributo standard del file (informazioni sulle date e ore). Questo approccio fornisce una spinta sul piano delle prestazioni quanto si naviga all’interno delle directory in quanto NTFS non deve accedere alla MFT per trovare le informazioni da visualizzare per ogni file all’interno di una directory.
Quando queste informazioni posso essere contenute interamente in un record della MFT, un tipo di attributo, l’index root, descrive la locazione dei valori nel record. Quando una directory cresce, le informazioni necessarie a descriverla possono superare il record della MFT assegnato. In questo caso, NTFS alloca un index buffers per memorizzare informazioni addizionali. L’header dell’attributo indice specifica la locazione di un buffer. Nell’NTFS di NT 4.0 la dimensione di questo buffer era di 4Kb, e le informazioni sulla directory all’interno del buffer erano di lunghezza variabile visto che conteneva nomi di file.
Per rendere più efficienti possibili le operazioni sulle directory, NTFS preordina le directory all’interno della radice e dei buffer. L’ordinamento crea una struttura ad albero (un B+ albero).
NTFS logging
Dato che file e directory (inclusi i file di metadati NTFS) cambiano, NTFS scrive delle informazioni nei file log del volume. Il programma CHKDSK usa questi file di log per rendere le strutture dati NTFS consistenti e per minimizzare la perdita di dati in caso di crash. I file di log sono di due tipi: redo e undo. Redo memorizza le informazioni riguardanti modifiche che devono essere rifatte in caso di guasto al sistema e i dati modificati non sono sul disco. Per esempio, se una cancellazione di un file è in atto, l’operazione redo segnala che la cancellazione deve essere completata se un capita un problema e solo alcune delle strutture dati sul disco sono state aggiornate.
NTFS usa una operazione undo per fare un roll back delle modifiche fatte che non erano state completate quando è capitato il crash. Se NTFS sta aggiungendo dati a un file e il sistema “cade” tra il tempo in cui NTFS estendeva la lunghezza del file e il tempo in cui scriveva i nuovi dati, il file di log undo dice a NTFS di accorciare la lunghezza del file alla sua dimensione originale durante il recupero.
La dimensione dei due file di log è basata sulla dimansione del disco e comunque varia fra i 2Mb e i 4Mb. Il file di log si riempie fintanto che NTFS assicura che le informazioni registrate sui file di log redo e undo non sono necessarie per un eventuale ripristino. Periodicamente, NTFS fa un reset delle informazioni contenute nei due file di log spedendo tutti i dati modificati sul disco. L’operazione avviene tipicamente una volta ogni 5 secondi.
NT 5.0 NTFS
La versione 5.0 del file system NTFS acquisisce nuove caratteristiche alcune davvero interessanti. Una di queste è la capacità di supportare autonomamente la crittazione dei dati che protegge da occhi indiscreti le informazioni. Con le precedenti versioni, esistevano dei software in grado di ignorare le informazioni di sicurezza di NT rendendo quindi possibile l’accesso a tutte le informazioni memorizzate sul disco. NTFS non fa direttamente la codifica ma un altro componente software che è fortemente accoppiato con driver del file system. Questo si chiama EFS (Encrypting File System). Quando un utente vuole crittare un file, NTFS passa i dati a EFS che usando il SID dell’utente, che è univoco, e DES (uno standard di crittografia) crittografa il file.
NTFS 5.0 ora supporta nativamente la gestione delle quote per singolo utente cioè NTFS può dare un limite massimo allo spazio che i file di un utente devono occupare. Altre funzioni che NTFS 5.0 supporta sono il supporto per file “sparsi” e un sistema particolare di puntatori. I file detti sparsi sono chiamati così perché al loro interno hanno parecchi spazi vuoti e quindi NTFS per ottimizzare la loro memorizzazione, alloca clusters solo per le parti del file che contengono dati validi visto che le altre porzioni sono ipotizzate contenere degli zero. Il sistema nuovo di puntatori invece sono essenzialmente dei link simbolici, e possono puntare a file o directory sullo stesso o su un differente disco.
|
TABLE 1: NTFS Metadata Files |
||
|
NameMFT |
Record |
Description |
|
$MFT |
0 |
Master File Table—NTFS's command central |
|
$MFTMIRR |
1 |
Copy of the first 16 records of the MFT |
|
$LOGFILE |
2 |
Transactional logging file |
|
$VOLUME |
3 |
Contains volume serial number, creation time, and dirty flag |
|
$ATTRDEF |
4 |
Attribute definitions |
|
. |
5 |
Root directory of the disk |
|
$BITMAP |
6 |
Contains drive's cluster map (in-use vs. free) |
|
$BOOT |
7 |
Boot record of the drive |
|
$BADCLUS |
8 |
Lists bad clusters on the drive |
|
$QUOTA |
9 |
Contains user quota information—unused before NT 5.0 NTFS |
|
$UPCASE |
10 |
Maps lowercase characters to their uppercase version |
|
TABLE 2: NTFS Attribute Types |
|
|
Attribute Type |
Description |
|
$VOLUME_VERSION |
Volume version |
|
$VOLUME_NAME |
Disk's volume name |
|
$VOLUME_INFORMATION |
NTFS version and dirty flag |
|
$FILE_NAME |
File or directory name |
|
$STANDARD_INFORMATION |
File time stamps and hidden, system, and read-only flags |
|
$SECURITY_DESCRIPTOR |
Security information |
|
$DATA |
File data |
|
$INDEX_ROOT |
Directory content |
|
$INDEX_ALLOCATION |
Directory content |
|
$BITMAP |
Directory content mapping |
|
$ATTRIBUTE_LIST |
Describes nonresident attribute headers |
|
$SYMBOLIC_LINK |
Unused |
|
$EA_INFORMATION |
OS/2-compatibility extended attributes |
|
$EA |
OS/2-compatibility extended attributes |
Tratto da informazioni reperite su:
http://www.execsoft-europe.com
http://support.microsoft.com/searc= h/
Buffon Elia