\chapter{L'architettura dei file}
\label{cha:file_intro}
-Uno dei concetti fondamentali della architettura di unix è il cosiddetto
-\textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
-di input/output del computer viene effettuato attraverso un'interfaccia
-astratta che tratta le periferiche allo stesso modo degli usuali file di dati.
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+dispositivi di input/output del computer viene effettuato attraverso
+un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
+file di dati.
Questo significa che si può accedere a qualunque periferica del computer,
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.
-In questo capitolo forniremo un'introduzione all'architettura della gestione
-dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
-nelle particolarità che ha la specifica implementazione usata da Linux. Al
-contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
-varie caratteristiche distintive.
+In questo capitolo forniremo una panoramica dell'architettura dei file, sia
+nelle sue caratteristiche generali, comuni a tutti gli Unix, che nelle
+particolarità che ha la specifica implementazione usata da Linux.
-\section{L'organizzazione di file e directory}
-\label{sec:file_organization}
+\section{L'architettura dell'accesso ai file}
+\label{sec:file_access_arch}
-Il primo passo nella trattazione dell'architettura della gestione dei file in
-un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
-di quale è la struttura che hanno all'interno del sistema.
+Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
+le opportune interfacce che consentano di leggerne il contenuto; il sistema
+cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
+l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
+fatto strutturando l'informazione sul disco attraverso quello che si chiama un
+\textit{filesystem}, essa poi viene resa disponibile attraverso quello che
+viene chiamato il \textsl{montaggio} del filesystem.
+% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
+In questa sezione faremo una panormamica generica su come il sistema presenta
+i file ai processi, trattando l'organizzazione di file e directory, i tipi di
+file ed introducendo le interfacce disponibili, che saranno approfondite nei
+capitoli seguenti.
-\subsection{La struttura di file e directory}
+
+\subsection{L'organizzazione di file e directory}
\label{sec:file_file_struct}
-Partiamo allora da come viene strutturata nel sistema la disposizione dei
-file: per potervi accedere il kernel usa una apposita interfaccia che permetta
-di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
-dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
- brevità questo nome al posto della più prolissa traduzione italiana sistema
- di file}, che descriveremo in dettaglio in \secref{sec:file_vfs}.
-
-Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
-memorizzati all'interno del disco stesso, strutturando l'informazione in file
-e directory. Per poter accedere ai file contenuti in un disco occorrerà
-perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
-(o la partizione del disco).
-
-%In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
-%informazioni riservate che tengono conto degli inodes allocati, di quelli
-%liberi, e delle posizioni fisiche su disco dei dati contenuti nei file, per
-
-In unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
-file vengono tenuti all'interno di un unico albero la cui radice (la directory
-di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
-dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
-percorso che si deve fare per accedere al file.
+In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
+file vengono tenuti all'interno di un unico albero la cui radice (quella che
+viene chiamata \textit{root directory}) viene montata all'avvio. Pertanto
+un file viene identificato dall'utente usando quello che viene chiamato
+\textit{pathname}, cioè il percorso che si deve fare per accedere al file.
Dopo la fase di inizializzazione il kernel riceve dal boot loader
l'indicazione di quale dispositivo contiene il filesystem da usare come punto
di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
-nell'albero utilizzando opportune subdirectory.
+directory \file{/}); tutti gli ulteriori filesystem che possono essere su
+altri dispositivi devono poi essere inseriti nell'albero utilizzando opportune
+subdirectory.
Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
alcune strutture interne del kernel) sono generati automaticamente dal kernel
convenzione, sono inseriti nella directory \file{/dev}).
L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
-medesimi nell'albero descritto in precedenza; una directory comunque, come già
-specificato in \secref{sec:file_vfs}, è solo un particolare tipo di file
-che contiene le informazioni che associano un nome al contenuto.
+medesimi nell'albero descritto in precedenza; una directory comunque, come
+vedremo in \secref{sec:file_vfs_work}, è solo un particolare tipo di file che
+contiene le informazioni che associano un nome al contenuto.
% Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
% una directory contiene solo delle etichette per fare riferimento ai file
% stessi.
-I manuale delle glibc chiama i nomi contenuti nelle directory
+I manuale delle \acr{glibc} chiama i nomi contenuti nelle directory
\textsl{componenti} (in inglese \textit{file name components}), noi li
chiameremo più semplicemente \textit{nomi}. Un file può essere indicato
rispetto alla directory corrente semplicemente specificando il nome da essa
directory.
Il nome completo di file generico è composto da una serie di nomi separati da
-una \file{/} (in Linux più \file{/} consecutive sono considerate
-equivalenti ad una sola). Il nome completo di un file viene usualmente
-chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo
-nome (poiché genererebbe confusione, dato che con \textit{path} si indica
-anche un insieme di directory su cui effettuare una ricerca, come quello in
-cui si cercano i comandi); non seguiremo questa scelta dato che l'uso della
-parola \textit{pathname} è ormai così comune che è senz'altro più chiaro
-dell'alternativa proposta.
-
-Il processo con cui si associa ad un pathname uno specifico file è chiamato
-risoluzione del nome (\textit{file name resolution} o \textit{pathname
- resolution}). La risoluzione viene fatta esaminando il pathname da destra a
-sinistra e localizzando ogni nome nella directory indicata dal nome
-precedente: ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi devono consentire l'accesso.
+una \file{/} (in Linux più \file{/} consecutive sono considerate equivalenti
+ad una sola). Il nome completo di un file viene usualmente chiamato
+\textit{pathname}, e anche se il manuale della \acr{glibc} depreca questa
+nomenclatura\footnote{poiché genererebbe confusione, dato che con
+ \textit{path} si indica anche un insieme di directory su cui effettuare una
+ ricerca, come quello in cui si cercano i comandi}; non seguiremo questa
+scelta dato che l'uso della parola \textit{pathname} è ormai così comune che è
+senz'altro più chiaro dell'alternativa proposta.
+
+Il procedimento con cui si associa ad un pathname uno specifico file è
+chiamato risoluzione del nome (\textit{file name resolution} o
+\textit{pathname resolution}). La risoluzione viene fatta esaminando il
+pathname da destra a sinistra e localizzando ogni nome nella directory
+indicata dal nome precedente: ovviamente perché il procedimento funzioni
+occorre che i nomi indicati come directory esistano e siano effettivamente
+directory, inoltre i permessi devono consentire l'accesso.
Se il pathname comincia per \file{/} la ricerca parte dalla directory radice
del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
sono implementati come oggetti del \textit{Virtual File System} (vedi
-\secref{sec:file_vfs}) e sono presenti in tutti i filesystem unix-like
+\secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual
File System è riportato in \ntab.
\textit{regular file} & \textsl{file normale} &
un file che contiene dei dati (l'accezione normale di file) \\
\textit{directory} & \textsl{cartella o direttorio} &
- un file che contiene una lista di nomi associati a degli inodes \\
+ un file che contiene una lista di nomi associati a degli \textit{inodes}
+ (vedi \secref{sec:file_vfs}). \\
\textit{symbolic link} & \textsl{collegamento simbolico} &
un file che contiene un riferimento ad un altro file/directory \\
\textit{char device} & \textsl{dispositivo a caratteri} &
\section{L'architettura della gestione dei file}
-\label{sec:file_architecture}
+\label{sec:file_arch_func}
Per capire fino in fondo le proprietà di file e directory in un sistema
unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
\end{figure}
Il VFS definisce un insieme di funzioni che tutti i filesystem devono
-implementare. L'interfaccia comprende tutte le funzioni che riguardano i
-file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
-e file, corrispondenti a tre apposite strutture definite nel kernel.
+implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
+le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
+\textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
+definite nel kernel.
Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
filesystem supportato: quando si vuole inserire il supporto di un nuovo
(\var{file\_system\_type}) che contiene i dettagli per il riferimento
all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
-
In questo modo quando viene effettuata la richiesta di montare un nuovo disco
(o qualunque altro \textit{block device} che può contenere un filesystem), il
VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
in generale) organizza i dati che tiene su disco attraverso l'uso di un
-filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
+filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / commitdiff