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 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
\subsection{L'organizzazione di file e directory}
\label{sec:file_organization}
-\index{\textit{pathname}|(}
+\itindbeg{pathname}
In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
file vengono tenuti all'interno di un unico albero la cui radice (quella che
viene chiamata \textit{root directory}) viene montata all'avvio. Un file
Un file può essere indicato rispetto alla directory corrente semplicemente
specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
-contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
-components}), noi li chiameremo più semplicemente \textsl{nomi} o
-\textsl{voci}.} da essa contenuto. All'interno dello stesso albero si
+ contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
+ components}), noi li chiameremo più semplicemente \textsl{nomi} o
+ \textsl{voci}.} 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\index{socket}
-e gli stessi file di dispositivo \index{file!di~dispositivo} (questi ultimi,
-per convenzione, sono inseriti nella directory \file{/dev}).
+l'interfaccia che manipola i file come le fifo, i link, i socket e gli stessi
+file di dispositivo \index{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
procedimento con cui si individua il file a cui esso fa riferimento è chiamato
directory radice del processo; questa, a meno di un \func{chroot} (su 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{\textit{pathname}!assoluto}. Altrimenti
-la ricerca parte dalla directory corrente (su cui torneremo in
+di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la
+ricerca parte dalla directory corrente (su cui torneremo in
sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
-relativo}\index{\textit{pathname}!relativo}.
+ relativo} \itindsub{pathname}{relativo}.
I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
in ogni directory: il primo fa riferimento alla directory corrente e il
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.
+\itindend{pathname}
\subsection{I tipi di file}
sono implementati come oggetti del \textit{Virtual File System} (vedi
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{\textit{Virtual~File~System}} è riportato in
+\textit{Virtual File System}\itindex{Virtual~File~System} è riportato in
tab.~\ref{tab:file_file_types}.
Si tenga ben presente che questa classificazione non ha nulla a che fare con
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
-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
-scrivere sui dispositivi fisici; essi vengono suddivisi in due grandi
-categorie, \textsl{a blocchi} e \textsl{a caratteri} a seconda delle modalità
-in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in
- sostanza i dispositivi a blocchi (ad esempio i dischi) corrispondono a
- periferiche per le quali è richiesto che l'I/O venga effettuato per blocchi
- di dati di dimensioni fissate (ad esempio le dimensioni di un settore),
- mentre nei dispositivi a caratteri l'I/O viene effettuato senza nessuna
- particolare struttura.}
+sez.~\ref{sec:ipc_named_pipe}) ed i \textit{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 scrivere sui
+dispositivi fisici; essi vengono suddivisi in due grandi categorie, \textsl{a
+ blocchi} e \textsl{a caratteri} a seconda delle modalità in cui il
+dispositivo sottostante effettua le operazioni di I/O.\footnote{in sostanza i
+ dispositivi a blocchi (ad esempio i dischi) corrispondono a periferiche per
+ le quali è richiesto che l'I/O venga effettuato per blocchi di dati di
+ dimensioni fissate (ad esempio le dimensioni di un settore), mentre nei
+ dispositivi a caratteri l'I/O viene effettuato senza nessuna particolare
+ struttura.}
\begin{table}[htb]
\footnotesize
\textit{fifo} & ``\textsl{coda}'' &
un file speciale che identifica una linea di comunicazione software
unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\
- \textit{socket}\index{socket} & ``\textsl{presa}''&
+ \textit{socket} & ``\textsl{presa}''&
un file speciale che identifica una linea di comunicazione software
bidirezionale (vedi cap.~\ref{cha:socket_intro}) \\
\hline
\file{stdio.h}.
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
+altri oggetti del VFS (fifo, socket, dispositivi, sui quali torneremo in
+dettaglio a tempo opportuno), ma per poter accedere alle operazioni di
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
+\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 cap.~\ref{cha:file_advanced}).
\section{L'architettura della gestione dei 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 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 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
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
-% funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
-% accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
-% sez.~\ref{sec:file_vfs}.
-
\subsection{Il \textit{Virtual File System} di Linux}
\label{sec:file_vfs}
-% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
-% file. L'argomento è abbastanza ``esoterico'' e questa sezione può essere
-% saltata ad una prima lettura; è bene però tenere presente che vengono
-% introdotti qui alcuni termini che potranno comparire in seguito, come
-% \textit{inode}, \textit{dentry}, \textit{dcache}.
-
+\itindbeg{Virtual~File~System}
In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual File System}\index{\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 manipolazione sui file alle operazioni di I/O, e
-gestisce l'organizzazione di queste ultime nei vari modi in cui i diversi
-filesystem le effettuano, permettendo la coesistenza di filesystem differenti
-all'interno dello stesso albero delle directory.
+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
+manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
+queste ultime nei vari modi in cui i diversi filesystem le effettuano,
+permettendo la coesistenza di filesystem differenti all'interno dello stesso
+albero delle directory.
Quando un processo esegue una system call che opera su un file, il kernel
chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
-opportune routine del filesystem specifico a cui si fa riferimento. Saranno
+opportune funzioni 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
fig.~\ref{fig:file_VFS_scheme}.
nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
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
+attraverso quest'ultimo diventa possibile accedere alle funzioni specifiche per
l'uso di quel filesystem.
Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
-alle routine specifiche di quel filesystem.
+alle funzioni specifiche di quel filesystem.
Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
\subsection{Il funzionamento del \textit{Virtual File System}}
\label{sec:file_vfs_work}
-La funzione più importante implementata dal
-VFS\index{\textit{Virtual~File~System}} è la system call \func{open} che
-permette di aprire un file. Dato un \index{\textit{pathname}}\textit{pathname}
+La funzione più importante implementata dal VFS è la system call \func{open}
+che permette di aprire un file. Dato un \itindex{pathname}\textit{pathname}
viene eseguita una ricerca dentro la \textit{directory entry cache} (in breve
\textit{dcache}), una tabella che contiene tutte le \textit{directory entry}
(in breve \textit{dentry}) che permette di associare in maniera rapida ed
l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
-\index{\textit{pathname}}\textit{pathname} il VFS deve creare una nuova
+\itindex{pathname}\textit{pathname} il VFS deve creare una nuova
\textit{dentry} e caricare l'inode\index{inode} corrispondente in memoria.
Questo procedimento viene eseguito dal metodo \code{lookup()}
In questo modo per ciascun file diventano possibili una serie di operazioni
(non è detto che tutte siano disponibili), che costituiscono l'interfaccia
astratta del VFS. Qualora se ne voglia eseguire una, il kernel andrà ad
-utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al
+utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al
tipo di file in questione.
Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
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.
+\itindend{Virtual~File~System}
\subsection{Il funzionamento di un filesystem Unix}
prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
inode\index{inode}.
-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
-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.
-
-
+Le directory sono implementate come una \itindex{linked~list}\textit{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 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.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "gapil"
%%% End:
+
+% LocalWords: everything is device kernel filesystem sez pathname root glibc
+% LocalWords: path filename bootloader proc name components fifo socket dev LF
+% LocalWords: resolution chroot parent Virtual System like tab cap l'I regular
+% LocalWords: inode symbolic char block VFS VMS Windows dell'I raw access Mac
+% LocalWords: CR dos HFS l'XFS SGI magic number descriptor system call int ext
+% LocalWords: nell'header unistd stream dall'ANSI stdio locking POSIX fig type
+% LocalWords: register superblock dell'inode stat entry cache dcache dentry ln
+% LocalWords: l'inode lookup ops read write llseek ioctl readdir poll nell'I
+% LocalWords: multiplexing mmap fsync fasync seek MacOs group dall' dell' img
+% LocalWords: count unlink nell' rename gapil second Tb attributes BSD SVr gid
+% LocalWords: sgid append only log fs linux extented linked list