Rifinitura degli indici, correzioni ortografiche varie.

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index a84918ac555e0bcebc94203e3c1734609cc0740d..e309ea954febb4b20c99265896fda52e9001c1b7 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -19,10 +19,10 @@ 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
 
 Questo significa che si può accedere a qualunque periferica del computer,
 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i

-cosiddetti file di dispositivo (i \textit{device file}). Questi sono dei file
-speciali agendo sui quali i programmi possono leggere, scrivere e compiere
-operazioni direttamente sulle periferiche, usando le stesse funzioni che si
-usano per i normali file di dati.
+cosiddetti file di dispositivo\index{file!di dispositivo} (i \textit{device
+  file}). Questi sono dei file speciali agendo sui quali i programmi possono
+leggere, scrivere e compiere operazioni direttamente sulle periferiche, usando
+le stesse funzioni che si usano per i normali file di dati.

 
 In questo capitolo forniremo una descrizione dell'architettura dei file in
 Linux, iniziando da una panoramica sulle caratteristiche principali delle
 
 In questo capitolo forniremo una descrizione dell'architettura dei file in
 Linux, iniziando da una panoramica sulle caratteristiche principali delle


@@ -57,16 +57,16 @@ 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.  Un file
 viene identificato dall'utente usando quello che viene chiamato
 file vengono tenuti all'interno di un unico albero la cui radice (quella che
 viene chiamata \textit{root directory}) viene montata all'avvio.  Un file
 viene identificato dall'utente usando quello che viene chiamato

