X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=d4d478522fa388caa6566451a5f9a1eddd9aebe2;hp=2bcfe8127c66295338d8e7e8b85238b1d604c105;hb=09473ed326013ece27d53cd5ff9f96064cbce9f3;hpb=e239c3df54406ccbc9415d1d767ca6be41de14f3

diff --git a/fileintro.tex b/fileintro.tex
index 2bcfe81..d4d4785 100644
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -1,4 +1,3 @@
-
 \chapter{I files: l'architettura}
 \label{cha:files_intro}
 
@@ -21,7 +20,7 @@ contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
 varie caratteristiche distintive.
 
 \section{L'organizzazione di files e directories}
-\label{sec:fileintr_organization}
+\label{sec:file_organization}
 
 Il primo passo nella trattazione dell'achitettura della gestione dei file in
 un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
@@ -29,14 +28,14 @@ di quale 
 
 
 \subsection{La struttura di files e directory}
-\label{sec:fileintr_filedir_struct}
+\label{sec:file_file_struct}
 
 Partiamo allora da come viene strutturata nel sistema la disposizione dei
 file: per potervi accedere il kernel usa una apposita interfaccia che permetta
 di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
 dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
   brevità questo nome al posto della più prolissa traduzione italiana sistema
-  di file}, che descriviremo in dettaglio in \secref{sec:fileintr_vfs}.
+  di file}, che descriviremo in dettaglio in \secref{sec:file_vfs}.
 
 Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
 memorizzati all'interno del disco stesso, strutturando l'informazione in files
@@ -71,7 +70,7 @@ convenzione, sono inseriti nella directory \texttt{/dev}).
 
 L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
 medesimi nell'albero descritto in precedenza; una directory comunque, come già
-specificato in \secref{sec:fileintr_vfs}, è solo un particolare tipo di file
+specificato in \secref{sec:file_vfs}, è solo un particolare tipo di file
 che contiene le informazioni che associano un nome al contenuto.
 
 % Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
@@ -108,9 +107,9 @@ Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
 del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
 seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
 equivale alla directory radice dell'albero (come descritto in
-\secref{sec:fileintr_organization}): in questo caso si parla di un pathname
+\secref{sec:file_organization}): in questo caso si parla di un pathname
 \textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
-cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
+cui torneremo più avanti in \secref{sec:file_work_dir}) ed il pathname è
 detto \textsl{relativo}.
 
 I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
@@ -121,11 +120,11 @@ questa sia la directory radice allora il riferimento 
 
 
 \subsection{I tipi di files}
-\label{sec:fileintr_file_types}
+\label{sec:file_file_types}
 
 Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
 sono implementati come oggetti del \textit{Virtual File System} (vedi
-\secref{sec:fileintr_vfs}) e sono presenti in tutti i filesystem unix-like
+\secref{sec:file_vfs}) e sono presenti in tutti i filesystem unix-like
 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual
 File System è riportato in \ntab.
 
@@ -157,7 +156,7 @@ dati) in base al loro contenuto, o tipo di accesso.
     \hline
     \end{tabular}
     \caption{Tipologia dei file definiti nel VFS}
-    \label{tab:fileintr_file_types}
+    \label{tab:file_file_types}
   \end{center}
 \end{table}
 
@@ -180,7 +179,7 @@ riga.
 
 
 \subsection{Le due interfacce ai file}
-\label{sec:fileintr_io_api}
+\label{sec:file_io_api}
 
 In unix le modalità di accesso ai file e le relative interfacce di
 programmazione sono due, basate su due diversi meccanismi con cui è possibile
@@ -188,7 +187,8 @@ accedere al loro contenuto.
 
 La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
 chiama interfaccia dei descrittori di file (o \textit{file descriptor}).  È
-un'interfaccia specifica di unix e provvede un accesso non bufferizzato.
+un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la
+tratteremo in dettaglio in \capref{cha:file_unix_interface}.
 
 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
