Quando si migra da un sistema operativo come Microsoft Windows ad un altro, una cosa che influenza profondamente l'utente finale è, in modo particolare, la differenza tra i filesystem.
Cosa sono i filesystem?
Un filesystem è l'insieme dei metodi e strutture di dati che un sistema operativo usa per tener traccia dei file su un disco o su una partizione; cioè, il modo in cui i file sono organizzati sul disco. La parola è usata anche per riferirsi a una partizione o disco usati per archiviare i file, o per indicare il tipo del filesystem. Così, uno potrebbe dire: "Ho due filesystem", volendo intendere che ha due partizioni sulle quali memorizza i file, o che sta usando l'"exetended filesystem", intendendo il tipo di filesystem.
La differenza fra un disco o partizione e il filesystem che vi è contenuto è importante. Alcuni programmi (includendo, a maggior ragione, i programmi che creano filesystem) operano direttamente sui settori grezzi di un disco o partizione; se c'è un file system esistente verrà distrutto o seriamente danneggiato. La maggior parte dei programmi opera su di un filesystem, e quindi non funziona su una partizione che non ne contiene uno (o che ne contiene uno del tipo sbagliato).
Prima che una partizione o disco possano essere usati come filesystem, devono essere inizializzati e devono essere scritte le strutture di dati per l'archiviazione (sulla partizione o sul disco). Questo processo è chiamato creazione di un filesystem.
La maggior parte dei tipi di filesystem UNIX ha una struttura generale simile, sebbene nel dettaglio vari notevolmente I concetti fondamentali del filesystem sono: superblocco, inode, blocco di dati, blocco di directory, e blocco di indirezione. Il superblocco contiene informazioni riguardo al filesystem nella sua interezza, come le sue dimensioni (l'informazione precisa dipende dal filesystem). Un inode contiene tutte le informazioni sul file, ad eccezione del suo nome. Il nome è memorizzato nella directory, insieme al numero di inode. Un elemento di directory consiste di un nome del file e del numero di inode che rappresenta il file. L'inode contiene i numeri di diversi blocchi di dati, che sono usati per archiviare i dati nel file. C'è spazio solo per pochi numeri di blocchi di dati nell'inode, in ogni caso, e se è necessario, uno spazio aggiuntivo, per puntatori di blocchi di dati, è allocato dinamicamente. Questi blocchi, allocati dinamicamente, sono blocchi indiretti; il nome indica che per trovare il blocco di dati, si deve trovare prima il suo numero nel blocco indiretto.
Come in UNIX, si è scelto anche in Linux di avere una singola gerarchia della struttura di directory. Ogni cosa ha inizio dalla directory root (radice), rappresentata da /, e che si espande in sottodirectory invece di avere i cosidetti 'drive'. Nell'ambiente Windows si possono mettere i propri file praticamente ovunque: sul drive C, drive D, drive E etc. Un tale file system è chiamato una struttura gerarchica ed è gestito dagli stessi programmi (directory di programma), non dal sistema operativo. D'altra parte, in Linux le directory sono ordinate partendo dalla directory root / secondo la loro importanza nel processo di avvio.
Qualcuno potrebbe chiedersi perché Linux usa la barra obliqua normale / invece della barra obliqua rovesciata \ come in Windows; il motivo è semplice: perché segue la tradizione di UNIX. Linux, come Unix, è anche sensibile alle maiuscole/minuscole. Questo significa che è molto importante se i caratteri sono in maiuscolo o minuscolo. Così "questo" non è lo stesso di "QUESTO". Questa caratteristica spiega gran parte dei problemi per i nuovi utenti, specialmente nel corso di operazioni di trasferimento di file, sia che avvengano tramite supporti rimovili come floppy disk o attraverso una connessione ftp.
L'ordinamento del filesystem è specifico alla funzione di un file e non al contesto del suo programma (la maggior parte dei filesystem di Linux sono 'Second Extended File Systems', in breve 'EXT2' (detti anche 'ext2fs' o 'extfs2') o sono essi stessi sottoinsiemi di questo filesystem come ext3 e Reiserfs). È all'interno di questo filesystem che il sistema operativo determina in quali directory i programmi archiviano i loro file.
Se si installa un programma in Windows, la maggior parte dei suoi file vengono archiviati nella propria struttura di directory. Per esempio un file di aiuto si può trovare in C:\Program Files\[nome programma]\ o in C:\Program Files\[nome-programma]\help o in C:\Program Files\[nome-programma]\humpty\dumpty\doo. In Linux, i programmi mettono la loro documentazione in /usr/share/doc/[nome-programma], le pagine (di) man(uale) in /usr/share/man/man[1-9] e le pagine info in /usr/share/info. Essi confluiscono e si fondono nella gerarchia del sistema.
Come tutti gli utenti Linux sanno, a meno che non si "monti" una partizione o un dispositivo, il sistema non è in grado di rilevare l'esistenza di quella partizione o dispositivo. Questo potrebbe sembrare non essere il modo più facile per fornire un accesso alle proprie partizioni o dispositivi, tuttavia offre il vantaggio di una flessibilità di gran lunga superiore se paragonata ad altri sistemi operativi. Questo genere di schema, conosciuto come "filesystem unificato", fornisce diversi vantaggi rispetto all'approccio usato da Windows. Prendiamo l'esempio della directory /usr. Questa sottodirectory della directory root contiene la maggior parte degli eseguibili di sistema. Con il filesystem Linux, si può scegliere di montarla su un'altra partizione, o anche su un'altra macchina in rete usando un insieme innumerevole di protocolli come NFS (Sun), Coda (CMU) o AFS (IBM). La differenza non viene rilevata dal sistema sottostante, e non deve esserlo. La presenza della directory /usr è completamente trasparente. Appare come una directory locale che fa parte della struttura di directory locale.
La conformità richiede che:
+---------+-----------------+-------------------+ | | condivisibile | non condivisibile | +---------+-----------------+-------------------+ |statici | /usr | /etc | | | /opt | /boot | +---------+-----------------+-------------------+ |variabli | /var/mail | /var/run | | | /var/spool/news | /var/lock | +---------+-----------------+-------------------+ I file "condivisibili" sono definiti come quelli che possono essere archiviati su un host e usati in altri. I file "non condivisibili" sono quelli che non possono essere condivisi. Per esempio, i file nelle directory home dell'utente sono condivisibili mentre i device lock file non lo sono. I file "statici" includono binari, librerie, file di documentazione e altri file che non cambiano senza l'intervento dell'amministratore del sistema. I file "variabili" son definiti come file che non sono statici.
Un altro motivo a favore di questo filesystem unificato è che Linux conserva nella cache una grande quantità di accessi al disco utilizzando la memoria di sistema mentre è in esecuzione, per accelerare questi processi. È quindi di vitale importanza che questi buffer siano svuotati (il loro contenuto scritto su disco), prima che si arresti il sistema. Altrimenti i file sono lasciati in uno stato indeterminato, e ciò è una cosa naturalmente molto negativa. Lo svuotamento è ottenuto 'smontando' le partizioni durante l'arresto del sistema (quando avviene nel modo appropriato). In altre parole, non si deve spegnere il sistema mentre è in esecuzione! Può andar bene diverse volte, poiché il file system di Linux è molto robusto, ma si possono anche distruggere file importanti. Premere semplicemente i tasti ctrl-alt-del o usare i comandi appropriati (p.es. shutdown, poweroff, init 0). Questo provoca l'arresto del sistema in modo adeguato, garantendo così l'integrità dei propri file.
Molte persone nella comunità Linux danno per scontata l'esistenza di libri e documenti riguardo a Linux di eccellente qualità, per fare un esempio, quelli prodotti dal Linux Documentation Project. Siamo abituati a disporre di numerosi pacchetti scaricati da diverse fonti, come siti Linux FTP e CD-ROM delle distribuzioni, che si integrano insieme senza difficoltà. È considerata come una cosa ovvia sapere dove si possono trovare i file cruciali come mount su ogni macchina che esegue Linux. È dato per scontato anche l'uso delle distribuzioni basate su CD-ROM che possono essere eseguite direttamente da CD, e che occupano solo una piccola quantità di disco rigido fisico o di disco RAM per alcuni file variabili come /etc/passwd, etc. Ma non è sempre stato così.
Negli anni "adolescenziali" di Linux, durante la prima metà degli anni '90, ogni distributore aveva il suo schema preferito per posizionare i file nella gerarchia della directory. Sfortunatamente questo causò molti problemi. Il Linux File System Structure è un documento che fu creato per cercare di porre fine a quest'anarchia. Spesso il gruppo che produce questo documento, o il documento stesso, è indicato come FSSTND. Questa è l'abbreviazione di "file system standard". Questo documento ha contribuito a standardizzare ovunque la struttura dei file system sui sistemi Linux. Sin dalla release originale dello standard, la maggior parte dei distributori lo hanno adottato in tutto o in parte, con grande beneficio per tutti gli utenti Linux.
Sin dalla prima stesura dello standard, il progetto FSSTND è stato coordinato da Daniel Quinlan, e lo sviluppo di questo standard è avvenuto col consenso di un gruppo di sviluppatori e di appassionati di Linux. Il gruppo FSSTND si propone di portare a termine un certo numero di obiettivi specifici. Il primo obiettivo era quello di risolvere un certo numero di problemi che c'erano con le distribuzioni presenti a quel tempo. Prima di allora non era possibile avere una partizione /usr condivisibile, non c'era una chiara distinzione fra /bin and /usr/bin, non era possibile impostare una workstation senza dischi, e c'era solamente una generale confusione su quali file dovessero andare dove . Il secondo obiettivo era di mantenere una ragionevole compatibilità con gli standard "de facto" già in uso in Linux e in altri sistemi operativi di tipo UNIX. Infine, lo standard doveva ottenere l'approvazione generale degli sviluppatori, distrubutori e utenti all'interno della comunità Linux. Senza tale supporto lo standard sarebbe stato poco utile, diventando semplicemente un altro modo di rappresentare il file system.
Fortunatamente, il FSSTND ha avuto successo, sebbene ci siano anche alcuni obiettivi che il progetto FSSTND non si era proposto di raggiungere. Il FSSTND non tenta di emulare lo schema di nessun sistema operativo UNIX commerciale specifico (p.es. SunOS, AIX, etc.). Inoltre, per molti dei file contemplati dal FSSTND, lo standard non richiede che i file siano presenti, ma indica solamente dove i file dovrebbero essere se fossero presenti. Infine, per la maggior parte dei file, il FSSTND non tenta di imporre il formato del contenuto dei file (ci sono alcune particolari eccezioni quando diversi pacchetti distinti possono aver bisogno di conoscere il formato dei file per lavorare insieme in modo appropriato; per esempio, i file di lock che contengono l'ID del processo del processo bloccato dal lock). L'obiettivo generale era stabilire la posizione dove i file comuni potevano essere trovati, se esistenti su una certa macchina. Il progetto FSSTND ebbe inizio ai primi di agosto del 1993. Da allora, ci sono state diverse revisioni ufficiali di questo documento. L'ultima, la v2.3, è stata rilasciata il 29 gennaio 2004.
Ora il lettore si starà chiedendo: "Qual'è lo scopo di tutto ciò?" Bene, la risposta dipende da chi è l'interlocutore. Per l'utente Linux, che non amministra il proprio sistema, il FSSTND garantisce che sia in grado di trovare i programmi dove si aspetta che siano se ha già avuto esperienza su un'altra macchina Linux. Garantisce anche che qualsiasi documentazione di cui disponga abbia un senso. Inoltre, se ha già avuto qualche esperienza di Unix in precedenza, il FSSTND non dovrebbe essere troppo diverso da quello che sta usando attualmente, con poche eccezioni. Forse la cosa più importante è che lo sviluppo di uno standard porta Linux a un livello di maturità tale che autori e sviluppatori di applicazioni commerciali sentono di poterlo supportare.
Per gli amministratori della propria macchina, questi godono di tutti i benefici del FSSTND menzionati precedentemente. Si sentiranno inoltre più sicuri delle capacità degli altri nel fornire assistenza, nella risoluzione di eventuali problemi. Inoltre, aggiornamenti periodici del sistema sono teoricamente più facili. Dato che c'è uno standard condiviso per le posizioni dei file, i responsabili dei pacchetti possono fornire istruzioni per l'aggiornamento, in modo da non lasciare cose superflue e vecchi file sparsi in giro per il sistema, occupando spazio prezioso sul disco. Il FSSTND significa anche che da quei pacchetti forniti col codice sorgente c'è un maggiore supporto per compilarli e installarli da se stessi. Il fornitore sa, per esempio, dove l'eseguibile per "sed" possa essere trovato in una macchina Linux e può usare quello nel suo script d'installazione e nei Makefile.
Per chi gestisce una grossa rete, il FSSTND può ridurre molti dei "grattacapi" con NFS, poiché è particolarmente adatto per gestire i problemi che in passato hanno reso irrealizzabili implementazioni condivise di /usr. Il distributore sarà influenzato molto dal FSSTND Linux. Ci vorrà un po' di lavoro in più per assicurarsi che la distrubuzione sia conforme al FSSTND, ma gli utenti (e quindi le aziende) ne guadagneranno. Se il sistema è conforme, i pacchetti aggiuntivi di terze parti (e possibilmente i propri) si integreranno agevolmente col sistema. Gli utenti, naturalmente, avranno tutti i benefici visti sopra, e molti dei problemi per il supporto saranno semplificati. Si hanno a disposizione tutte le discussioni e le considerazioni confluite nel FSSTND e si evitano molte delle insidie insite nel progettare da soli una struttura di filesystem. Aderendo al FSSTND si può trarre vantaggio da diverse caratteristiche attorno alle quali è stato costruito il FSSTND. Per esempio, il FSSTND rende possibile che i CD-ROM "live" contengano tutto tranne alcuni file nelle directory / e /var. Se si scrive della documentazione per Linux, il FSSTND rende più facile farla in modo che abbia un significato per la comunità Linux. Non c'è più bisogno di preoccuparsi della posizione specifica dei file di lock in una distribuzione piuttosto che in un'altra, nè si è costretti a scrivere documentazione utile solo agli utenti di una distribuzione specifica. La FSSTND è almeno in parte responsabile della recente "esplosione" di libri pubblicati su Linux.
Per gli sviluppatori, l'esistenza del FSSTND riduce fortemente la possibilità di potenziali problemi. Si possono sapere dove si trovano i binari di sistema importanti, così da usarli all'interno dei propri programmi o script di shell. Dare assistenza agli utenti viene reso inoltre più facile, poiché non ci si deve preoccupapre di cose come la posizione di questi binari quando si devono risolvere problemi in fase di assistenza. Se si sta lavorando allo sviluppo di un programma che deve integrarsi col resto del sistema, seguendo il FSSTND lo sviluppatore sa con certezza i passi da seguire per raggiungere questo risultato. Per esempio, applicazioni come kermit, che permette l'accesso tramite le porte seriali, hanno bisogno di sapere che esse possono ottenere un accesso esclusivo al dispositivo TTY. Il FSSTND specifica un metodo comune per fare questo così che tutte le applicazioni conformi possono lavorare insieme. In questo modo ci si può concentrare nel fare un software con migliori prestazioni per Linux invece di preoccuparsi di come scoprire e affrontare le differenze di gusto di Linux. L'accettazione generale del FSSTND da parte della comunità di Linux è stato determinante per il successo sia dello standard che del sistema operativo. Quasi ogni distribuzione moderna si uniforma al FSSTND Linux. Se l'implementazione non è almeno parzialmente conforme al FSSTND, probabilmente o è molto vecchia o è stata costruita da soli. Lo stesso FSSTND contiene una lista di alcune distribuzioni che sono orientate verso la conformità con il FSSTND. Tuttavia, ci sono alcune distribuzioni che sono note per fare qualche modifica alla loro implementazione del FSSTND.
Questo non vuol dire assolutamente che lo standard è di per se completo. Ci sono ancora questioni irrisolte, come l'organizzazione di script indipendenti dall'architettura e i file di dati in /usr/share. Fino ad ora, la i386 è stata la piattaforma principale per Linux, cosicché non vi era la necessità della standardizzazione di questi file.
Il rapido progresso nel portare Linux su altre architetture (MC680x0, Alpha, MIPS, PowerPC) suggerisce che questa questione dovrà essere trattata presto. Un'altra questione che è oggetto di alcune discussioni è la creazione di una directory /opt come in SVR4. L'obiettivo di questa directory dovrebbe essere quello di fornire una posizione ai pacchetti commerciali di grande diffusione o di terze parti, perché si installino senza preoccuparsi dei requisiti richiesti da FSSTND per le gerarchie delle altre directory. Il FSSTND fornisce alla comunità Linux un eccellente documento di riferimento, e si è rivelato come un fattore importante nella maturazione di Linux. Poiché Linux continua ad evolversi, si evolverà di conseguenza anche il FSSTND.
Ora che abbiamo visto come le cose dovrebbero essere, diamo uno sguardo al mondo reale. Come si vedrà, l'implementazione di questo concetto su Linux non è perfetto, e siccome Linux ha sempre attratto individualisti che tendono a essere piuttosto ostinati, è stato oggetto di dispute fra utenti, per esempio, in quali directory dovrebbero essere messi certi file. Con l'arrivo di diverse distribuzioni, l'anarchia è discesa ancora una volta fra di noi. Alcevidenteune distribuzioni mettono le directory per il montaggio dei supporti esterni nella directory /, altre in /mnt. Le distribuzioni basate su Red Hat si caratterizzano per la sottogerarchia /etc/sysconfig per i file di configurazione concernenti i dispositivi di input e di rete. Altre distribuzioni non hanno affatto questa directory e mettono i file appropriati altrove, o usano anche un meccanismo completamente diverso per fare la stessa cosa. Alcune distribuzioni mettono KDE in /opt/, altre in /usr.
Ma, anche all'interno di una data gerarchia del file system, vi sono incongruenze. Per esempio, anche se questa non è mai stata l'intenzione del gruppo XFree86, XFree86 ha in realtà la propria gerarchia di directory.
Questi problemi non si manifestano fintanto che ci si compila i programmi da soli. Si possono adattare gli script di configurazione o i Makefile in base alla configurazione del proprio sistema o secondo le proprie preferenze. La storia è differente se si installano pacchetti precompilati come gli RPM. Spesso questi non son adattabili da una gerarchia di file system ad un'altra. C'è di peggio: alcuni RPM potrebbero anche creare una loro propria gerarchia. Se, diciamo, si installa un RPM KDE per la distribuzione SuSE Linux sul sistema Mandrake, i binari saranno messi in /opt/kde2/bin. E quindi non funziona, perché Mandrake si aspetta che siano in /usr/bin. Naturalmente ci sono modi per aggirare questo problema ma la situazione corrente è chiaramente insostenibile. Così, tutti i più importanti distributori Linux sono entrati a far parte del progetto Linux Standard Base, che sta tendando di creare uno standard condiviso per le distribuzioni Linux. Questo non è facile, perché cambiare la gerarchia del file system significa una gran quantità di lavoro per i distributori, così ogni distributore preme per uno standard che gli permette di mantenere la maggior parte possibile della propria gerarchia. Il LSB includerà anche le proposte fatte dal progetto Hierarchy Standard (FHS, vecchio FSSTND).