sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
Questo viene fatto strutturando l'informazione sul disco attraverso quello che
-si chiama un \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi
-viene resa disponibile ai processi attraverso quello che viene chiamato il
+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 \secref{sec:file_arch_func}).
+% (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
stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
Una directory, come vedremo in maggior dettaglio in
-\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
+sez.~\ref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
particolare che il kernel riconosce come tale. Il suo scopo è quello di
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
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
-\secref{sec:file_access_control}) devono consentire l'accesso all'intero
+sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
\textit{pathname}.
Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte
dalla directory radice del processo; questa, a meno di un \func{chroot} (su
-cui torneremo in \secref{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{pathname!assoluto}. Altrimenti la
+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{pathname!assoluto}. Altrimenti la
ricerca parte dalla directory corrente (su cui torneremo in
-\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
+sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
relativo}\index{pathname!relativo}.
I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
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:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
+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{Virtual File System} è riportato in
-\tabref{tab:file_file_types}.
+tab.~\ref{tab:file_file_types}.
Si tenga ben presente che questa classificazione non ha nulla a che fare con
la classificazione dei file (che in questo caso sono sempre file di dati) in
base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
Alcuni di essi, come le \textit{fifo} (che tratteremo in
-\secref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che
-tratteremo in \capref{cha:socket_intro}) non sono altro che dei riferimenti
+sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che
+tratteremo in cap.~\ref{cha:socket_intro}) non sono altro che dei riferimenti
per utilizzare delle funzionalità di comunicazione fornite dal kernel. Gli
altri sono i \textsl{file di dispositivo}\index{file!di dispositivo} (o
\textit{device file}) che costituiscono una interfaccia diretta per leggere e
un file che contiene dei dati (l'accezione normale di file) \\
\textit{directory} & \textsl{cartella o direttorio} &
un file che contiene una lista di nomi associati a degli
- \textit{inode}\index{inode} (vedi \secref{sec:file_vfs}). \\
+ \textit{inode}\index{inode} (vedi sez.~\ref{sec:file_vfs}). \\
\textit{symbolic link} & \textsl{collegamento simbolico} &
un file che contiene un riferimento ad un altro file/directory \\
\textit{char device} & \textsl{dispositivo a caratteri} &
un file che identifica una periferica ad accesso a blocchi \\
\textit{fifo} & ``\textsl{coda}'' &
un file speciale che identifica una linea di comunicazione software
- unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\
+ unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
\textit{socket}\index{socket} & ``\textsl{presa}''&
un file speciale che identifica una linea di comunicazione software
- bidirezionale (vedi \capref{cha:socket_intro}) \\
+ bidirezionale (vedi cap.~\ref{cha:socket_intro}) \\
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
accedere al loro contenuto.
La prima è l'interfaccia standard di Unix, quella che il manuale delle
-\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
- descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce
+\textsl{glibc} chiama interfaccia dei descrittori di file (o \textit{file
+ descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce
un accesso non bufferizzato; la tratteremo in dettaglio in
-\capref{cha:file_unix_interface}.
+cap.~\ref{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
La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
\textit{stream}\index{file!stream}. Essa fornisce funzioni più evolute e un
accesso bufferizzato (controllato dalla implementazione fatta dalle
-\acr{glibc}), la tratteremo in dettaglio nel \capref{cha:files_std_interface}.
+\acr{glibc}), la tratteremo in dettaglio nel
+cap.~\ref{cha:files_std_interface}.
Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
anche su tutti i sistemi non Unix. Gli \textit{stream}\index{file!stream} sono
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
altri oggetti del VFS (fifo, socket\index{socket}, device, sui quali torneremo
in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di
-controllo (descritte in \secref{sec:file_fcntl} e \secref{sec:file_ioctl}) su
-un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di
-Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i
+controllo (descritte in sez.~\ref{sec:file_fcntl} e sez.~\ref{sec:file_ioctl})
+su un qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard
+di Unix con i \textit{file descriptor}. Allo stesso modo devono essere usati i
\textit{file descriptor}\index{file!descriptor} se si vuole ricorrere a
modalità speciali di I/O come il \textit{file locking}\index{file!locking} o
-l'I/O non-bloccante (vedi \capref{cha:file_advanced}).
+l'I/O non-bloccante (vedi cap.~\ref{cha:file_advanced}).
Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
quella dei \textit{file descriptor}, che permette di poter scegliere tra
% 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:file_link}) aprire un file provvisorio per
+% 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 \secref{sec:file_fd}, quando tratteremo
+% 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.
%% 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 \capref{cha:intro_unix}.
+%% 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 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:file_vfs}.
+% sez.~\ref{sec:file_vfs}.
\subsection{Il \textit{Virtual File System} di Linux}
opportune routine 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
-\figref{fig:file_VFS_scheme}.
+fig.~\ref{fig:file_VFS_scheme}.
\begin{figure}[htb]
\centering
(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 \secref{sec:file_ext2}), inizializzare tutte le variabili
+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
l'uso di quel filesystem.
una directory, un link simbolico, una FIFO, un file di
dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa
essere rappresentata dal VFS (i tipi di file riportati in
-\tabref{tab:file_file_types}). A ciascuno di essi è associata pure una
+tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una
struttura che sta in memoria, e che, oltre alle informazioni sullo specifico
file, contiene anche il riferimento alle funzioni (i \textsl{metodi} del VFS)
da usare per poterlo manipolare.
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:file_fd}). Un elenco delle
+(su questo torneremo in dettaglio in sez.~\ref{sec:file_fd}). Un elenco delle
operazioni previste dal kernel è riportato in
-\tabref{tab:file_file_operations}.
+tab.~\ref{tab:file_file_operations}.
\begin{table}[htb]
\centering
\textbf{Funzione} & \textbf{Operazione} \\
\hline
\hline
- \textsl{\code{open}} & apre il file (vedi \secref{sec:file_open}). \\
- \textsl{\code{read}} & legge dal file (vedi \secref{sec:file_read}).\\
- \textsl{\code{write}} & scrive sul file (vedi \secref{sec:file_write}).\\
+ \textsl{\code{open}} & apre il file (vedi sez.~\ref{sec:file_open}). \\
+ \textsl{\code{read}} & legge dal file (vedi sez.~\ref{sec:file_read}).\\
+ \textsl{\code{write}} & scrive sul file (vedi
+ sez.~\ref{sec:file_write}).\\
\textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi
- \secref{sec:file_lseek}). \\
+ sez.~\ref{sec:file_lseek}). \\
\textsl{\code{ioctl}} & accede alle operazioni di controllo
- (vedi \secref{sec:file_ioctl}).\\
+ (vedi sez.~\ref{sec:file_ioctl}).\\
\textsl{\code{readdir}}& legge il contenuto di una directory \\
\textsl{\code{poll}} & usata nell'I/O multiplexing (vedi
- \secref{sec:file_multiplexing}). \\
+ sez.~\ref{sec:file_multiplexing}). \\
\textsl{\code{mmap}} & mappa il file in memoria (vedi
- \secref{sec:file_memory_map}). \\
+ sez.~\ref{sec:file_memory_map}). \\
\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}). \\
+ sez.~\ref{sec:file_sync}). \\
\textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
- \secref{sec:file_asyncronous_io}) sul file. \\
+ sez.~\ref{sec:file_asyncronous_io}) sul file. \\
\hline
\end{tabular}
\caption{Operazioni sui file definite nel VFS.}
\subsection{Il funzionamento di un filesystem Unix}
\label{sec:file_filesystem}
-Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
+Come già accennato in sez.~\ref{sec:file_organization} Linux (ed ogni sistema
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
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 \figref{fig:file_disk_filesys};
+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
superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
-\secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+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
inode\index{inode} e lo spazio a disposizione per i dati e le directory.
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
-\figref{fig:file_filesys_detail}.
+fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[htb]
\centering
\label{fig:file_filesys_detail}
\end{figure}
-Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+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
dell'\textit{inode}\index{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 \secref{sec:file_vfs}).
+ le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}).
-\item Come mostrato in \figref{fig:file_filesys_detail} si possono avere più
+\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
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
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 \figref{fig:file_filesys_detail} creiamo una nuova directory
+mostrata in fig.~\ref{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\index{inode}.
+fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
+di inode\index{inode}.
\begin{figure}[htb]
\centering
semantica SVr4 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 \acr{sgid} impostato (per una descrizione dettagliata del significato di
- questi termini si veda \secref{sec:file_access_control}), nel qual caso file
- e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+ questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
+ file e subdirectory ereditano sia il \acr{gid} che lo \acr{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).
log).
\end{itemize}
-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 \figref{fig:file_filesys_detail}, in cui la partizione
-è divisa in gruppi di blocchi.
+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
+ 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
+ usata dal kernel per un filesystem \acr{ext2}, definita nel file
+ \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
+ kernel.}
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
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
-\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.
+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.
projects / gapil.git / blobdiff