Unix File System

Da Wikipedia, l'enciclopedia libera.

UFS (Unix File System) è un file system usato principalmente in sistemi operativi Unix e Unix-like. È un derivato del Berkeley Fast File System, che fu a sua volta sviluppato a partire dal FS usato dalla prima versione di Unix realizzata presso i Bell Labs.

Pressoché tutti i derivati di BSD, inclusi FreeBSD, NetBSD, OpenBSD, NEXTSTEP e Solaris, usano una variante di UFS. In Mac OS X è disponibile come alternativa a HFS+. In Linux è disponibile un supporto parziale a UFS, mentre il primo file system usato per solo linux, ext2, è anch'esso derivato da UFS.

Implementazione e struttura[modifica | modifica sorgente]

Un filesystem UFS è composto dalle seguenti componenti:

  • il primo settore del disco (512 byte) contiene la tabella delle partizioni.
  • un piccolo numero di blocchi posizionati all'inizio della partizione (dal 1° al 15 ° settore) sono destinati al boot (e inizializzati separatamente dal filesystem stesso)
  • un superblocco, contenente un magic number che identifica il filesystem come UFS ed altri parametri di importanza vitale che descrivono la geometria del filesystem e alcune statistiche.
  • una serie di gruppi di cilindri. Ogni gruppo contiene:
    • una copia di backup del superblocco
    • il numero delle directory
    • il numero di inode, i quali comprendono i dati sugli attributi dei file che contengono
    • un header, che contiene alcune statistiche, tra le quali, la lista dei blocchi e degli inode liberi, la frammentazione nei gruppi di cilindri. È simile al superblocco, ma applicato ad ogni gruppo di cilindri
    • il numero di blocchi per i dati nel gruppo di cilindri
    • la mappa dei blocchi liberi
    • la mappa degli inode usati

Gli inode sono numerati in sequenza: i primi due inode sono riservati per motivazioni storiche, e sono seguiti immediatamente dall'inode della root directory, che è pertanto sempre l'inode 2.

I file che descrivono le directory contengono solo i nomi e i puntatori agli inode degli elementi che contengono. Tutti i metadati sono conservati nell'inode stesso.

Storia ed evoluzione[modifica | modifica sorgente]

Le prime versioni di Unix file system sono state denominate semplicemente come FS. FS includeva solo il blocco di boot, il superblocco, un gruppo di inode e blocchi di dati. Questo file system ha funzionato bene per i primi piccoli dischi Unix, ma l'avanzamento di tecnologia e l'ingrandimento dei dischi, il movimento della testina avanti e indietro tra i gruppi di inode e i riferimenti ai blocchi di dati causavono thrashing(thrashing è una situazione in cui vengono utilizzate grandi quantità di risorse del computer per fare una quantità minima di lavoro, con il sistema in un continuo stato di insufficienza delle risorse.). Marshall Kirk McKusick, allora una studente di berkeley, ottimizza il FS per il sistema operativo 4.2BSD chiamandolo FFS(Fast File System) inventando i gruppi di cilindri. Questo divide il disco in tanti piccoli chunks, ognuno con un proprio groppo di inode e blocchi di dati.

L'intento di BSD FFS è di cercare di localizzare i blocchi di dati e metadati associati nello stesso gruppo di cilindri, e, idealmente, inserire tutto il contenuto di una directory (entrambi i dati e metadati per tutti i file), nello stesso o nelle vicinanze di gruppo di cilindri, riducendo così la frammentazione causata dalla dispersione del contenuto di una directory su un disco intero.

Alcuni dei parametri di prestazione nel superblocco includevano numero di tracce e settori, la velocità di rotazione del disco, la velocità della testina, e l'allineamento dei settori tra le tracce. In un sistema completamente ottimizzato, la testina potrebbe essere spostata vicino alle tracce per leggere i settori sparsi alternati da brani durante l'attesa per il piatto a girare vorticosamente.

Come dischi diventavano sempre più grandi, le ottimizzazioni a livello di settore sono diventate obsolete (in particolare con i dischi che utilizzavano numerazione lineare dei settori e settori variabili per traccia). Con I dischi più grandi e file più grandi, la lettura dei frammenti è diventata un problema. Per combattere questo, BSD originalmente aumentava la dimensione dei blocchi nel file system da un settore a 1k nel 4.0BSD; e nel FFS aumentava la dimensione dei blocchi nel file system da 1k a 8k. questo ha diversi effetti. La possibilità dei settori dei file di essere continui è maggiore. La quantità di overhead per elencare i blocchi dei file è ridotta. Il numero di byte rappresentabile da un determinato numero di blocchi è aumentato; poiché il massimo numero di blocchi è limitato da una larghezza fissa del blocco, questo è consentito anche per i dischi di grande dimensione.

Con blocchi di grande dimensione, dischi con molti file piccoli potrebbero sprecare molto spazio, così BSD ha aggiunto la frammentazione a livello di blocco (chiamato anche suballocation blocco), dove l'ultimo blocco parziale di dati provenienti da diversi file possono essere memorizzati in un unico frammento di blocco, invece di più blocchi per lo più vuoti (Allen 2005).

Presente e futuro[modifica | modifica sorgente]

In molti sono coloro che hanno adattato UFS ai loro propri scopi, aggiungendo estensioni proprietarie non compatibili con le versioni degli altri. Sorprendentemente alcuni hanno continuato ad usare la dimensione originale dei blocchi e dei campi dati, ed alcuni margini di compatibilita' tra versioni (almeno in fase di lettura del filesystem) sono rimasti.

FreeBSD 5.0 ha introdotto UFS2, che dispone del supporto per volumi di oltre 1 TB.

Linux ha il filesystem EXT2, scritto da zero ma basato sui principi di UFS, mentre non dispone, a causa dell'assenza di uno standard unificato di UFS, di uno strumento per poter scrivere su tale filesystem.

Dal 2004 Sun Microsystems ha introdotto il "logging on" su Solaris 7, rendendo così l'UFS un File System journaled (vedi journaling). Solaris dispone inoltre di diverse estensioni per la manipolazione di grandi file e grandi volumi.

Collegamenti esterni[modifica | modifica sorgente]