Aggiunta la shell di Alessio per generare le figure.
[gapil.git] / fileintro.tex
index 010add3be64c39094d05bed03863814924d91641..40d8e2575d262890ff440b6f165c95eb1f563537 100644 (file)
@@ -176,7 +176,8 @@ Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
 i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
+l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
+universale, solo una convenzione.
 
 
 
 
 
 
@@ -296,23 +297,23 @@ POSIX.1 dei sistemi Unix, ed 
 Per capire fino in fondo le proprietà di file e directory in un sistema
 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
 una breve introduzione al funzionamento gestione dei file da parte del kernel
 Per capire fino in fondo le proprietà di file e directory in un sistema
 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
 una breve introduzione al funzionamento gestione dei file da parte del kernel
-e sugli oggetti su cui è basato un filesystem di tipo unix. In particolare
-occorre tenere presente dov'è che si situa la divisione fondamentale fra
-kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
+e sugli oggetti su cui è basato un filesystem. In particolare occorre tenere
+presente dov'è che si situa la divisione fondamentale fra kernel space e user
+space che tracciavamo al \capref{cha:intro_unix}.
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 
 In questa sezione esamineremo come viene implementato l'accesso ai file in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
-prima le caratteristiche generali di un filesystem Unix, per poi trattare in
-maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
+prima le caratteristiche generali di un filesystem di un sistema unix-like,
+per poi trattare in maniera un po' più dettagliata il filesystem standard di
+Linux, l'\acr{ext2}.
 
 
+% in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
+% funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
+% accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
+% \secref{sec:file_vfs}.
 
 
-% in particolare si riprenderà, approfondendolo sul piano
-% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
-% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
-% nel kernel) in \secref{sec:file_vfs}.
 
 
-
-\subsection{Il \textit{virtual filesystem} di Linux}
+\subsection{Il \textit{Virtual Filesystem} di Linux}
 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
 \label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
@@ -322,13 +323,14 @@ maniera un po' pi
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato
 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 
 In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
-l'interfaccia che il kernel rende disponibile ai programmi in user space
-attraverso la quale vengono manipolati i file; esso provvede un livello di
-indirezione che permette di collegare le operazioni di manipolazione sui file
-alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
-modi in cui diversi filesystem la effettuano, permettendo la coesistenza
-di filesystem differenti all'interno dello stesso albero delle directory
+attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+strato intermedio che il kernel usa per accedere ai più svariati filesystem
+mantenendo la stessa interfaccia per i programmi in user space. Esso provvede
+un livello di indirezione che permette di collegare le operazioni di
+manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
+queste ultime nei vari modi in cui diversi filesystem le effettuano,
+permettendo la coesistenza di filesystem differenti all'interno dello stesso
+albero delle directory.
 
 Quando un processo esegue una system call che opera su un file il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
 
 Quando un processo esegue una system call che opera su un file il kernel
 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
@@ -361,17 +363,17 @@ 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
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da 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
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
-il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
-variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
-specifiche per l'uso di quel filesystem.
+il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili
+interne e restituire uno speciale descrittore dei filesystem montati al VFS;
+attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
+l'uso di quel filesystem.
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 una apposita struttura che contiene vari dati come le informazioni comuni ad
 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
-usare le funzioni contenute nel filesystem descriptor per accedere alle routine
-specifiche di quel filesystem.
+usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
+alle routine specifiche di quel filesystem.
 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 
 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
@@ -386,28 +388,28 @@ file gi
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 
 \subsection{Il funzionamento del VFS}
 \label{sec:file_vfs_work}
 
