Altra serie di correzioni ortografiche, con inserimento delle parole

[gapil.git] / fileintro.tex

diff --git a/fileintro.tex b/fileintro.tex
index f2b6336751e9bcf4e53a04b09656f77f0fdf5e0a..80f41931120968e85cd8c9cfc9628b36aa03cd69 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -43,7 +43,6 @@ Questo viene fatto strutturando l'informazione sul disco attraverso quello che
 si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
 poi viene resa disponibile ai processi attraverso quello che viene chiamato il
 \textsl{montaggio} del \textit{filesystem}.
 si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa
 poi viene resa disponibile ai processi attraverso quello che viene chiamato il
 \textsl{montaggio} del \textit{filesystem}.

-% (approfondiremo tutto ciò in sez.~\ref{sec:file_arch_func}).

 
 In questa sezione faremo una panoramica generica su come il sistema presenta
 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
 
 In questa sezione faremo una panoramica generica su come il sistema presenta
 i file ai processi, trattando l'organizzazione di file e directory, i tipi di


@@ -53,7 +52,7 @@ file ed introducendo le interfacce disponibili e le loro caratteristiche.
 \subsection{L'organizzazione di file e directory}
 \label{sec:file_organization}
 
 \subsection{L'organizzazione di file e directory}
 \label{sec:file_organization}
 

-\index{\textit{pathname}|(} 
+\itindbeg{pathname}

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


@@ -87,38 +86,38 @@ particolare che il kernel riconosce come tale. Il suo scopo 
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
 contenere una lista di nomi di file e le informazioni che associano ciascun
 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente

-un'organizzazione ad albero inserendo directory in altre directory.
+un'organizzazione ad albero inserendo nomi di directory in altre directory.

 
 Un file può essere indicato rispetto alla directory corrente semplicemente
 specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
 
 Un file può essere indicato rispetto alla directory corrente semplicemente
 specificandone il nome\footnote{Il 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}.} 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\index{socket} e gli stessi file di dispositivo
-\index{file!di~dispositivo} (questi
-ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
+contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+components}), noi li chiameremo più semplicemente \textsl{nomi} o
+\textsl{voci}.}  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\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
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato

