Correzioni varie
authorSimone Piccardi <piccardi@gnulinux.it>
Mon, 9 Jan 2012 19:31:32 +0000 (19:31 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Mon, 9 Jan 2012 19:31:32 +0000 (19:31 +0000)
filedir.tex
img/dir_links.dia
img/filesys_struct.dia
listati/file_system_type.h

index 514705b61e32b47f3b97ad09cbdb42b964d65c2e..1964e7d38808d439f4e865805832723b51071365 100644 (file)
@@ -61,8 +61,8 @@ astrazione che prevede quattro tipi di oggetti strettamente correlati: i
 filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
 corrispondono una serie di apposite strutture definite dal kernel che
 contengono come campi le funzioni di gestione e realizzano l'infrastruttura
-del VFS. L'interfaccia è estremamente complessa, ne faremo pertanto una
-trattazione estremamente semplificata che consenta di comprenderne i principi
+del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione
+estremamente semplificata che consenta di comprenderne i principi
 difunzionamento.
 
 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
@@ -88,14 +88,14 @@ verrà inserita nella tabella, ed il nuovo filesystem comparirà in
 La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
 come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
   viene riportato in \procfile{/proc/filesystems} e che viene usato come
-  parametro dell'opzione \texttt{-t} del comando \texttt{mount}.}  contiene i
-riferimenti alle funzioni di base che consentono l'utilizzo di quel
-filesystem. In particolare la funzione \code{mount} del quarto campo è quella
-che verrà invocata tutte le volte che si dovrà effettuare il montaggio di un
-filesystem di quel tipo. Per ogni nuovo filesystem si dovrà allocare una di
-queste strutture ed inizializzare i relativi campi con i dati specifici diquel
-filesystem, ed in particolare si dovra creare anche la relativa versione della
-funzione \code{mount}.
+  valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che
+  indica il tipo di filesystem.}  contiene i riferimenti alle funzioni di base
+che consentono l'utilizzo di quel filesystem. In particolare la funzione
+\code{mount} del quarto campo è quella che verrà invocata tutte le volte che
+si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo
+filesystem si dovrà allocare una di queste strutture ed inizializzare i
+relativi campi con i dati specifici di quel filesystem, ed in particolare si
+dovrà creare anche la relativa versione della funzione \code{mount}.
 
 Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
 restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
@@ -104,9 +104,10 @@ la \textit{pathname resolution}, ciascuna di esse corrisponde ad un
 \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
 vedremo a breve è l'oggetto usato dal kernel per identificare un un
 file.\footnote{in questo caso si parla di file come di un qualunque oggetto
-  generico che sta sul filesystem.} La \textit{dentry} ottenuta dalla chiamata
-alla funzione \code{mount} sarà inserita in corrispondenza al
-\textit{pathname} della directory in cui il filesystem è stato montato.
+  generico che sta sul filesystem e non dell'oggetto file del VFS cui
+  accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
+\code{mount} sarà inserita in corrispondenza al \textit{pathname} della
+directory in cui il filesystem è stato montato.
 
 % NOTA: struct dentry è dichiarata in include/linux/dcache.h
 
@@ -116,7 +117,7 @@ nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
 \textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
 ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
   funzionamento della \textit{dcache} è in effetti di una delle parti più
-  critiche per le prestazioni del sistema.} che a sua ci darà, tramite
+  critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite
 l'\textit{inode}, il riferimento al file.
 
 Dato che normalmente non è possibile mantenere nella \textit{dcache} le
@@ -190,10 +191,10 @@ una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può
 trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
 
 Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
-è un puntatore ad una funzione, e, come suggerisce il nome della struttura
-stessa, queste funzioni, le principali delle quali sono riportate in
-tab.~\ref{tab:file_inode_operations}) sono quelle che definiscono le
-operazioni che il VFS può compiere su un \textit{inode}.
+è un puntatore ad una funzione e, come suggerisce il nome della struttura
+stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS
+può compiere su un \textit{inode}. Si sono riportate in
+tab.~\ref{tab:file_inode_operations} le più rilevanti.
 
 \begin{table}[htb]
   \centering
@@ -229,18 +230,19 @@ operazioni che il VFS può compiere su un \textit{inode}.
 
 Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
 identici alle varie \textit{system call} con le quali si gestiscono file e
-directory che tratteremo nel resto del capitolo. Quello che succede è che
+directory, che tratteremo nel resto del capitolo. Quello che succede è che
 tutte le volte che deve essere eseguita una \textit{system call}, o una
 qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
 andrà ad utilizzare la funzione corrispondente attraverso il puntatore
 \var{i\_op}.
 
 Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
-opportuna istanza di \kstruct{inode\_operation} contenente i puntatori alla
-implementazione di queste funzioni per quel filesystem e quel punto le
-strutture \kstruct{inode} usate per gli oggetti di quel filesystem otterranno
-il puntatore a detta istanza di \kstruct{inode\_operation} e verranno
-automaticamente usate le funzioni corrette.
+implementazione di queste funzioni per quel filesystem e si allochi una
+opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette
+funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di
+quel filesystem otterranno il puntatore alla relativa istanza di
+\kstruct{inode\_operation} e verranno automaticamente usate le funzioni
+corrette.
 
 Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
 funzione \texttt{open} che invece è citata in
@@ -248,8 +250,9 @@ tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
   invocata dato che nella struttura \kstruct{inode} è presente anche il
   puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
   fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione: l'allocazione di una struttura di