-La funzione più fondamentale implementata dal VFS è la system call
-\func{open} che permette di aprire un file. Dato un pathname viene eseguita
-una ricerca dentro la \textit{directory entry cache} (in breve
-\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
-  entry} (in breve \textit{dentry}) che permette di associare in maniera
-rapida ed efficiente il pathname a una specifica dentry.
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un pathname viene eseguita una ricerca
+dentro la \textit{directory entry cache} (in breve \textit{dcache}), una
+tabella che contiene tutte le \textit{directory entry} (in breve
+\textit{dentry}) che permette di associare in maniera rapida ed efficiente il
+pathname a una specifica \textit{dentry}.
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
 identifica un singolo oggetto del VFS sia esso un file ordinario, una
 directory, un link simbolico, una FIFO, un file di dispositivo, o una
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
 identifica un singolo oggetto del VFS sia esso un file ordinario, una
 directory, un link simbolico, una FIFO, un file di dispositivo, o una
-qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
-``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
-una struttura che sta in memoria, e che oltre alle informazioni sullo
-specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
-da usare per poterlo manipolare.
+qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di
+``file'' riportati in \tabref{tab:file_file_types}). A ciascuno di essi è
+associata pure una struttura che sta in memoria, e che, oltre alle
+informazioni sullo specifico file, contiene anche il riferimento alle funzioni
+(i \textsl{metodi} del VFS) da usare per poterlo manipolare.
 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
-vengono usate per motivi di velocità, gli inode invece stanno su disco e
-vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
-all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
-è ad essi che puntano le singole \textit{dentry}.
+vengono usate per motivi di velocità, gli \textit{inode} invece stanno su
+disco e vengono copiati in memoria quando serve, ed ogni cambiamento viene
+copiato all'indietro sul disco, gli inode che stanno in memoria sono inode del
+VFS ed è ad essi che puntano le singole \textit{dentry}.
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
@@ -421,9 +423,9 @@ della directory che contiene il file; questo viene installato nelle relative
 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 su cui l'inode va a vivere.
 
 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 su cui l'inode va a vivere.
 
-Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
-diventa possibile accedere alle varie operazioni sul file come la
-\func{open} per aprire il file o la \func{stat} per leggere i dati
+Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
+\textit{inode}) diventa possibile accedere alle varie operazioni sul file come
+la \func{open} per aprire il file o la \func{stat} per leggere i dati
 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
@@ -464,44 +466,45 @@ operazioni previste dal kernel 
   \label{tab:file_file_operations}
 \end{table}
 
   \label{tab:file_file_operations}
 \end{table}
 
-In questo modo per ciascun file diventano utilizzabili una serie di operazioni
-(non è dette che tutte siano disponibili), che costituiscono l'interfaccia
-astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
+In questo modo per ciascun file diventano possibili una serie di operazioni
+(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
+astratta del VFS.  Qualora se ne voglia eseguire una il kernel andrà ad
 utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
 utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
-di file in questione. 
+di file in questione.
 
 
-Così sarà possibile scrivere sulla porta seriale come su un file di dati
-normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
-\code{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
-diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
-(relativamente) trasparente per l'utente ed il programmatore.
+In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
+su un file di dati normale; ovviamente certe operazioni (nel caso della
+seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
+sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
+MacOs) è immediato e (relativamente) trasparente per l'utente ed il
+programmatore.
 
 
 
 
-\subsection{Il funzionamento di un filesystem unix}
+\subsection{Il funzionamento di un filesystem Unix}
 \label{sec:file_filesystem}
 
 \label{sec:file_filesystem}
 
-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
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+unix-like) organizza i dati che tiene su disco attraverso l'uso di un
 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à
 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
-daremo una descrizione a grandi linee che si adatta alle caratteristiche
-comuni di un qualunque filesystem standard unix.
+proprie.  Per questo per il momento non entreremo nei dettagli di un
+filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
+alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 
 
-Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; la strutturazione tipica
+Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
+partizione può contenere un filesystem. La strutturazione tipica
 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem unix, indipendentemente da come poi viene
+comune di tutti i filesystem per Unix, indipendentemente da come poi viene
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=9cm]{img/disk_struct}
+  \includegraphics[width=12cm]{img/disk_struct}
   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
   \label{fig:file_disk_filesys}
 \end{figure}
   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
   \label{fig:file_disk_filesys}
 \end{figure}
