-
\chapter{I files: l'architettura}
\label{cha:files_intro}
\begin{figure}[htb]
\centering
- \includegraphics[width=5cm]{img/vfs.eps}
+ \includegraphics[width=7cm]{img/vfs.eps}
\caption{Schema delle operazioni del VFS}
\label{fig:fileintr_VFS_scheme}
\end{figure}
\begin{table}[htb]
\centering
- \begin{tabular}[c]{|c|p{7cm}}
+ \begin{tabular}[c]{|c|p{7cm}|}
\hline
\textbf{funzione} & \textbf{operazione} \\
\hline
comuni di un qualunque filesystem standard unix.
Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; quest'ultimo è in genere strutturato
-secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
-disposizione per i dati e le directory.
+partizione può contenere un filesystem; la strutturazione tipica
+dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
+alla struttura del filesystem ext2, che prevede una separazione dei dati in
+\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di
+ext2 torneremo in \secref{sec:fileintr_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.
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=9cm]{img/disk_struct.eps}
\caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
\label{fig:fileintr_disk_filesys}
\end{figure}
-Se si va ad esaminare come è strutturata l'informazione all'interno di un
-singolo filesystem (tralasciando le parti connesse alla strutturazione e al
-funzionamento del filesystem stesso come il super-block) avremo una situazione
-del tipo di quella esposta in \nfig.
+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 \nfig.
+
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione di un filesystem}
+ \includegraphics[width=11cm]{img/filesys_struct.eps}
+ \caption{Strutturazionne dei dati all'interno di un filesystem}
\label{fig:fileintr_filesys_detail}
\end{figure}
-da questa figura si evidenziano alcune caratteristiche su cui è bene porre
-attenzione in quanto sono fondamentali per capire il funzionamento delle
-funzioni che manipolano i file e le directory su cui torneremo fra poco; in
-particolare è opportuno ricordare sempre che:
+
+Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
+cui è bene porre attenzione in quanto sono fondamentali per capire il
+funzionamento delle funzioni che manipolano i file e le directory su cui
+torneremo in seguitp; in particolare è opportuno ricordare sempre che:
\begin{enumerate}
numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
solo quando questo contatore si annulla i dati del file vengono
effettivamente rimossi dal disco. Per questo la funzione per cancellare un
- file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
+ file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
file, ma si limita a eliminare la relativa voce da una directory e
decrementare il numero di riferimenti 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 \textit{inodes} relativi ad altri filesystem. Questo limita
- l'uso del comando \texttt{ln} (che crea una nuova voce per un file
- esistente, con la funzione \texttt{link}) al filesystem corrente.
+ 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 deve essere spostato, 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 \texttt{mv} attraverso la funzione
- \texttt{rename}).
+ in cui opera normalmente il comando \cmd{mv} attraverso la funzione
+ \func{rename}).
\end{enumerate}
Infine è bene avere presente che essendo file pure loro, esiste un numero di
riferimenti anche per le directories; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
-nella directory corrente avremo una situazione come quella in \nfig, dove per
+situazione mostrata in \curfig\ creiamo una nuova directory \texttt{img} nella
+directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
chiarezza abbiamo aggiunto dei numeri di inode.
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=11cm]{img/dir_links.eps}
+ \caption{Organizzazione dei link per le directory}
+ \label{fig:fileintr_dirs_link}
+\end{figure}
+
La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
è referenziata dalla directory da cui si era partiti (in cui è inserita la
-nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
+nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
che è sempre inserita in ogni directory; questo vale sempre per ogni directory
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 \texttt{..} di \texttt{textdir}.
-
+adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
\subsection{Il filesystem \texttt{ext2}}
\label{sec:fileintr_ext2}
sottodirectory ereditano sia il group id che il setgid.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
- peremttono un accesso più veloce, ma sprecano più spazio disco).
+ 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
\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 è
-riportata in \nfig; su ciascun gruppo di blocchi contiene una copia delle
-informazioni essenziali del filesystem (superblock e descrittore del
-filesystem) per una maggiore affidabilità e possibilità di recupero in caso di
-corruzione del superblock principale.
+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.
+
+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+superblock principale.
+
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione logica del \textit{second extented filesystem}.}
- \label{fig:fileintr_ext2_struct}
+ \includegraphics[width=9cm]{img/dir_struct.eps}
+ \caption{Struttura delle directory nel \textit{second extented filesystem}.}
+ \label{fig:fileintr_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
inodes.
-Le directory sono implementate come una linked list di entrate di dimensione
-variabile. Ciascuna entry contiene il numero di inode, la sua lunghezza, il
-nome del file e la sua lunghezza.
-
+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 \curfig;
+in questo modo è possibile implementare nomi per i file anche molto lunghi
+(fino a 1024 caratteri) senza sprecare spazio disco.
projects / gapil.git / blobdiff