@@ -200,9 +200,11 @@ nell'header \texttt{unistd.h}.
 
 La seconda interfaccia è quella che il manuale della glibc chiama degli
 \textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
-(controllato dalla implementazione fatta dalle librerie del C).  Questa è
-l'interfaccia standard specificata dall'ANSI C e perciò si trova anche su
-tutti i sistemi non Unix. Gli stream sono oggetti complessi e sono
+(controllato dalla implementazione fatta dalle librerie del C), la tratteremo
+in dettaglio in \capref{cha:files_std_interface}.
+
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+anche su tutti i sistemi non unix. Gli 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
 \texttt{FILE *}.  L'interfaccia è definita nell'header \texttt{stdio.h}.
@@ -241,10 +243,10 @@ pertanto di portabilit
 \label{sec:fileint_unix_spec}
 
 Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-specifiche di Unix 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.
+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
@@ -275,7 +277,7 @@ accesso 
 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 \secref{sec:fileintr_link}) aprire un file provvisorio per
+in dettaglio in \secref{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.
@@ -283,23 +285,22 @@ saranno disponibili per tutto il tempo in cui il processo 
 Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
 esaminando in dettaglio come tutto ciò viene realizzato.
 
-Si ricordi infine che in unix non esistono i tipi di file e che non c'è nessun
-supporto 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 .c, ma questa è, appunto, solo
-una convenzione.
-
+Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
+c'è nessun supporto 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 .c, ma
+questa è, appunto, solo una convenzione.
 
 
 \section{L'architettura della gestione dei file}
-\label{sec:fileintr_architecture}
+\label{sec:file_architecture}
 
 Per capire fino in fondo le proprietà di files e directories in un sistema
-unix ed il funzionamento delle relative funzioni di manipolazione occorre una
-breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato
-un filesystem 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}.
+unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
+una breve introduzione sulla gestione dei medesimo 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}.
 
 In questa sezione esamineremo come viene implementato l'accesso ai files in
 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
@@ -310,10 +311,10 @@ l'\texttt{ext2}, come esempio di un filesystem unix-like.
 % 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:fileintr_vfs}.
+% nel kernel) in \secref{sec:file_vfs}.
 
 \subsection{Il \textit{virtual filesystem} di Linux}
-\label{sec:fileintr_vfs}
+\label{sec:file_vfs}
 
 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
 % files.  L'argomento è abbastanza ``esoterico'' e questa sezione può essere
@@ -341,7 +342,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
   \centering
   \includegraphics[width=7cm]{img/vfs.eps}
   \caption{Schema delle operazioni del VFS}
-  \label{fig:fileintr_VFS_scheme}
+  \label{fig:file_VFS_scheme}
 \end{figure}
 
 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
@@ -361,7 +362,7 @@ 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
-il superblock (vedi \ref{sec:fileintr_ext2}), inizializzare tutte le
+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 possible accedere alle routine
 specifiche per l'uso di quel filesystem.
@@ -384,7 +385,7 @@ file gi
 
 
 \subsection{Il funzionamento del VFS}
-\label{sec:fileintr_vfs_work}
+\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
@@ -430,7 +431,7 @@ 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:fileunix_fd}). Un elenco delle operazioni
+torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle operazioni
 previste dal kernel è riportato in \ntab.
 
 \begin{table}[htb]
@@ -458,7 +459,7 @@ previste dal kernel 
     \hline
   \end{tabular}
   \caption{Operazioni sui file definite nel VFS.}
-  \label{tab:fileintr_file_operations}
+  \label{tab:file_file_operations}
 \end{table}
 
 In questo modo per ciascun file diventano utilizzabili una serie di operazioni
@@ -475,9 +476,9 @@ diversi filesystem (come quelli usati da Windows o MacOs) 
 
 
 \subsection{Il funzionamento di un filesystem unix}
-\label{sec:fileintr_filesystem}
+\label{sec:file_filesystem}
 