-\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
-  nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
-  un insieme di directory su cui effettuare una ricerca (come quello in cui si
-  cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
-  di componente per il nome del file all'interno della directory. Non
-  seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
-  ormai così comune che mantenerne l'uso è senz'altro più chiaro
-  dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
-al file a partire dalla \textit{root directory}, che è composto da una serie
-di nomi separati da una \file{/}.
+\textit{pathname}\index{pathname}\footnote{il manuale della \acr{glibc}
+  depreca questa nomenclatura, che genererebbe confusione poiché \textit{path}
+  indica anche un insieme di directory su cui effettuare una ricerca (come
+  quello in cui si cercano i comandi). Al suo posto viene proposto l'uso di
+  \textit{filename} e di componente per il nome del file all'interno della
+  directory. Non seguiremo questa scelta dato che l'uso della parola
+  \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più
+  chiaro dell'alternativa proposta.}, cioè il percorso che si deve fare per
+accedere al file a partire dalla \textit{root directory}, che è composto da
+una serie di nomi separati da una \file{/}.

 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 riceve dal boot loader l'indicazione di quale dispositivo contiene il
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 riceve dal boot loader l'indicazione di quale dispositivo contiene il


@@ -94,7 +94,8 @@ specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
     components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
 contenuto.  All'interno dello stesso albero si potranno poi inserire anche
 tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
     components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
 contenuto.  All'interno dello stesso albero si potranno poi inserire anche
 tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file

-come le fifo, i link, i socket e gli stessi file di dispositivo (questi
+come le fifo, i link, i socket\index{socket} e gli stessi file di dispositivo
+\index{file!di dispositivo} (questi

 ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il


@@ -109,14 +110,14 @@ esistano e siano effettivamente directory, inoltre i permessi (si veda
 \secref{sec:file_access_control}) devono consentire l'accesso all'intero
 \textit{pathname}.
 
 \secref{sec:file_access_control}) devono consentire l'accesso all'intero
 \textit{pathname}.
 

-Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
-radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
-\secref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
-directory radice dell'albero dei file: in questo caso si parla di un
-\textsl{pathname assoluto}\index{pathname assoluto}. Altrimenti la ricerca
-parte dalla directory corrente (su cui torneremo in
+Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte
+dalla directory radice del processo; questa, a meno di un \func{chroot} (su
+cui torneremo in \secref{sec:file_chroot}) è la stessa per tutti i processi ed
+equivale alla directory radice dell'albero dei file: in questo caso si parla
+di un \textsl{pathname assoluto}\index{pathname!assoluto}. Altrimenti la
+ricerca parte dalla directory corrente (su cui torneremo in

 \secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
 \secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname

-  relativo}\index{pathname relativo}.
+  relativo}\index{pathname!relativo}.

 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il
 
 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 in ogni directory: il primo fa riferimento alla directory corrente e il


@@ -141,18 +142,19 @@ la classificazione dei file (che in questo caso sono sempre file di dati) in
 base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
 oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
 Alcuni di essi, come le \textit{fifo} (che tratteremo in
 base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
 oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
 Alcuni di essi, come le \textit{fifo} (che tratteremo in

-\secref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in
-\capref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare
-delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i
-\textsl{file di dispositivo} (o \textit{device file}) che costituiscono una
-interfaccia diretta per leggere e scrivere sui dispositivi fisici; essi
-vengono suddivisi in due grandi categorie, \textsl{a blocchi} e \textsl{a
-  caratteri} a seconda delle modalità in cui il dispositivo sottostante
-effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
-  (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto
-  che l'I/O venga effettuato per blocchi di dati di dimensioni fissate (ad
-  esempio le dimensioni di un settore), mentre nei dispositivi a caratteri
-  l'I/O viene effettuato senza nessuna particolare struttura.}
+\secref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che
+tratteremo in \capref{cha:socket_intro}) non sono altro che dei riferimenti
+per utilizzare delle funzionalità di comunicazione fornite dal kernel. Gli
+altri sono i \textsl{file di dispositivo}\index{file!di dispositivo} (o
+\textit{device file}) che costituiscono una interfaccia diretta per leggere e
+scrivere sui dispositivi fisici; essi vengono suddivisi in due grandi
+categorie, \textsl{a blocchi} e \textsl{a caratteri} a seconda delle modalità
+in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in
+  sostanza i dispositivi a blocchi (ad esempio i dischi) corrispondono a
+  periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi
+  di dati di dimensioni fissate (ad esempio le dimensioni di un settore),
+  mentre nei dispositivi a caratteri l'I/O viene effettuato senza nessuna
+  particolare struttura.}

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


@@ -165,8 +167,8 @@ effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
       \textit{regular file} & \textsl{file regolare} &
       un file che contiene dei dati (l'accezione normale di file) \\
       \textit{directory} & \textsl{cartella o direttorio} &
       \textit{regular file} & \textsl{file regolare} &
       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 \textit{inodes}
-      (vedi \secref{sec:file_vfs}).  \\
+      un file che contiene una lista di nomi associati a degli
+      \textit{inode}\index{inode} (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} &
       \textit{symbolic link} & \textsl{collegamento simbolico} &
       un file che contiene un riferimento ad un altro file/directory \\
       \textit{char device} & \textsl{dispositivo a caratteri} &


@@ -175,10 +177,10 @@ effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi
       un file che identifica una periferica ad accesso a blocchi \\
       \textit{fifo} & \textsl{``coda''} &
       un file speciale che identifica una linea di comunicazione software
       un file che identifica una periferica ad accesso a blocchi \\
       \textit{fifo} & \textsl{``coda''} &
       un file speciale che identifica una linea di comunicazione software

-      (unidirezionale) \\
-      \textit{socket} & \textsl{``presa''} &
+      unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
+      \textit{socket}\index{socket} & \textsl{``presa''} &

       un file speciale che identifica una linea di comunicazione software
       un file speciale che identifica una linea di comunicazione software

-      (bidirezionale) \\
+      bidirezionale (vedi \capref{cha:socket_intro}) \\

     \hline
     \end{tabular}
     \caption{Tipologia dei file definiti nel VFS}
     \hline
     \end{tabular}
     \caption{Tipologia dei file definiti nel VFS}


@@ -195,10 +197,10 @@ il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{questo vale
   dimensione fissa avviene solo all'interno del kernel, ed è completamente
   trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
     diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
   dimensione fissa avviene solo all'interno del kernel, ed è completamente
   trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
     diretto} riferendosi alla capacità, che non ha niente a che fare con tutto

-  ciò, di effettuare, attraverso degli appositi file di dispositivo,
-  operazioni di I/O direttamente sui dischi senza passare attraverso un
-  filesystem (il cosiddetto \textit{raw access}, introdotto coi kernel della
-  serie 2.4.x).}
+  ciò, di effettuare, attraverso degli appositi file di
+  dispositivo\index{file!di dispositivo}, operazioni di I/O direttamente sui
+  dischi senza passare attraverso un filesystem (il cosiddetto \textit{raw
+    access}, introdotto coi kernel della serie 2.4.x).}

 
 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 
 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è


@@ -243,29 +245,31 @@ L'interfaccia 
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 direttamente le system call del kernel (in realtà il kernel effettua al suo
 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 direttamente le system call del kernel (in realtà il kernel effettua al suo
 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai

-dispositivi); i \textit{file descriptor}\index{file descriptor} sono
+dispositivi); i \textit{file descriptor}\index{file!descriptor} sono

 rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
 L'interfaccia è definita nell'header \file{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli

-\textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso
-bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
-tratteremo in dettaglio nel \capref{cha:files_std_interface}.
+\textit{stream}\index{file!stream}. Essa fornisce funzioni più evolute e un
+accesso bufferizzato (controllato dalla implementazione fatta dalle
+\acr{glibc}), la tratteremo in dettaglio nel \capref{cha:files_std_interface}.

 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 
 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova

-anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
-e sono rappresentati da puntatori ad un opportuna struttura definita dalle
-librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il
-tipo \ctyp{FILE *}.  L'interfaccia è definita nell'header \file{stdio.h}.
+anche su tutti i sistemi non Unix. Gli \textit{stream}\index{file!stream} sono
+oggetti complessi e sono rappresentati da puntatori ad un opportuna struttura
+definita dalle librerie del C; si accede ad essi sempre in maniera indiretta
+utilizzando il tipo \ctyp{FILE *}.  L'interfaccia è definita nell'header
+\file{stdio.h}.

 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 
 Entrambe le interfacce possono essere usate per l'accesso ai file come agli

-altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio
-a tempo opportuno), ma per poter accedere alle operazioni di controllo
-(descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque
-tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i
-\textit{file descriptor}. Allo stesso modo devono essere usati i \textit{file
-  descriptor} se si vuole ricorrere a modalità speciali di I/O come il polling
-o il non-bloccante (vedi \capref{cha:file_advanced}).
+altri oggetti del VFS (fifo, socket\index{socket}, device, sui quali torneremo
+in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di
+controllo (descritte in \secref{sec:file_fcntl} e \secref{sec:file_ioctl}) su
+un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di
+Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i
+\textit{file descriptor}\index{file!descriptor} se si vuole ricorrere a
+modalità speciali di I/O come il \textit{file locking}\index{file!locking} o
+l'I/O non-bloccante (vedi \capref{cha:file_advanced}).

 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 quella dei \textit{file descriptor}, che permette di poter scegliere tra
 
 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 quella dei \textit{file descriptor}, che permette di poter scegliere tra


@@ -273,20 +277,22 @@ diversi stili di bufferizzazione.  Il maggior vantaggio degli \textit{stream}
 è che l'interfaccia per le operazioni di input/output è enormemente più ricca
 di quella dei \textit{file descriptor}, che forniscono solo funzioni
 elementari per la lettura/scrittura diretta di blocchi di byte.  In
 è che l'interfaccia per le operazioni di input/output è enormemente più ricca
 di quella dei \textit{file descriptor}, che forniscono solo funzioni
 elementari per la lettura/scrittura diretta di blocchi di byte.  In

-particolare gli \textit{stream} dispongono di tutte le funzioni di
-formattazione per l'input e l'output adatte per manipolare anche i dati in
-forma di linee o singoli caratteri.
+particolare gli \textit{stream}\index{file!stream} dispongono di tutte le
+funzioni di formattazione per l'input e l'output adatte per manipolare anche i
+dati in forma di linee o singoli caratteri.

 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
 uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
 
 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
 uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo

-tempo uno \textit{stream} ad un \textit{file descriptor}.
+tempo uno \textit{stream}\index{file!stream} ad un \textit{file
+  descriptor}\index{file!descriptor}.

 
 In generale, se non necessitano specificatamente le funzionalità di basso
 
 In generale, se non necessitano specificatamente le funzionalità di basso

-livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
-portabilità, essendo questi ultimi definiti nello standard ANSI C;
-l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
-POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
+livello, è opportuno usare sempre gli \textit{stream}\index{file!stream} per
+la loro maggiore portabilità, essendo questi ultimi definiti nello standard
+ANSI C; l'interfaccia con i \textit{file descriptor}\index{file!descriptor}
+infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed è pertanto di
+portabilità più limitata.

 
 
 % \subsection{Caratteristiche specifiche dei file in Unix}
 
 
 % \subsection{Caratteristiche specifiche dei file in Unix}


@@ -396,8 +402,8 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in
 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: \textit{filesystem},
 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: \textit{filesystem},

-\textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
-definite nel kernel.
+\textit{inode}\index{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
 
 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


@@ -426,10 +432,10 @@ Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
 filesystem usate per l'accesso dal VFS; in particolare il descrittore
 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
 filesystem usate per l'accesso dal VFS; in particolare il descrittore

-dell'inode contiene i puntatori alle funzioni che possono essere usate su
-qualunque file (come \func{link}, \func{stat} e \func{open}), mentre il
-descrittore di file contiene i puntatori alle funzioni che vengono usate sui
-file già aperti.
+dell'inode\index{inode} contiene i puntatori alle funzioni che possono essere
+usate su qualunque file (come \func{link}, \func{stat} e \func{open}), mentre
+il descrittore di file contiene i puntatori alle funzioni che vengono usate
+sui file già aperti.

 
 
 \subsection{Il funzionamento del VFS}
 
 
 \subsection{Il funzionamento del VFS}


@@ -443,37 +449,39 @@ tabella che contiene tutte le \textit{directory entry} (in breve
 pathname a una specifica \textit{dentry}.
 
 Una singola \textit{dentry} contiene in genere il puntatore ad un
 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
-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.
+\textit{inode}\index{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\index{file!di dispositivo}, o una 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 \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}.
+vengono usate per motivi di velocità, gli \textit{inode}\index{inode} invece
+stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
+viene copiato all'indietro sul disco, gli inode\index{inode} che stanno in
+memoria sono inode\index{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
 
 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.
+pathname il VFS deve creare una nuova \textit{dentry} e caricare
+l'inode\index{inode} corrispondente in memoria.

 
 

-Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode
-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.
+Questo procedimento viene eseguito dal metodo \code{lookup()}
+dell'inode\index{inode} 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.

 
 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
 
 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.
+dell'inode\index{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


@@ -551,7 +559,7 @@ superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
 \secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
 filesystem per Unix, indipendentemente da come poi viene strutturata nei
 dettagli questa informazione, prevedere una divisione fra la lista degli
 \secref{sec:file_ext2}). È comunque caratteristica 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.
+inode\index{inode} e lo spazio a disposizione per i dati e le directory.

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


@@ -583,15 +591,15 @@ particolare 
 
 \begin{enumerate}
   
 
 \begin{enumerate}
   

-\item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
-  tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
-  fisici che contengono i dati e così via; le informazioni che la funzione
-  \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
-  troverà solo il nome del file e il numero dell'\textit{inode} ad esso
-  associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
-  traduzione 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 L'\textit{inode}\index{inode} contiene tutte le informazioni riguardanti
+  il file: il tipo di file, i permessi di accesso, le dimensioni, i puntatori
+  ai blocchi fisici che contengono i dati e così via; le informazioni che la
+  funzione \func{stat} fornisce provengono dall'\textit{inode}; dentro una
+  directory si troverà solo il nome del file e il numero
+  dell'\textit{inode}\index{inode} ad esso associato, cioè quella che da qui
+  in poi chiameremo una \textsl{voce} (come traduzione 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 \figref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
   
 \item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un


@@ -600,19 +608,20 @@ particolare 
   file vengono effettivamente rimossi dal disco. Per questo la funzione per
   cancellare un file si chiama \func{unlink}, ed in realtà non cancella
   affatto i dati del file, ma si limita ad eliminare la relativa voce da una
   file vengono effettivamente rimossi dal disco. Per questo la funzione per
   cancellare un file si chiama \func{unlink}, ed in realtà non cancella
   affatto i dati del file, ma si limita ad eliminare la relativa voce da una

-  directory e decrementare il numero di riferimenti nell'\textit{inode}.
-
+  directory e decrementare il numero di riferimenti
+  nell'\textit{inode}\index{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
 \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.
+  riferimenti ad \textit{inode}\index{inode} 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 viene spostato fisicamente, viene semplicemente creata una
   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una

-  nuova voce per l'\textit{inode} in questione e rimossa la vecchia (questa è
-  la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
-  funzione \func{rename}).
+  nuova voce per l'\textit{inode}\index{inode} in questione e rimossa la
+  vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
+  attraverso la funzione \func{rename}).

 
 \end{enumerate}
 
 
 \end{enumerate}
 


@@ -621,7 +630,7 @@ riferimenti anche per le directory; per cui, se a partire dalla situazione
 mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
 \file{img} nella directory \file{gapil}, avremo una situazione come quella in
 \figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di
 mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory
 \file{img} nella directory \file{gapil}, avremo una situazione come quella in
 \figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di

-inode.
+inode\index{inode}.

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


@@ -667,9 +676,9 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
 \item il filesystem implementa link simbolici veloci, in cui il nome del file
   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
   permettono un accesso più veloce, ma sprecano più spazio disco).
 \item il filesystem implementa link simbolici veloci, in cui il nome del file

-  non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando
-  letture multiple e spreco di spazio), non tutti i nomi però possono essere
-  gestiti così per limiti di spazio (il limite è 60 caratteri). 
+  non è salvato su un blocco, ma tenuto all'interno dell'inode\index{inode}
+  (evitando letture multiple e spreco di spazio), non tutti i nomi però
+  possono essere gestiti così per limiti di spazio (il limite è 60 caratteri).

 \item vengono supportati i file immutabili (che possono solo essere letti) per
   la protezione di file di configurazione sensibili, o file
   \textit{append-only} che possono essere aperti in scrittura solo per
 \item vengono supportati i file immutabili (che possono solo essere letti) per
   la protezione di file di configurazione sensibili, o file
   \textit{append-only} che possono essere aperti in scrittura solo per


@@ -696,11 +705,11 @@ superblock principale.
 
 L'utilizzo di raggruppamenti 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 raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli

-inode. 
+inode\index{inode}. 

 
 Le directory sono implementate come una linked list con voci di dimensione
 
 Le directory sono implementate come una linked list con voci di dimensione

-variabile. Ciascuna voce della lista contiene il numero di inode, la sua
-lunghezza, il nome del file e la sua lunghezza, secondo lo schema in
+variabile. Ciascuna voce della lista contiene il numero di inode\index{inode},
+la sua lunghezza, il nome del file e la sua lunghezza, secondo lo schema in

 \figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
 i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.
 
 \figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per
 i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.