File system del Dos & Windows

Indice:

1. Introduzione
2. Boot Master Record
3. Boot Sector
4. FAT16 & FAT32
5. Directory (Root)
6. File & Directory

Ultimo aggiornamento:Thursday 05 September 2002

Visitatori dal 01 giugno 1999

Introduzione:

In questa pagina desidero condensare tutto quello che ho trovato e sperimentato riguardante la gestione dell'HD bypassando il sistema operativo, dunque al più basso livello possibile.

Ho iniziato questa ricerca inizialmente per curiosità e successivamente, viste le conoscenze acquisite, per realizzare un progetto valido per il corso d'esame di Informatica Industriale che verte nel realizzare le primitive per il supporto del disco in il sistema operativo Real Time HARTIK scritto dal mio professore.

Il documento cerca di spiegare come siano strutturate le informazioni sull'HD che in breve può essere diviso in cinque aree:

Nel seguito saranno descritte le varie parti.

Master Boot Record:

Il MBR è il primo settore dell'HD (Il settore 1 del cilindro 0 sotto la testina 0 oppure il settore 0 nella numerazione LBA) e contiene il codice che esegue le prime operazioni di boot (Dal byte 0 al 1DD cerca la partizione da avviare e se c'è lancia il boot sector) e la tabella delle partizioni (Al massimo possono essercene 4 "primarie").

I sedici byte di ciascuna partizione sono utilizzati in questo modo:

Il primo byte BOOT contiene 80H se la partizione è avviabile altrimenti contiene 0.
Il secondo, terzo e quarto byte contengono le coordinate "fisiche" del primo settore della partizione (Boot Record) ma occorre notare due cose:

1. I bit 6 e 7 del byte Settore sono i due bit più significativi del Cilindro che dunque è un dato a 10 bit.
2. Il numero di settori indirizzabili con questa rappresentazione è limitato a 8bit+6bit+10bit=24bit quindi circa 16M settori dunque 4G byte, quantità ormai superata dagli HD attuali ... dunque e meglio usare la LBA.

Il quarto byte SYS contiene informazioni sul sistema operativo che ha creato la partizione.
Il quinto, sesto e settimo byte contengono le coordinate "fisiche" dell'ultimo settore della partizione.

I quattro byte successivi indicano la posizione del primo settore della partizione rappresentando il disco come una sequenza lineare di settori (LBA Logical Block Adress) a partire da 0 = MBR.
Gli ultimi quattro byte indicano il numero di settori occupati dalla partizione.

Per verificare quanto scritto prova a digitare i seguenti comandi dal prompt del dos

Boot Sector:

Ogni partizione inizia con un settore preposto a contenere informazioni sull'unità, e sul file system implementato nonché ad avviare il sistema operativo (Se la partizione è avviabile e contiene il file IO.SYS e MSDOS.SYS).

Il settore di Boot contiene parecchie informazioni ma le più importanti sono:

Due osservazioni:

1. La word in 11H indica quanti file possono essere memorizzati in Root.
   Fino all'introduzione della FAT32, infatti, LA directory (Root) era dimensionata fin dalla formattazione dunque il numero di file che poteva contenere era limitato.
   Successivamente si è deciso di trattare la directory come tutte le altre; questo però ha modificato il modo in cui si gestisce il file system.
   Mentre con la FAT16 il cluster 2 è il primo cluster dopo la directory, con la FAT 32 il primo cluster utilizzabile (che è sempre il numero 2 visto che i primi due (0 e 1) sono comunque riservati) è quello che segue l'ultima copia della FAT e in generale contiene la prima parte della Root ma contrariamente a quanto accade nella precedente versione non è detto che sia seguita dal resto della Root che per essere letta deve essere raggiunta facendo uso della FAT come per qualunque altro file.
2. Un'altra differenza sostanziale tra FAT16 e FAT32 sta nel fatto che la FAT32 ha dimensioni molto variabili e per grossi HD è anche molto grande dunque non basta la word 16H per memorizzarne le dimensione ecco perché per la FAT32 sono stati usati 4 byte a partire da 24H.

Per verificare quanto scritto prova a digitare i seguenti comandi dal prompt del dos

FAT16 & FAT32:

La FAT è una tabella in cui sono registrate tutti i concatenamenti di cluster necessari a ricostruire un file.

Facciamo un passo indietro e vediamo il motivo per cui c'è bisogno di una FAT.

