Si prosegue con l'architettura dei file

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index 479ff86bf653717444cc04653c5819336984ff5e..7ed71e42b654c555d63ac01d0eab07c2ce84116b 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -391,32 +391,34 @@ file gi
 \label{sec:file_vfs_work}
 
 La funzione più fondamentale implementata dal VFS è la system call
 \label{sec:file_vfs_work}
 
 La funzione più fondamentale implementata dal VFS è la system call

-\texttt{open} che permette di aprire un file. Dato un pathname viene eseguita
+\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.
 
 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.
 

-Una singola 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, 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.
-
-Le 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 dentry.
-
-La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei
-file, ovviamente per non riempire tutta la memoria questa vista è parziale
-(la dcache cioè contiene solo le dentry per i file per i quali è stato
-richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
-creare una nuova dentry e caricare l'inode corrispondente in memoria. 
+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.
+
+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}.
+
+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 è
+parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
+per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
+pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode
+corrispondente in memoria.

 
 Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
 della directory che contiene il file; questo viene installato nelle relative
 
 Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
 della directory che contiene il file; questo viene installato nelle relative


@@ -430,12 +432,12 @@ dell'inode e passarli in user space.
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 una struttura di tipo \var{file} in cui viene inserito un puntatore alla
 
 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 una struttura di tipo \var{file} in cui viene inserito un puntatore alla

-dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che
-implementano le operazioni disponibili sul file. In questo modo i processi in
-user space possono accedere alle operazioni attraverso detti metodi, che
-saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo
-torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle operazioni
-previste dal kernel è riportato in \ntab.
+\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
+metodi che implementano le operazioni disponibili sul file. In questo modo i
+processi in user space possono accedere alle operazioni attraverso detti
+metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
+(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
+operazioni previste dal kernel è riportato in \ntab.

 
 \begin{table}[htb]
   \centering
 
 \begin{table}[htb]
   \centering


@@ -469,12 +471,12 @@ previste dal kernel 
 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 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

-utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo
+utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo

 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
 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

-\textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
+\func{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.
 
 diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
 (relativamente) trasparente per l'utente ed il programmatore.
 


@@ -494,9 +496,9 @@ comuni di un qualunque filesystem standard unix.
 Dato un disco lo spazio fisico 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
 Dato un disco lo spazio fisico 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 ext2, che prevede una separazione dei dati in
-\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di
-ext2 torneremo in \secref{sec:file_ext2}). È comunque caratteristica
+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
 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 comune di tutti i filesystem 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.


@@ -586,7 +588,7 @@ adesso sar
 \label{sec:file_ext2}
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
 \label{sec:file_ext2}
 
 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended

-  filesystem}, identificato dalla sigla \textsl{ext2}. Esso supporta tutte le
+  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
 filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 


@@ -604,9 +606,9 @@ seguenti:
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SYSV comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
   con lo stesso identificatore di gruppo della directory che li contiene. La
   semantica SYSV comporta che i file vengono creati con l'identificatore del
   gruppo primario del processo, eccetto il caso in cui la directory ha il bit

-  di sgid settato (per una descrizione dettagliata del significato di questi
-  termini si veda \secref{sec:file_access_control}), nel qual caso file e
-  sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}.
+  di \acr{sgid} settato (per una descrizione dettagliata del significato di
+  questi termini si veda \secref{sec:file_access_control}), nel qual caso file
+  e sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}.

 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).


@@ -631,7 +633,6 @@ filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale.
 
 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 superblock principale.
 

-

 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct.eps}  
 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct.eps}  


@@ -641,7 +642,7 @@ superblock principale.
 
 L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 
 L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli

-inodes. 
+inode. 

 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
 
 Le directory sono implementate come una linked list con voci di dimensione
 variabile. Ciascuna voce della lista contiene il numero di inode, la sua


@@ -651,5 +652,3 @@ in questo modo 
 
 
 
 
 
 

-
-