-Come già accennato in \secref{sec:fileintr_organization} Linux (ed ogni unix
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
 in generale) organizza i dati che tiene su disco attraverso l'uso di un
 filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
 quella di poter supportare grazie al VFS una enorme quantità di filesystem
@@ -491,7 +492,7 @@ partizione pu
 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:fileintr_ext2}). È comunque caratteristica
+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.
@@ -500,7 +501,7 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory.
   \centering
   \includegraphics[width=9cm]{img/disk_struct.eps}
   \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
-  \label{fig:fileintr_disk_filesys}
+  \label{fig:file_disk_filesys}
 \end{figure}
 
 Se si va ad esaminare con maggiore dettaglio la strutturazione
@@ -513,7 +514,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig.
   \centering
   \includegraphics[width=11cm]{img/filesys_struct.eps}
   \caption{Strutturazionne dei dati all'interno di un filesystem}
-  \label{fig:fileintr_filesys_detail}
+  \label{fig:file_filesys_detail}
 \end{figure}
 
 Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
@@ -531,7 +532,7 @@ torneremo in seguitp; in particolare 
   associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
   (traduzione approssimata dell'inglese \textit{directory entry}, che non
   useremo anche per evitare confusione con le \textit{dentries} del kernel di
-  cui si parlava in \secref{sec:fileintr_vfs}).
+  cui si parlava in \secref{sec:file_vfs}).
   
 \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
@@ -566,7 +567,7 @@ chiarezza abbiamo aggiunto dei numeri di inode.
   \centering 
   \includegraphics[width=11cm]{img/dir_links.eps}
   \caption{Organizzazione dei link per le directory}
-  \label{fig:fileintr_dirs_link}
+  \label{fig:file_dirs_link}
 \end{figure}
 
 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
@@ -577,19 +578,18 @@ che non contenga a sua volta altre directories. Al contempo la directory da
 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 
-\subsection{Il filesystem \texttt{ext2}}
-\label{sec:fileintr_ext2}
+\subsection{Il filesystem \textsl{ext2}}
+\label{sec:file_ext2}
 
 Il filesystem standard usato da Linux è il cosidetto \textit{second extended
-  filesystem}, identificato dalla sigla \texttt{ext2}. Esso supporta tutte le
+  filesystem}, identificato dalla sigla \textsl{ext2}. Esso supporta tutte le
 caratteristiche di un filesystem standard unix, è in grado di gestire
 filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
 4~Tb. 
 
-Oltre alle caratteristiche standard ext2 fornisce alcune estensioni che non
-sono presenti sugli altri filesystem unix. Caratteristiche particolari di ext2
-sono le seguenti''
-
+Oltre alle caratteristiche standard \textsl{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
   kernel quando agisce su gruppi di file. Possono essere settati su file e
@@ -600,9 +600,9 @@ sono le 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
-  di setgid settata (per una descrizione dettagliata del sigificato di questi
-  termini si veda \secref{sec:filedir_access_control}), nel qual caso file e
-  sottodirectory ereditano sia il group id che il setgid.
+  di sgid settato (per una descrizione dettagliata del significato di questi
+  termini si veda \secref{sec:file_access_control}), nel qual caso file e
+  sottodirectory ereditano sia il group id che il 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).
@@ -617,10 +617,10 @@ sono le seguenti''
   log).
 \end{itemize}
 
-La struttura di 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:fileintr_filesys_detail}, in cui la partizione è
-divisa in gruppi di blocchi. 
+La struttura di \textsl{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.
 
 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
@@ -632,11 +632,11 @@ superblock principale.
   \centering
   \includegraphics[width=9cm]{img/dir_struct.eps}  
   \caption{Struttura delle directory nel \textit{second extented filesystem}.}
-  \label{fig:fileintr_ext2_dirs}
+  \label{fig:file_ext2_dirs}
 \end{figure}
 
 L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
-performance dato che viene ridotta la distanza fra i dati e la tabella degli
+prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 inodes. 
 
 Le directory sono implementate come una linked list con voci di dimensione