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 i file di dispositivo (questi
+come le fifo, i link, i socket e gli stessi 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
I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
in ogni directory: il primo fa riferimento alla directory corrente e il
secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
-la directory che contiene il riferimento alla directory corrente; nel caso
-questa sia 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.
\subsection{I tipi di 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 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 \capref{cha:intro_unix}.
+unix-like ed il comportamento delle relative funzioni di manipolazione,
+occorre una breve introduzione al funzionamento 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 \capref{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
prima le caratteristiche generali di un filesystem di un sistema unix-like,
-per poi trattare in maniera un po' più dettagliata il filesystem standard di
+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
% \secref{sec:file_vfs}.
-\subsection{Il \textit{Virtual Filesystem} di Linux}
+\subsection{Il \textit{Virtual File System} di Linux}
\label{sec:file_vfs}
% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
% \textit{inode}, \textit{dentry}, \textit{dcache}.
In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+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
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:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in \ntab.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.
\begin{table}[htb]
\centering
\secref{sec:file_multiplexing}). \\
\textsl{\code{mmap}} & mappa il file in memoria (vedi
\secref{sec:file_memory_map}). \\
- \textsl{\code{release}}& chiamata quando l'ultima referenza a un file
- aperto è chiusa. \\
+ \textsl{\code{release}}& chiamata quando l'ultimo riferimento a un file
+ aperto è chiuso. \\
\textsl{\code{fsync}} & sincronizza il contenuto del file (vedi
\secref{sec:file_sync}). \\
\textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
di file in questione.
-In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
-su normale un 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.
+Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su
+normale un 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.
\subsection{Il funzionamento di un filesystem Unix}
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 \nfig; in essa si fa riferimento
-alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
-in \textit{blocks group} che replicano il 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 inodes e lo spazio a disposizione per i dati e le directory.
+dell'informazione su un disco è riportata in \figref{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
+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
+inodes e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
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.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.
\begin{figure}[htb]
\centering
\label{fig:file_filesys_detail}
\end{figure}
-Da \curfig\ 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:
+Da \figref{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:
\begin{enumerate}
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 \curfig\ si possono avere più voci che puntano allo
- stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
- 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 \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}.
+
+\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
+ contatore che contiene il 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 \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}.
\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
Infine è bene avere presente che, essendo file pure loro, esiste un numero di
riferimenti anche per le directory; per cui, se a partire dalla situazione
-mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
-\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
-abbiamo aggiunto dei numeri di inode.
+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.
\begin{figure}[htb]
\centering
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.
+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.
projects / gapil.git / blobdiff