• Con la FAT la ricerca di cluster liberi si riduce ad una lettura di "pochi" settori (Quelli della FAT) alla ricerca di celle vuote mentre senza la FAT occorrerebbe scandagliare l'HD settore per settore alla ricerca di spazi liberi.
• Per aprire un file basta sapere la posizione del primo cluster e tramite la FAT è possibile (Seguendo i concatenamenti) trovare tutti i cluster che utilizza, senza la FAT si potrebbe pensare di aggiungere dei byte in testa ad ogni cluster che indicano quale sia il cluster successivo (Il Commodore 64 pur usando una piccola FAT usava questo metodo) ma quest'implementazione oltre a non risolvere il primo punto è anche pericolosa, infatti, se uno di questi link salta per qualche motivo le conseguenze possono essere disastrose (Questo può succedere anche con la FAT ed è per questo che essa viene duplicata).
• Ci sono anche altri motivi ma ora mi sfuggono.

NB: i primi due valori (0 e 1) della FAT sono riservati dunque il primo cluster utilizzabile è il 2.

Il primo cluster dell'esempio è il n° 010A1H ed è libero.
Il secondo cluster è il primo di un File e c'informa che il successivo si trova nella posizione 010A3H che ci dice che il successivo è nella posizione 010A4H ... fino alla 010A6H dove si trova il codice di fine file 0FFFFFF8
Nella posizione 010A8H troviamo un altro file che questa volta è piccolo e quindi occupa solo questo cluster.
Infine nelle posizioni 010AAH e 010ACH ci sono due codici speciali, il primo indica la presenza di un cluster riservato mentre il secondo indica che quel cluster è danneggiato.

Dunque:

OSSERVAZIONE: Nella FAT32 in realtà vengono utilizzati solo 28bit.

Per verificare quanto scritto prova a digitare i seguenti comandi dal prompt del dos

Directory:

Come ho già detto la Root viene gestita diversamente a seconda che la FAT sia a 16 o 32 bit.

I dati dei file sono memorizzati nelle directory in questo modo:

I nomi lunghi vengono gestiti da W95 memorizzando nella directory una struttura del tutto analoga a quella appena descritta preceduta da uno o più blocchi della stessa dimensione che contengono il nome completo.

Per mantenere la compatibilità con gli OS precedenti i programmatori della Microsoft hanno sfruttato il fatto che questi (DOS e WIN3.1) interpretano l'attributo del file (0Bh nel descrittore del file) 0Fh saltando il blocco, come se non ci fosse.
Dunque la compatibilità verso il basso viene assicurata semplicemente inserendo, prima della struttura dati che rappresenta il file scritto nel formato "short (8.3)", dei blocchi da 32 byte che riportano come attributo il valore 0F e nei restanti byte le informazioni sul nome lungo.

In realtà le cose sono leggermente più complicate infatti:

• I caratteri del nome del file non vengono salvati come ASCI ma come UNICODE a due byte
• Il primo byte della struttura viene usato come contatore/marcatore di blocco
• Alcuni byte restano riservati

Riporto ora la struttura che viene utilizzata per implementare la gestione dei nomi lunghi dei file in W95.

Il byte (0D) contiene la Check sum che permette al sistema operativo di verificare se il/i blocchi che precedono quello standard (Short a 8.3) sono quelli che contengono il suo nome lungo.
Il calcolo della Check sum vene eseguito con questa funzione:

Esempio di struttura dati per la gestione di un LongFileName.

NB: Quando un file viene cancellato viene inserito il codice 0E5H come primo carattere del nome.

Per verificare quanto scritto prova a digitare i seguenti comandi dal prompt del dos

File & Directory:

Una volta guadagnato l'accesso alla Root è possibile accedere ai file o alle altre directory tramite il primo cluster del file memorizzato nella posizione 1AH per la FAT16 e nella posizione 14H : 1AH per la FAT32.

Due osservazioni:

• L'area dati (Dove sono memorizzati i cluster) inizia per la FAT16 alla fine della Root mentre per la FAT32 all'inizio della Root.
• Se nella struttura che contiene le informazioni del file compare come primo cluster il numero X allora per cercare nella FAT eventuali altri cluster collegati ci si deve spostare alla cella X (X*2 byte o X*4 byte) e seguirne il contenuto fino al marcatore di fine file mentre per leggere i cluster veri e propri occorre ricordare che i cluster 0 ed 1 non esistono dunque una volta trovata l'area dati si va a leggere il settore (X-2)*Numero_Settori_Per_Cluster+Primo_Settore_Area_Dati.

Il campo 1CH (Dimensione del file) della struttura dati che memorizza le informazioni del file è necessario per leggere nel cluster solo le informazioni del file e non tutto il cluster (Es: se il cluster è grande 4K ed il file solo 1K gli altri 3K non vanno letti)

Per commenti, aggiunte, correzioni o altro contattatemi