@@ -514,15 +517,16 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
 
 \begin{figure}[htb]
   \centering
 
 \begin{figure}[htb]
   \centering
-  \includegraphics[width=11cm]{img/filesys_struct}
+  \includegraphics[width=12cm]{img/filesys_struct}
   \caption{Strutturazione dei dati all'interno di un filesystem}
   \label{fig:file_filesys_detail}
 \end{figure}
 
   \caption{Strutturazione dei dati all'interno di un filesystem}
   \label{fig:file_filesys_detail}
 \end{figure}
 
-Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
-cui è bene porre attenzione in quanto sono fondamentali per capire il
-funzionamento delle funzioni che manipolano i file e le directory su cui
-torneremo in seguito; in particolare è opportuno ricordare sempre che:
+Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
+filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prossimo capitolo; in particolare è opportuno
+ricordare sempre che:
 
 \begin{enumerate}
   
 
 \begin{enumerate}
   
@@ -535,8 +539,8 @@ torneremo in seguito; in particolare 
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentry} del kernel di
   cui si parlava in \secref{sec:file_vfs}).
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentry} del kernel di
   cui si parlava in \secref{sec:file_vfs}).
-  
-\item Come mostrato in \curfig si possono avere più voci che puntano allo
+
+\item Come mostrato in \curfig\ si possono avere più voci che puntano allo
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
   numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
   solo quando questo contatore si annulla i dati del file vengono
   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
   numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
   solo quando questo contatore si annulla i dati del file vengono
@@ -544,13 +548,13 @@ torneremo in seguito; in particolare 
   file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
   file, ma si limita a eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti nell'\textit{inode}.
   file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
   file, ma si limita a eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti nell'\textit{inode}.
-  
+
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
   esistente, con la funzione \func{link}) al filesystem corrente.
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
   esistente, con la funzione \func{link}) al filesystem corrente.
-  
+
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non deve essere spostato, viene semplicemente creata una nuova voce
   per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
   del file non deve essere spostato, viene semplicemente creata una nuova voce
   per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
@@ -559,15 +563,15 @@ torneremo in seguito; in particolare 
 
 \end{enumerate}
 
 
 \end{enumerate}
 
-Infine è bene avere presente che essendo file pure loro, esiste un numero di
-riferimenti anche per le directory; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
-directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
-chiarezza abbiamo aggiunto dei numeri di inode.
+Infine è bene avere presente che, essendo file pure loro, esiste un numero di
+riferimenti anche per le directory; per cui se a partire dalla situazione
+mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
+\file{gapil}: avremo una situazione come quella in \nfig, dove per chiarezza
+abbiamo aggiunto dei numeri di inode.
 
 \begin{figure}[htb]
   \centering 
 
 \begin{figure}[htb]
   \centering 
-  \includegraphics[width=11cm]{img/dir_links}
+  \includegraphics[width=12cm]{img/dir_links}
   \caption{Organizzazione dei link per le directory}
   \label{fig:file_dirs_link}
 \end{figure}
   \caption{Organizzazione dei link per le directory}
   \label{fig:file_dirs_link}
 \end{figure}
@@ -586,12 +590,11 @@ adesso sar
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
-caratteristiche di un filesystem standard unix, è in grado di gestire
-filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
-4~Tb. 
+caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
+file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb.
 
 
-Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
-che non sono presenti sugli altri filesystem unix, le cui principali sono le
+Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni che
+non sono presenti sugli altri filesystem Unix, le cui principali sono le
 seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
 seguenti:
 \begin{itemize}
 \item i \textit{file attributes} consentono di modificare il comportamento del
@@ -620,7 +623,7 @@ seguenti:
   log).
 \end{itemize}
 
   log).
 \end{itemize}
 
-La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD:
 un filesystem è composto da un insieme di blocchi, la struttura generale è
 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 è divisa in gruppi di blocchi.
 un filesystem è composto da un insieme di blocchi, la struttura generale è
 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 è divisa in gruppi di blocchi.