-tipo \kstruct{file} che viene associata ad ogni file aperto nel sistema.
+file richiede comunque un'altra operazione che mette in gioco l'omonimo
+oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
+viene associata ad ogni file aperto nel sistema.
 
 I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
 come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
@@ -327,7 +330,7 @@ stesso modo sulla porta seriale come su un normale file di dati, e lavorare
 sui file allo stesso modo indipendentemente dal filesystem.
 
 Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
-alle funzioni presenti nelle due strutture \kstruct{inode\_operation}
+alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
 \kstruct{file\_operation}.  Ovviamente non è detto che tutte le operazioni
 possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
 non è realizzabile per un dispositivo come la porta seriale o per una fifo,
@@ -352,34 +355,39 @@ 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 qualunque filesystem di un sistema unix-like.
 
-Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. Una possibile strutturazione
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys},
-in essa per semplicità si è fatto riferimento alla struttura del filesystem
-\acr{ext2}, che prevede una separazione dei dati in \textit{block group} che
-replicano il cosiddetto \textit{superblock} (sulle caratteristiche di
-\acr{ext2} e derivati torneremo in sez.~\ref{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 \itindex{inode} \textit{inode} e lo spazio a
-disposizione per i dati e le directory.\footnote{questo non è del tutto vero
-  per filesystem evoluti come \textsl{btrfs}, ma per il momento limitiamoci
-  alla implementazione classica.}
+Una possibile strutturazione dell'informazione su un disco è riportata in
+fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
+partizioni. In essa per semplicità si è fatto riferimento alla struttura del
+filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
+  group}.  All'interno di ciascun \textit{block group} viene anzitutto
+replicato il cosiddetto \textit{superblock}, (la struttura che contiene
+l'indice iniziale del filesystem e che consente di accedere a tutti i dati
+sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
+per accedere agli stessi.  Sulle caratteristiche di \acr{ext2} e derivati
+torneremo in sez.~\ref{sec:file_ext2}.
+
+È comunque caratteristica comune di tutti i filesystem per Unix,
+indipendentemente da come poi viene strutturata nei dettagli questa
+informazione, prevedere la presenza di due tipi di risorse: gli
+\itindex{inode} \textit{inode}, cui abbiamo già accennato in
+sez.~\ref{sec:file_vfs_work}, che sono le strutture che identificano i singoli
+oggetti sul filesystem, e i blocchi, che invece attengono allo spazio disco
+che viene messo a disposizione per i dati in essi contenuti.
 
 \begin{figure}[!htb]
   \centering
-  \includegraphics[width=14cm]{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}
 
 Se si va ad esaminare con maggiore dettaglio la strutturazione
-dell'informazione all'interno del singolo filesystem, tralasciando i dettagli
-relativi al funzionamento del filesystem stesso come la strutturazione in
-gruppi dei blocchi, il superblock e tutti i dati di gestione possiamo
-esemplificare la situazione con uno schema come quello esposto in
-fig.~\ref{fig:file_filesys_detail}.
+dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
+dettagli relativi al funzionamento del filesystem stesso come la
+strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
+gestione possiamo esemplificare la situazione con uno schema come quello
+esposto in fig.~\ref{fig:file_filesys_detail}.
 
 \begin{figure}[!htb]
   \centering
@@ -389,24 +397,26 @@ fig.~\ref{fig:file_filesys_detail}.
 \end{figure}
 
 Da fig.~\ref{fig:file_filesys_detail} 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:
+caratteristiche di base di un filesystem, che restano le stesse anche su
+filesystem la cui organizzazione dei dati è totalmente diversa da quella
+illustrata, e 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 prosieguo del capitolo. In particolare è
+opportuno tenere sempre presente che:
 
 \begin{enumerate}
   
-\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i
-  cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
+\item L'\textit{inode} \itindex{inode} contiene tutte le informazionii
+  cosiddetti \textsl{metadati}, 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}
   (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}.
   Dentro una directory si troverà solo il nome del file e il numero
   \itindex{inode} 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
-  sez.~\ref{sec:file_vfs_work}).
+  qui in poi chiameremo una \textsl{voce}, che abbiamo scelto 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
+  sez.~\ref{sec:file_vfs_work}.
   
 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
@@ -418,11 +428,13 @@ particolare è opportuno ricordare sempre che:
   file, ma si limita ad eliminare la relativa voce da una directory e
   decrementare il numero di riferimenti \itindex{inode} 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 \itindex{inode} \textit{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 All'interno di ogni filesystem ogni \textit{inode} è identificato da un
+  numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un
+  \textit{inode} a questo numero e non ci può essere una directory che
+  contiene riferimenti ad \itindex{inode} \textit{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
index 82ac44f90415efc35b77a068814b69248e74b688..7b0faf1c962344975a4c4c1faa3b56f61964de62 100644 (file)
Binary files a/img/dir_links.dia and b/img/dir_links.dia differ
index f9562562f36fac45e83aa6a4cc7cffa570ee8c25..c08ed10d3f49d733d2b3915a880e2f3dda20eaec 100644 (file)
Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ
index 4f4ceb90987b976ffd0bfafcfe9e4e05b67558f7..dabe30973751190f39f5f932a30c420cca7691a2 100644 (file)
@@ -9,7 +9,5 @@ struct file_system_type {
         struct module *owner;
         struct file_system_type * next;
         struct list_head fs_supers;
-
-        struct lock_class_key s_lock_key;
         ...
 };