-risoluzione del nome (\textit{file name resolution} o \textit{pathname
-  resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
+risoluzione del nome (\textit{filename resolution} o \textit{pathname
+resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da

 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome

-precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
-  costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
+precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto,
+il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,

 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda
 sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
 \textit{pathname}.
 
 perché il procedimento funzioni, occorre che i nomi indicati come directory
 esistano e siano effettivamente directory, inoltre i permessi (si veda
 sez.~\ref{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
-sez.~\ref{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{\textit{pathname}!assoluto}. Altrimenti la
+Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla
+directory radice del processo; questa, a meno di un \func{chroot} (su cui
+torneremo in sez.~\ref{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} \itindsub{pathname}{assoluto}.  Altrimenti la

 ricerca parte dalla directory corrente (su cui torneremo in
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
 ricerca parte dalla directory corrente (su cui torneremo in
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname

-  relativo}\index{\textit{pathname}!relativo}.
+  relativo} \itindsub{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


@@ -126,6 +125,7 @@ secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cio
 la directory che contiene il riferimento alla directory corrente; nel caso la
 directory corrente coincida con la directory radice, allora il riferimento è a
 se stessa.
 la directory che contiene il riferimento alla directory corrente; nel caso la
 directory corrente coincida con la directory radice, allora il riferimento è a
 se stessa.

+\itindend{pathname}

 
 
 \subsection{I tipi di file}
 
 
 \subsection{I tipi di file}


@@ -135,7 +135,7 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 sez.~\ref{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
 sono implementati come oggetti del \textit{Virtual File System} (vedi
 sez.~\ref{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

-\textit{Virtual File System}\index{\textit{Virtual~File~System}} è riportato in
+\textit{Virtual File System}\itindex{Virtual~File~System} è riportato in

 tab.~\ref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 tab.~\ref{tab:file_file_types}.
 
 Si tenga ben presente che questa classificazione non ha nulla a che fare con


@@ -297,63 +297,10 @@ infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed 
 portabilità più limitata.
 
 
 portabilità più limitata.
 
 

-% \subsection{Caratteristiche specifiche dei file in Unix}
-% \label{sec:fileint_unix_spec}
-
-% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-% specifiche di un sistema unix-like che devono essere tenute in conto
-% nell'accesso ai file. È infatti normale che più processi o programmi possano
-% accedere contemporaneamente allo stesso file e devono poter eseguire le loro
-% operazioni indipendentemente da quello che fanno gli altri processi.
-
-% Per questo motivo le strutture usate per all'accesso ai file sono relative al
-% processo che effettua l'accesso.  All'apertura di ogni file infatti viene
-% creata all'interno del processo una apposita struttura in cui sono memorizzati
-% tutti gli attributi del medesimo, che viene utilizzata per tutte le
-% operazioni. Questa è una struttura che resta locale al processo stesso; in
-% questo modo processi diversi possono usare le proprie strutture locali per
-% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
-% indipendente.
-
-% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
-% sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
-% file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
-% successiva. Essa è rappresentata da un numero intero che indica il numero di
-% byte dall'inizio del file, che viene (a meno che non si apra il file in
-% append) inizializzato a zero all'apertura del medesimo.
-
-% Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
-% ogni processo avrà la sua posizione corrente nel file, che non sarà
-% influenzata da quello che altri processi possono fare. Anzi, aprire un file
-% significa appunto creare ed inizializzare una tale struttura, per cui se si
-% apre due volte lo stesso file all'interno dello stesso processo, si otterranno
-% due file descriptor o due stream che avranno ancora una posizione corrente nel
-% file assolutamente indipendente.
-
-% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
-% accesso è un riferimento all'inode del file, pertanto anche se il file viene
-% cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
-% dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
-% chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-% in dettaglio in sez.~\ref{sec:file_link}) aprire un file provvisorio per
-% cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
-% file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
-% saranno disponibili per tutto il tempo in cui il processo è attivo.
-
-% Ritorneremo su questo più avanti in sez.~\ref{sec:file_fd}, quando tratteremo
-% l'input/output sui file, esaminando in dettaglio come tutto ciò viene
-% realizzato.
-

 
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 
 
 \section{L'architettura della gestione dei file}
 \label{sec:file_arch_func}
 

-%% 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 della gestione dei file da
-%% parte del kernel 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 cap.~\ref{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


@@ -361,35 +308,25 @@ prima le caratteristiche generali di un filesystem di un sistema unix-like,
 per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 Linux, l'\acr{ext2}.
 
 per poi trattare in maniera un po' più dettagliata il filesystem più usato con
 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
-% sez.~\ref{sec:file_vfs}.
-

 
 \subsection{Il \textit{Virtual File System} di Linux}
 \label{sec:file_vfs}
 
 
 \subsection{Il \textit{Virtual File System} di Linux}
 \label{sec:file_vfs}
 

-% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
-% file.  L'argomento è abbastanza ``esoterico'' e questa sezione può essere
-% saltata ad una prima lettura; è bene però tenere presente che vengono
-% introdotti qui alcuni termini che potranno comparire in seguito, come
-% \textit{inode}, \textit{dentry}, \textit{dcache}.
-
+\itindbeg{Virtual~File~System}

 In Linux il concetto di \textit{everything is a file} è stato implementato
 In Linux il concetto di \textit{everything is a file} è stato implementato

-attraverso il \textit{Virtual File System}\index{\textit{Virtual~File~System}}
-(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 fornisce 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 i diversi
-filesystem le effettuano, permettendo la coesistenza di filesystem differenti
-all'interno dello stesso albero delle directory.
+attraverso il \textit{Virtual File System} (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 fornisce
+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 i 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
 manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
 
 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
 manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle

-opportune routine del filesystem specifico a cui si fa riferimento. Saranno
+opportune funzioni del filesystem specifico a cui si fa riferimento. Saranno

 queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 di I/O sul dispositivo fisico, secondo lo schema riportato in
 fig.~\ref{fig:file_VFS_scheme}.
 queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 di I/O sul dispositivo fisico, secondo lo schema riportato in
 fig.~\ref{fig:file_VFS_scheme}.


@@ -420,7 +357,7 @@ VFS pu
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 il superblock (vedi sez.~\ref{sec:file_ext2}), inizializzare tutte le variabili
 interne e restituire uno speciale descrittore dei filesystem montati al VFS;
 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 il superblock (vedi sez.~\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
+attraverso quest'ultimo diventa possibile accedere alle funzioni specifiche per

 l'uso di quel filesystem.
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 l'uso di quel filesystem.
 
 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad


@@ -428,7 +365,7 @@ 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 \textit{filesystem descriptor} per accedere
 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 \textit{filesystem descriptor} per accedere

-alle routine specifiche di quel filesystem.
+alle funzioni 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


@@ -443,9 +380,8 @@ sui file gi
 \subsection{Il funzionamento del \textit{Virtual File System}}
 \label{sec:file_vfs_work}
 
 \subsection{Il funzionamento del \textit{Virtual File System}}
 \label{sec:file_vfs_work}
 

-La funzione più importante implementata dal
-VFS\index{\textit{Virtual~File~System}} è la system call \func{open} che
-permette di aprire un file. Dato un \index{\textit{pathname}}\textit{pathname}
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un \itindex{pathname}\textit{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
 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


@@ -473,7 +409,7 @@ La \textit{dcache} costituisce perci
 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
 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

-\index{\textit{pathname}}\textit{pathname} il VFS deve creare una nuova
+\itindex{pathname}\textit{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()}
 \textit{dentry} e caricare l'inode\index{inode} corrispondente in memoria.
 
 Questo procedimento viene eseguito dal metodo \code{lookup()}


@@ -532,7 +468,7 @@ tab.~\ref{tab:file_file_operations}.
 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
 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 l'opportuna routine dichiarata in \struct{f\_ops} appropriata al
+utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al

 tipo di file in questione.
 
 Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
 tipo di file in questione.
 
 Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un


@@ -540,6 +476,7 @@ normale file di dati; 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.
 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.

+\itindend{Virtual~File~System}

 
 
 \subsection{Il funzionamento di un filesystem Unix}
 
 
 \subsection{Il funzionamento di un filesystem Unix}


@@ -550,7 +487,7 @@ 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, per il momento non entreremo nei dettagli di un
+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.
 
 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 


@@ -558,7 +495,7 @@ 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 fig.~\ref{fig:file_disk_filesys};
 in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
 partizione può contenere un filesystem. La strutturazione tipica
 dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys};
 in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che

-prevede una separazione dei dati in \textit{blocks group} che replicano il
+prevede una separazione dei dati in \textit{block group} che replicano il

 superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
 sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
 filesystem per Unix, indipendentemente da come poi viene strutturata nei
 superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
 sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
 filesystem per Unix, indipendentemente da come poi viene strutturata nei


@@ -693,7 +630,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 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 fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
 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 fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa

-in gruppi di blocchi.\footnote{non si confonda la questa definizione con
+in gruppi di blocchi.\footnote{non si confonda questa definizione con

   quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
   riferimento alla struttura usata in user space per riportare i dati
   contenuti in una directory generica, questa fa riferimento alla struttura
   quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
   riferimento alla struttura usata in user space per riportare i dati
   contenuti in una directory generica, questa fa riferimento alla struttura


@@ -717,12 +654,12 @@ 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\index{inode}. 
 
 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 inode\index{inode}. 
 

-Le directory sono implementate come una linked list con voci di dimensione
-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
-fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi
-per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio
-disco.
+Le directory sono implementate come una \itindex{linked~list}\textit{linked
+  list} con voci di dimensione 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 fig.~\ref{fig:file_ext2_dirs}; in questo modo
+è possibile implementare nomi per i file anche molto lunghi (fino a 1024
+caratteri) senza sprecare spazio disco.