+In questo capitolo tratteremo in dettaglio le modalità con cui si gestiscono
+file e directory, iniziando da un approfondimento dell'architettura del
+sistema illustrata a grandi linee in sez.~\ref{sec:file_arch_overview} ed
+illustrando le principali caratteristiche di un filesystem e le interfacce
+che consentono di controllarne il montaggio e lo smontaggio.
+
+Esamineremo poi le funzioni di libreria che si usano per copiare, spostare e
+cambiare i nomi di file e directory e l'interfaccia che permette la
+manipolazione dei loro attributi. Tratteremo inoltre la struttura di base del
+sistema delle protezioni e del controllo dell'accesso ai file e le successive
+estensioni (\textit{Extended Attributes}, ACL, quote disco). Tutto quello che
+riguarda invece la gestione dell'I/O sui file è lasciato al capitolo
+successivo.
+
+
+
+\section{L'architettura della gestione dei file}
+\label{sec:file_arch_func}
+
+In questa sezione tratteremo con maggiori dettagli rispetto a quanto visto in
+sez.~\ref{sec:file_arch_overview} il \textit{Virtual File System} di Linux e
+come il kernel può gestire diversi tipi di filesystem, descrivendo prima le
+caratteristiche generali di un filesystem di un sistema unix-like, per poi
+fare una panoramica sul filesystem tradizionalmente più usato con Linux,
+l'\acr{ext2} ed i suoi successori.
+
+
+\subsection{Il funzionamento del \textit{Virtual File System} di Linux}
+\label{sec:file_vfs_work}
+
+% NOTE articolo interessante:
+% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
+
+\itindbeg{Virtual~File~System~(VFS)}
+
+Come illustrato brevemente in sez.~\ref{sec:file_arch_overview} in Linux il
+concetto di \textit{everything is a file} è stato implementato attraverso il
+\textit{Virtual File System}, la cui struttura generale è illustrata in
+fig.~\ref{fig:file_VFS_scheme}. Il VFS definisce un insieme di funzioni che
+tutti i filesystem devono implementare per l'accesso ai file che contengono e
+l'interfaccia che consente di eseguire l'I/O sui file, che questi siano di
+dati o dispositivi.
+
+\itindbeg{inode}
+
+L'interfaccia fornita dal VFS comprende in sostanza tutte le funzioni che
+riguardano i file, le operazioni implementate dal VFS sono realizzate con una
+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 è molto complessa, ne faremo pertanto una trattazione
+estremamente semplificata che consenta di comprenderne i principi
+di funzionamento.
+
+Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
+filesystem supportato, quando si vuole inserire il supporto di un nuovo
+filesystem tutto quello che occorre è chiamare la funzione
+\code{register\_filesystem} passando come argomento la struttura
+\kstruct{file\_system\_type} (la cui definizione è riportata in
+fig.~\ref{fig:kstruct_file_system_type}) relativa a quel filesystem. Questa
+verrà inserita nella tabella, ed il nuovo filesystem comparirà in
+\procfile{/proc/filesystems}.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.80\textwidth}
+ \includestruct{listati/file_system_type.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file\_system\_type} usata dal
+ VFS (da \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file_system_type}
+\end{figure}
+
+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
+ 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}.
+
+\itindbeg{pathname}
+\itindbeg{pathname~resolution}
+
+Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
+restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
+ entry}. Le \textit{dentry} sono gli oggetti che il kernel usa per eseguire
+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
+file.\footnote{in questo caso si parla di file come di un qualunque oggetto
+ 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
+
+Le \textit{dentry} sono oggetti del VFS che vivono esclusivamente in memoria,
+nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve
+\textit{dcache}). Ogni volta che una \textit{system call} specifica un
+\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 volta ci darà, tramite
+l'\textit{inode}, il riferimento al file.
+
+Dato che normalmente non è possibile mantenere nella \textit{dcache} le
+informazioni relative a tutto l'albero dei file la procedura della
+\textit{pathname resolution} richiede un meccanismo con cui riempire gli
+eventuali vuoti. Il meccanismo prevede che tutte le volte che si arriva ad una
+\textit{dentry} mancante venga invocata la funzione \texttt{lookup}
+dell'\textit{inode} associato alla \textit{dentry} precedente nella
+risoluzione del \textit{pathname},\footnote{che a questo punto è una
+ directory, per cui si può cercare al suo interno il nome di un file.} il cui
+scopo è risolvere il nome mancante e fornire la sua \textit{dentry} che a
+questo punto verrà inserita nella cache.
+
+Dato che tutte le volte che si monta un filesystem la funzione \texttt{mount}
+(vedi sez.~\ref{sec:filesystem_mounting}) della corrispondente
+\kstruct{file\_system\_type} inserisce la \textit{dentry} iniziale nel
+\textit{mount point} dello stesso, si avrà comunque un punto di
+partenza. Inoltre essendo questa \textit{dentry} relativa a quel tipo di
+filesystem essa farà riferimento ad un \textit{inode} di quel filesystem, e
+come vedremo questo farà sì che venga eseguita una \texttt{lookup} adatta per
+effettuare la risoluzione dei nomi per quel filesystem.
+
+\itindend{pathname}
+\itindend{pathname~resolution}
+
+% Un secondo effetto della chiamata funzione \texttt{mount} di
+% \kstruct{file\_system\_type} è quello di allocare una struttura
+% \kstruct{super\_block} per ciascuna istanza montata, che contiene le
+% informazioni generali di un qualunque filesystem montato, come le opzioni di
+% montaggio, le dimensioni dei blocchi, quando il filesystem è stato montato
+% ecc. Fra queste però viene pure inserta, nel campo \var{s\_op}, una ulteriore
+% struttura \kstruct{super\_operations}, il cui contenuto sono i puntatori
+% alle funzioni di gestione di un filesystem, anche inizializzata in modo da
+% utilizzare le versioni specifiche di quel filesystem.
+
+L'oggetto più importante per il funzionamento del VFS è probabilmente
+l'\textit{inode}, ma con questo nome si può fare riferimento a due cose
+diverse. La prima è la struttura su disco (su cui torneremo anche in
+sez.~\ref{sec:file_filesystem}) che fa parte della organizzazione dei dati
+realizzata dal filesystem e che contiene le informazioni relative alle
+proprietà (i cosiddetti \textsl{metadati}) di ogni oggetto presente su di esso
+(si intende al solito uno qualunque dei tipi di file di
+tab.~\ref{tab:file_file_types}).
+
+La seconda è la corrispondente struttura \kstruct{inode}, della cui
+definizione si è riportato un estratto in
+fig.~\ref{fig:kstruct_inode}.\footnote{l'estratto fa riferimento alla versione
+ del kernel 2.6.37.} Questa struttura viene mantenuta in memoria ed è a
+questa che facevamo riferimento quando parlavamo dell'\textit{inode} associato
+a ciascuna \textit{dentry}. Nella struttura in memoria sono presenti gli
+stessi \textsl{metadati} memorizzati su disco, che vengono letti quando questa
+struttura viene allocata e trascritti all'indietro se modificati.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/inode.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{inode} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_inode}
+\end{figure}
+
+Il fatto che la struttura \kstruct{inode} sia mantenuta in memoria,
+direttamente associata ad una \textit{dentry}, rende sostanzialmente immediate
+le operazioni che devono semplicemente effettuare un accesso ai dati in essa
+contenuti: è così ad esempio che viene realizzata la \textit{system call}
+\func{stat} che vedremo in sez.~\ref{sec:file_stat}. Rispetto ai dati salvati
+sul disco questa struttura contiene però anche quanto necessario alla
+implementazione del VFS, ed in particolare è importante il campo \var{i\_op}
+che, come illustrato in fig.~\ref{fig:kstruct_inode}, contiene il puntatore ad
+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 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
+ \footnotesize
+ \begin{tabular}[c]{|l|l|}
+ \hline
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\code{create}} & Chiamata per creare un nuovo file (vedi
+ sez.~\ref{sec:file_open_close}).\\
+ \textsl{\code{link}} & Crea un \textit{hard link} (vedi
+ sez.~\ref{sec:link_symlink_rename}).\\
+ \textsl{\code{unlink}} & Cancella un \textit{hard link} (vedi
+ sez.~\ref{sec:link_symlink_rename}).\\
+ \textsl{\code{symlink}}& Crea un collegamento simbolico (vedi
+ sez.~\ref{sec:link_symlink_rename}).\\
+ \textsl{\code{mkdir}} & Crea una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{rmdir}} & Rimuove una directory (vedi
+ sez.~\ref{sec:file_dir_creat_rem}).\\
+ \textsl{\code{mknod}} & Crea un file speciale (vedi
+ sez.~\ref{sec:file_mknod}).\\
+ \textsl{\code{rename}} & Cambia il nome di un file (vedi
+ sez.~\ref{sec:link_symlink_rename}).\\
+ \textsl{\code{lookup}}& Risolve il nome di un file.\\
+ \hline
+ \end{tabular}
+ \caption{Le principali operazioni sugli \textit{inode} definite tramite
+ \kstructd{inode\_operation}.}
+ \label{tab:file_inode_operations}
+\end{table}
+
+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
+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
+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
+tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque
+ invocata dato che nella struttura \kstruct{inode} è presente anche il
+ puntatore \var{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 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 operazioni eseguite dai processi con l'interfaccia
+dei file descriptor. Ogni processo infatti mantiene il riferimento ad una
+struttura \kstruct{file} per ogni file che ha aperto, ed è tramite essa che
+esegue le operazioni di I/O. Inoltre il kernel mantiene un elenco di tutti i
+file aperti nella \textit{file table} (torneremo su questo in
+sez.~\ref{sec:file_fd}).
+
+Inoltre se le operazioni relative agli \textit{inode} fanno riferimento ad
+oggetti posti all'interno di un filesystem e vi si applicano quindi le
+funzioni fornite nell'implementazione di quest'ultimo, quando si apre un file
+questo può essere anche un file di dispositivo, ed in questo caso il VFS
+invece di usare le operazioni fornite dal filesystem (come farebbe per un file
+di dati) dovrà invece ricorrere a quelle fornite dal driver del dispositivo.
+
+\itindend{inode}
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/file.h}
+ \end{minipage}
+ \normalsize
+ \caption{Estratto della struttura \kstructd{file} del kernel (da
+ \texttt{include/linux/fs.h}).}
+ \label{fig:kstruct_file}
+\end{figure}
+
+Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
+\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
+dei file descriptor il cui significato emergerà più avanti, il puntatore
+\var{f\_op} ad una struttura \kstruct{file\_operation}. Questa è l'analoga per
+i file di \kstruct{inode\_operation}, e definisce le operazioni generiche
+fornite dal VFS per i file. Si sono riportate in
+tab.~\ref{tab:file_file_operations} le più significative.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\code{open}} & Apre il file (vedi
+ sez.~\ref{sec:file_open_close}).\\
+ \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
+ sez.~\ref{sec:file_lseek}).\\
+ \textsl{\code{ioctl}} & Accede alle operazioni di controllo
+ (vedi sez.~\ref{sec:file_fcntl_ioctl}).\\
+ \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi
+ sez.~\ref{sec:file_dir_read}).\\
+ \textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi
+ sez.~\ref{sec:file_multiplexing}).\\
+ \textsl{\code{mmap}} & Mappa il file in memoria (vedi
+ 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
+ sez.~\ref{sec:file_sync}).\\
+ \textsl{\code{fasync}} & Abilita l'I/O asincrono (vedi
+ sez.~\ref{sec:file_asyncronous_io}) sul file.\\
+ \hline
+ \end{tabular}
+ \caption{Operazioni sui file definite tramite \kstructd{file\_operation}.}
+ \label{tab:file_file_operations}
+\end{table}
+
+Anche in questo caso tutte le volte che deve essere eseguita una
+\textit{system call} o una qualunque altra operazione sul file il VFS andrà ad
+utilizzare la funzione corrispondente attraverso il puntatore
+\var{f\_op}. Dato che è cura del VFS quando crea la struttura all'apertura del
+file assegnare a \var{f\_op} il puntatore alla versione di
+\kstruct{file\_operation} corretta per quel file, sarà possibile scrivere allo
+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} e
+\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
+possibili siano poi disponibili in tutti i casi, ad esempio \code{llseek} non
+sarà presente per un dispositivo come la porta seriale o per una
+\textit{fifo}, mentre sui file del filesystem \texttt{vfat} non saranno
+disponibili i permessi, ma resta il fatto che grazie al VFS le \textit{system
+ call} per le operazioni sui file possono restare sempre le stesse nonostante
+le enormi differenze che possono esserci negli oggetti a cui si applicano.
+
+
+\itindend{Virtual~File~System~(VFS)}
+
+% NOTE: documentazione interessante:
+% * sorgenti del kernel: Documentation/filesystems/vfs.txt
+% * http://thecoffeedesk.com/geocities/rkfs.html
+% * http://www.linux.it/~rubini/docs/vfs/vfs.html
+
+
+
+\subsection{Il funzionamento di un filesystem Unix}
+\label{sec:file_filesystem}
+
+Come già accennato in sez.~\ref{sec:file_arch_overview} 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
+diversi, ognuno dei quali avrà una sua particolare struttura e funzionalità
+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.
+
+\itindbeg{superblock}
+
+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}.
+
+\itindend{superblock}
+\itindbeg{inode}
+
+È 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
+\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=11cm]{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 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
+ \includegraphics[width=11cm]{img/filesys_struct}
+ \caption{Strutturazione dei dati all'interno di un filesystem.}
+ \label{fig:file_filesys_detail}
+\end{figure}
+
+Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
+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} contiene i cosiddetti \textsl{metadati}, vale dire le
+ informazioni riguardanti le proprietà del file come oggetto del filesystem:
+ 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 dell'\textit{inode} ad esso associato; il nome non è una
+ proprietà del file e non viene mantenuto nell'\textit{inode}. Da da qui in
+ poi chiameremo il nome del file contenuto in una directory
+ ``\textsl{voce}'', come traduzione della nomenclatura inglese
+ \textit{directory entry} che non useremo per evitare confusione con le
+ \textit{dentry} del kernel viste in sez.~\ref{sec:file_vfs_work}.
+
+\item Come mostrato in fig.~\ref{fig:file_filesys_detail} per i file
+ \texttt{macro.tex} e \texttt{gapil\_macro.tex}, ci possono avere più voci
+ che fanno riferimento allo stesso \textit{inode}. Fra le proprietà di un
+ file mantenute nell'\textit{inode} c'è anche il contatore con il numero di
+ riferimenti che sono stati fatti ad esso, il cosiddetto \textit{link
+ count}.\footnote{mantenuto anche nel campo \var{i\_nlink} della struttura
+ \kstruct{inode} di fig.~\ref{fig:kstruct_inode}.} Solo quando questo
+ contatore si annulla i dati del file possono essere effettivamente rimossi
+ dal disco. Per questo la funzione per cancellare un file si chiama
+ \func{unlink} (vedi sez.~\ref{sec:link_symlink_rename}), 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 All'interno di ogni filesystem ogni \textit{inode} è identificato da un
+ numero univoco. Il numero di \textit{inode} associato ad una voce in una
+ directory si riferisce ad questo numero e non ci può essere una directory
+ che contiene riferimenti ad \textit{inode} relativi ad altri filesystem.
+ Questa è la ragione che limita l'uso del comando \cmd{ln}, che crea una
+ nuova voce per un file esistente con la funzione \func{link} (vedi
+ sez.~\ref{sec:link_symlink_rename}), a operare su file nel 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
+ nuova voce per l'\textit{inode} in questione e rimossa la precedente, questa
+ è la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
+ funzione \func{rename} (vedi sez.~\ref{sec:link_symlink_rename}). Questa
+ operazione non modifica minimamente neanche l'\textit{inode} del file, dato
+ che non si opera sul file ma sulla directory che lo contiene.
+
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati}, ed i
+ blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
+ in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+ possibile esaurire sia lo spazio disco (il caso più comune) che lo spazio
+ per gli \textit{inode}. Nel primo caso non sarà possibile allocare ulteriore
+ spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
+ creare nuovi file, ma si potranno estendere quelli che ci
+ sono.\footnote{questo comportamento non è generale, alcuni filesystem più
+ sofisticati possono evitare il problema dell'esaurimento degli
+ \textit{inode} riallocando lo spazio disco libero per i blocchi.}
+
+\end{enumerate*}
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=12cm]{img/dir_links}
+ \caption{Organizzazione dei \textit{link} per le directory.}
+ \label{fig:file_dirs_link}
+\end{figure}
+
+Infine tenga presente che, essendo file pure loro, il numero di riferimenti
+esiste anche per le directory. Per questo se a partire dalla situazione
+mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory
+\file{img} nella directory \file{gapil}, avremo una situazione come quella
+illustrata in fig.~\ref{fig:file_dirs_link}.
+
+La nuova directory avrà 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{img}) e dalla voce interna ``\texttt{.}''
+che è presente in ogni directory. Questo è il valore che si troverà sempre
+per ogni directory che non contenga a sua volta altre directory. Al contempo,
+la directory da cui si era partiti avrà un numero di riferimenti di almeno
+tre, in quanto adesso sarà referenziata anche dalla voce ``\texttt{..}'' di
+\texttt{img}. L'aggiunta di una sottodirectory fa cioè crescere di uno il
+\textit{link count} della directory genitrice.
+
+\itindend{inode}
+
+
+\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
+\label{sec:file_ext2}
+
+Benché non esista ``il'' filesystem di Linux, dato che esiste un supporto
+nativo di diversi filesystem che sono in uso da anni, quello che gli avvicina
+di più è la famiglia di filesystem evolutasi a partire dal \textit{second
+ extended filesystem}, o \acr{ext2}. Il filesystem \acr{ext2} ha subito un
+grande sviluppo e diverse evoluzioni, fra cui l'aggiunta del
+\textit{journaling} con il passaggio ad \acr{ext3}, che probabilmente è ancora
+il filesystem più diffuso, ed una serie di ulteriori miglioramenti con il
+successivo \acr{ext4}. In futuro è previsto che questo debba essere sostituito
+da un filesystem completamente diverso, \acr{btrfs}, che dovrebbe diventare il
+filesystem standard di Linux, ma questo al momento è ancora in fase di
+sviluppo.\footnote{si fa riferimento al momento dell'ultima revisione di
+ questo paragrafo, l'inizio del 2012.}
+
+Il filesystem \acr{ext2} nasce come filesystem nativo per Linux a partire
+dalle prime versioni del kernel e supporta tutte le caratteristiche di un
+filesystem standard Unix: è in grado di gestire nomi di file lunghi (256
+caratteri, estensibili a 1012) e supporta una dimensione massima dei file fino
+a 4~Tb. I successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di
+questo filesystem, e sia pure con molti miglioramenti ed estensioni
+significative ne mantengono le caratteristiche fondamentali.
+
+Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
+non sono presenti su un classico filesystem di tipo Unix; le principali sono
+le seguenti:
+\begin{itemize*}
+\item gli attributi estesi (vedi sez.~\ref{sec:file_xattr}) che consentono di
+ estendere le informazioni salvabili come metadati e le ACL (vedi
+ sez.~\ref{sec:file_ACL}) che consentono di estendere il modello tradizionale
+ dei permessi sui file.
+\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
+ montaggio. La semantica BSD comporta che i file in una directory sono creati
+ con lo stesso identificatore di gruppo della directory che li contiene. La
+ 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 sez.~\ref{sec:file_access_control}), nel qual caso
+ file e subdirectory ereditano sia il \ids{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.
+\item il filesystem implementa collegamenti simbolici veloci, in cui il nome
+ del file non è salvato su un blocco, ma tenuto all'interno
+ dell'\textit{inode} (evitando letture multiple e spreco di spazio), non
+ tutti i nomi però possono essere gestiti così per limiti di spazio (il
+ limite è 60 caratteri).
+\item vengono supportati i cosiddetti \textit{file attributes} (vedi
+ sez.~\ref{sec:file_perm_overview}) che attivano comportamenti specifici per
+ i file su cui vengono attivati come marcarli come immutabili (che possono
+ cioè essere soltanto letti) per la protezione di file di configurazione
+ sensibili, o come \textit{append-only} (che possono essere aperti in
+ scrittura solo per aggiungere dati) per la protezione dei file di 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 fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa
+in gruppi di blocchi.
+
+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (i \textit{superblock} sono quindi ridondati) per una maggiore
+affidabilità e possibilità di recupero in caso di corruzione del
+\textit{superblock} principale. L'utilizzo di raggruppamenti di blocchi ha
+inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la
+distanza fra i dati e la tabella degli \textit{inode}.
+
+\begin{figure}[!htb]
+ \centering
+ \includegraphics[width=9cm]{img/dir_struct}
+ \caption{Struttura delle directory nel \textit{second extended filesystem}.}
+ \label{fig:file_ext2_dirs}
+\end{figure}
+
+
+Le directory sono implementate come una \textit{linked list} con voci di
+dimensione variabile. Ciascuna voce della lista contiene il numero di
+\textit{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.
+
+Con l'introduzione del filesystem \textit{ext3} sono state introdotte diverse
+modifiche strutturali, la principale di queste è quella che \textit{ext3} è un
+filesystem \textit{journaled}, è cioè in grado di eseguire una registrazione
+delle operazioni di scrittura su un giornale (uno speciale file interno) in
+modo da poter garantire il ripristino della coerenza dei dati del
+filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
+ filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
+ garantito un veloce ripristino è relativo ai dati della struttura interna
+ del filesystem, non di eventuali dati contenuti nei file che potrebbero
+ essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
+della corrente o di crollo del sistema che abbia causato una interruzione
+della scrittura dei dati sul disco.
+
+Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
+sia le prestazioni che la semplicità di gestione del filesystem, in
+particolare per le directory si è passato all'uso di alberi binari con
+indicizzazione tramite \textit{hash} al posto delle \textit{linked list} che
+abbiamo illustrato, ottenendo un forte guadagno di prestazioni in caso di
+directory contenenti un gran numero di file.
+
+% TODO (bassa priorità) portare a ext3, ext4 e btrfs ed illustrare le
+% problematiche che si possono incontrare (in particolare quelle relative alla
+% perdita di contenuti in caso di crash del sistema)
+% TODO (media priorità) trattare btrfs quando sarà usato come stabile
+
+
+\subsection{La gestione dell'uso dei filesystem}
+\label{sec:filesystem_mounting}
+
+Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
+occorre rendere disponibile al sistema il filesystem su cui essi sono
+memorizzati. L'operazione di attivazione del filesystem è chiamata
+\textsl{montaggio} e per far questo in Linux si usa la funzione di sistema
+\funcd{mount}, il cui prototipo è:\footnote{la funzione è una versione
+ specifica di Linux che usa la omonima \textit{system call} e non è
+ portabile.}
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{mount(const char *source, const char *target, const char
+ *filesystemtype, \\
+\phantom{mount(}unsigned long mountflags, const void *data)}
+\fdesc{Monta un filesystem.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+ caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
+ componenti del \textit{pathname}, o si è cercato di montare un filesystem
+ disponibile in sola lettura senza aver specificato \const{MS\_RDONLY} o il
+ device \param{source} è su un filesystem montato con l'opzione
+ \const{MS\_NODEV}.
+ \item[\errcode{EBUSY}] \param{source} è già montato, o non può essere
+ rimontato in sola lettura perché ci sono ancora file aperti in scrittura,
+ o non può essere montato su \param{target} perché la directory è ancora in
+ uso.
+ \item[\errcode{EINVAL}] il dispositivo \param{source} presenta un
+ \textit{superblock} non valido, o si è cercato di rimontare un filesystem
+ non ancora montato, o di montarlo senza che \param{target} sia un
+ \textit{mount point} o di spostarlo quando \param{target} non è un
+ \textit{mount point} o è la radice o si è usato un valore di
+ \param{mountflags} non valido.
+ \item[\errcode{ELOOP}] si è cercato di spostare un \textit{mount point} su
+ una sottodirectory di \param{source} o si sono incontrati troppi
+ collegamenti simbolici nella risoluzione di un nome.
+ \item[\errcode{EMFILE}] in caso di filesystem virtuale, la tabella dei
+ dispositivi fittizi (chiamati \textit{dummy} nella documentazione inglese)
+ è piena.
+ \item[\errcode{ENODEV}] il tipo \param{filesystemtype} non esiste o non è
+ configurato nel kernel.
+ \item[\errcode{ENOTBLK}] non si è usato un \textit{block device} per
+ \param{source} quando era richiesto.
+ \item[\errcode{ENXIO}] il \textit{major number} del
+ dispositivo \param{source} è sbagliato.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ENOMEM}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOTDIR} nel loro significato generico.}
+\end{funcproto}
+
+\itindbeg{mount~point}
+
+L'uso più comune della funzione è quello di montare sulla directory indicata
+da \param{target}, detta \textit{mount point}, il filesystem contenuto nel
+file di dispositivo indicato da \param{source}. In entrambi i casi, come
+daremo per assunto da qui in avanti tutte le volte che si parla di directory o
+file nel passaggio di un argomento di una funzione, si intende che questi
+devono essere indicati con la stringa contenente il loro \textit{pathname}.
+
+Normalmente un filesystem è contenuto su un disco o una partizione, ma come
+illustrato in sez.~\ref{sec:file_vfs_work} la struttura del \textit{Virtual
+ File System} è estremamente flessibile e può essere usata anche per oggetti
+diversi da un disco. Ad esempio usando il \textit{loop device} si può montare
+un file qualunque (come l'immagine di un CD-ROM o di un floppy) che contiene
+l'immagine di un filesystem, inoltre alcuni tipi di filesystem, come
+\texttt{proc} o \texttt{sysfs} sono virtuali e non hanno un supporto che ne
+contenga i dati che sono generati al volo dal kernel ad ogni lettura, e
+inviati al kernel ad ogni scrittura (costituiscono quindi un meccanismo di
+comunicazione, attraverso l'ordinaria interfaccia dei file, con il kernel).
+
+Il tipo di filesystem che si vuole montare è specificato
+dall'argomento \param{filesystemtype}, che deve essere una delle stringhe
+riportate nel file \procfilem{/proc/filesystems} che, come accennato in
+sez.~\ref{sec:file_vfs_work}, contiene l'elenco dei filesystem supportati dal
+kernel. Nel caso si sia indicato un filesystem virtuale, che non è associato a
+nessun file di dispositivo, il contenuto di \param{source} viene ignorato.
+
+L'argomento \param{data} viene usato per passare le impostazioni relative alle
+caratteristiche specifiche di ciascun filesystem. Si tratta di una stringa di
+parole chiave (separate da virgole e senza spazi) che indicano le cosiddette
+``\textsl{opzioni}'' del filesystem che devono essere impostate; in genere
+viene usato direttamente il contenuto del parametro dell'opzione \texttt{-o}
+del comando \texttt{mount}. I valori utilizzabili dipendono dal tipo di
+filesystem e ciascuno ha i suoi, pertanto si rimanda alla documentazione della
+pagina di manuale di questo comando e dei singoli filesystem.
+
+Dopo l'esecuzione della funzione il contenuto del filesystem viene reso
+disponibile nella directory specificata come \textit{mount point} ed il
+precedente contenuto di detta directory viene mascherato dal contenuto della
+directory radice del filesystem montato. Fino ai kernel della serie 2.2.x non
+era possibile montare un filesystem se un \textit{mount point} era già in uso,
+coi kernel successivi è possibile montare più filesystem sullo stesso
+\textit{mount point} impilandoli l'uno sull'altro, anche in questo caso vale
+quanto appena detto, e solo il contenuto dell'ultimo filesystem montato sarà
+visibile, mascherando quelli sottostanti.
+
+In realtà quella di montare un filesystem è solo una delle operazioni che si
+possono effettuare con \func{mount}, la funzione infatti è dedicata a tutte le
+operazioni relative alla gestione del montaggio dei filesystem e dei
+\textit{mount point}. Ad esempio fin dalle sue origini poteva essere
+utilizzata per effettuare il rimontaggio di un filesystem con opzioni diverse,
+ed a partire dal kernel 2.4.x è divenuto possibile usarla per spostare
+atomicamente un \textit{mount point} da una directory ad un'altra, per montare
+lo stesso filesystem in diversi \textit{mount point}, per montare una
+directory su un'altra (il cosiddetto \textit{bind mount}).
+
+\itindend{mount~point}
+
+Il tipo di operazione compiuto da \func{mount} viene stabilito in base al
+valore dell'argomento \param{mountflags}, che oltre alla selezione del tipo di
+operazione da compiere, consente anche di indicare alcune opzioni generiche
+valide per qualunque filesystem.\footnote{benché queste siano espresse nel
+ comando \cmd{mount} con l'opzione \texttt{-o} esse non vengono impostate nei
+ valori di \param{data}, che serve solo per le opzioni specifiche di ogni
+ filesystem.} Il valore dell'argomento deve essere espresso come maschera
+binaria e i vari bit che lo compongono, detti anche \textit{mount flags},
+devono essere impostati con un OR aritmetico dei valori dalle opportune
+costanti che illustreremo a breve.
+
+In Linux \param{mountflags} deve essere un intero a 32 bit;
+fino ai kernel della serie 2.2.x i 16 più significativi avevano un valore
+riservato che doveva essere specificato obbligatoriamente,\footnote{il valore
+ era il \textit{magic number} \code{0xC0ED}, si può usare la costante
+ \constd{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
+ al \textit{magic number}, mentre per specificarlo si può dare un OR
+ aritmetico con la costante \constd{MS\_MGC\_VAL}.} e si potevano usare solo
+i 16 meno significativi. Oggi invece, con un numero di opzioni superiore, sono
+utilizzati tutti e 32 i bit, ma qualora nei 16 più significativi sia presente
+detto valore, che non esprime una combinazione valida, esso viene ignorato.
+
+Come accennato il tipo di operazione eseguito da \func{mount} viene stabilito
+in base al contenuto di \param{mountflags}, la scelta viene effettuata
+controllando nell'ordine:
+\begin{enumerate*}
+\item se è presente il flag \const{MS\_REMOUNT}, nel qual caso verrà eseguito
+ il rimontaggio del filesystem, con le nuove opzioni indicate da \param{data}
+ e dagli altri flag di \param{mountflags};
+\item se è presente il flag \const{MS\_BIND}, nel qual caso verrà eseguito un
+ \textit{bind mount} (argomento che tratteremo più avanti);
+\item se è presente uno fra \const{MS\_SHARED}, \const{MS\_PRIVATE},
+ \const{MS\_SLAVE}, \const{MS\_UNBINDABLE}, nel qual caso verrà cambiata la
+ modalità di propagazione del montaggio (detti valori sono mutualmente
+ esclusivi).
+\item se è presente \const{MS\_MOVE}, nel qual caso verrà effettuato uno
+ spostamento del \textit{mount point};
+\item se nessuno dei precedenti è presente si tratta di una ordinaria
+ operazione di montaggio di un filesystem.
+\end{enumerate*}
+
+Il fatto che questi valori vengano controllati in quest'ordine significa che
+l'effetto di alcuni di questi flag possono cambiare se usati in combinazione
+con gli altri che vengono prima nella sequenza (è quanto avviene ad esempio
+per \const{MS\_BIND} usato con \const{MS\_REMOUNT}). Tratteremo questi
+\textit{mount flags} speciali per primi, nell'ordine appena illustrato,
+tornando sugli altri più avanti.
+
+Usando il flag \constd{MS\_REMOUNT} si richiede a \func{mount} di rimontare un
+filesystem già montato cambiandone le opzioni di montaggio in maniera atomica
+(non è cioè necessario smontare e rimontare il filesystem per effettuare il
+cambiamento). Questa operazione consente di modificare le opzioni del
+filesystem anche se questo è in uso. Gli argomenti \param{source} e
+\param{target} devono essere gli stessi usati per il montaggio originale,
+mentre sia \param{data} che \param{mountflags} conterranno le nuove opzioni,
+\param{filesystemtype} viene ignorato. Perché l'operazione abbia successo
+occorre comunque che il cambiamento sia possibile (ad esempio non sarà
+possibile rimontare in sola lettura un filesystem su cui sono aperti file per
+la lettura/scrittura).
+
+Qualunque opzione specifica del filesystem indicata con \param{data} può
+essere modificata (ma si dovranno rielencare tutte quelle volute), mentre con
+\param{mountflags} possono essere modificate solo alcune opzioni generiche:
+\const{MS\_LAZYTIME}, \const{MS\_MANDLOCK}, \const{MS\_NOATIME},
+\const{MS\_NODEV}, \const{MS\_NODIRATIME}, \const{MS\_NOEXEC},
+\const{MS\_NOSUID}, \const{MS\_RELATIME}, \const{MS\_RDONLY},
+\const{MS\_STRICTATIME} e \const{MS\_SYNCHRONOUS}. Inoltre dal kernel 3.17 il
+comportamento relativo alle opzioni che operano sui tempi di ultimo accesso
+dei file (vedi sez.~\ref{sec:file_file_times}) è cambiato e se non si è
+indicato nessuno dei vari \texttt{MS\_*ATIME} vengono mantenute le
+impostazioni esistenti anziché forzare l'uso di \const{MS\_RELATIME}.
+
+\itindbeg{bind~mount}
+
+Usando il flag \constd{MS\_BIND} si richiede a \func{mount} di effettuare un
+cosiddetto \textit{bind mount}, l'operazione che consente di montare una
+directory di un filesystem in un'altra directory. L'opzione è disponibile a
+partire dai kernel della serie 2.4. In questo caso verranno presi in
+considerazione solo gli argomenti \param{source}, che stavolta indicherà la
+directory che si vuole montare e non un file di dispositivo, e \param{target}
+che indicherà la directory su cui verrà effettuato il \textit{bind mount}. Gli
+argomenti \param{filesystemtype} e \param{data} vengono ignorati.
+
+Quello che avviene con questa operazione è che in corrispondenza del
+\textit{pathname} indicato da \param{target} viene montato l'\textit{inode} di
+\param{source}, così che la porzione di albero dei file presente sotto
+\param{source} diventi visibile allo stesso modo sotto
+\param{target}. Trattandosi esattamente dei dati dello stesso filesystem, ogni
+modifica fatta in uno qualunque dei due rami di albero sarà visibile
+nell'altro, visto che entrambi faranno riferimento agli stessi \textit{inode}.
+
+Dal punto di vista del VFS l'operazione è analoga al montaggio di un
+filesystem proprio nel fatto che anche in questo caso si inserisce in
+corrispondenza della \textit{dentry} di \texttt{target} un diverso
+\textit{inode}, che stavolta, invece di essere quello della radice del
+filesystem indicato da un file di dispositivo, è quello di una directory già
+montata.
+
+Si tenga presente che proprio per questo sotto \param{target} comparirà il
+contenuto che è presente sotto \param{source} all'interno del filesystem in
+cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla porzione
+di albero che sta sotto \param{source} qualora in una sottodirectory di
+quest'ultima si fosse effettuato un altro montaggio. In tal caso infatti nella
+porzione di albero sotto \param{source} si troverebbe il contenuto del nuovo
+filesystem (o di un altro \textit{bind mount}) mentre sotto \param{target} ci
+sarebbe il contenuto presente nel filesystem originale.
+
+L'unico altro \textit{mount flag} usabile direttamente con \const{MS\_BIND} è
+\const{MS\_REC} che consente di eseguire una operazione di \textit{bind mount}
+ricorsiva, in cui sotto \param{target} vengono montati ricorsivamente anche
+tutti gli eventuali ulteriori \textit{bind mount} già presenti sotto
+\param{source}.
+
+E' però possibile, a partire dal kernel 2.6.26, usare questo flag insieme a
+\const{MS\_REMOUNT}, nel qual caso consente di effettuare una modifica delle
+opzioni di montaggio del \textit{bind mount} ed in particolare effettuare il
+cosiddetto \textit{read-only bind mount} in cui viene onorata anche la
+presenza aggiuntiva del flag \const{MS\_RDONLY}. In questo modo si ottiene che
+l'accesso ai file sotto \param{target} sia effettuabile esclusivamente in sola
+lettura, mantenendo il normale accesso in lettura/scrittura sotto
+\param{source}.
+
+Il supporto per il \textit{bind mount} consente di superare i limiti presenti
+per gli \textit{hard link} (di cui parleremo in
+sez.~\ref{sec:link_symlink_rename}) con la possibilità di fare riferimento
+alla porzione dell'albero dei file di un filesystem presente a partire da una
+certa directory utilizzando una qualunque altra directory, anche se questa sta
+su un filesystem diverso.\footnote{e non c'è neanche il problema di non esser
+ più in grado di cancellare un \textit{hard link} ad una directory sullo
+ stesso filesystem (vedi sez.~\ref{sec:link_symlink_rename}), per cui su
+ Linux questi non sono possibili, dato che in questo caso per la rimozione
+ del collegamento basta smontare \param{target}.} Si può così fornire una
+alternativa all'uso dei collegamenti simbolici (di cui parleremo in
+sez.~\ref{sec:link_symlink_rename}) che funziona correttamente anche
+all'intero di un \textit{chroot} (argomento su cui torneremo in
+sez.~\ref{sec:file_chroot}).
+
+\itindend{bind~mount}
+\itindbeg{shared~subtree}
+
+I quattro flag \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+\const{MS\_UNBINDABLE} sono stati introdotti a partire dal kernel 2.6.15 per
+realizzare l'infrastruttura dei cosiddetti \textit{shared subtree}, che
+estendono le funzionalità dei \textit{bind mount}. La funzionalità nasce
+dalle esigenze di poter utilizzare a pieno le funzionalità di isolamento
+fornite dal kernel per i processi (i \textit{namespace}, che tratteremo in
+sez.~\ref{sec:process_namespaces}) in particolare per quanto riguarda la
+possibilità di far avere ad un processo una visione ristretta dei filesystem
+montati (il \textit{mount namespace}), ma l'applicazione è comunque rilevante
+anche con un classico \textit{chroot} (vedi sez.~\ref{sec:file_chroot}).
+
+\itindbeg{submount}
+
+Abbiamo visto come nella modalità ordinaria in cui si esegue un
+\textit{bind mount} sotto \param{target} compaia lo stesso ramo di albero dei
+file presente sotto \param{source}, ma limitato a quanto presente nel
+filesystem di \param{source}; i risultati di un eventuale
+``\textit{submount}'' effettuato all'interno di \param{source} non saranno
+visibili. Ed anche se quelli presenti al momento dell'uso di \const{MS\_BIND}
+possono essere riottenuti usando \const{MS\_REC}, ogni eventuale
+``\textit{submount}'' successivo (che avvenga sotto \param{source} o sotto
+\param{target}) resterà ``\textsl{privato}'' al ramo di albero su cui è
+avvenuto.
+
+\itindend{submount}
+\itindbeg{mount peer group}
+
+Ci sono casi però in cui può risultare utile che eventuali
+``\textit{submount}'' siano visibili sui rami di albero presenti al di sotto
+di tutte le directory coinvolte in un \textit{bind mount}, anche se effettuati
+in un secondo tempo. Per poter ottenere questa funzionalità i
+\textit{bind mount} sono stati estesi introducendo i \textit{mount peer
+ group}, che consentono di raggrupparli in modo da poter inviare a ciascuno
+di essi tutti gli eventi relativi a montaggi o smontaggi effettuati al loro
+interno ed avere sempre una propagazione degli stessi che li renda coerenti.
+
+Quando si effettua un montaggio ordinario, o si esegue un \textit{bind mount},
+di default non viene utilizzato nessun \textit{mount peer group} ed il
+\textit{mount point} viene classificato come ``\textsl{privato}'', nel senso
+che abbiamo appena visto. Si può però marcare un \textit{mount point} come
+``\textsl{condiviso}'', ed in questo modo esso verrà associato ad un
+\textit{mount peer group} insieme a tutti gli altri ulteriori \textit{mount
+ point} per i quali sia stato eseguito un \textit{bind mount}. Questo fa sì
+che tutte le volte che si effettua un montaggio o uno smontaggio all'interno
+di uno qualunque dei \textit{mount point} del gruppo, questo venga propagato
+anche su tutti gli altri e sotto tutti sia visibile sempre lo stesso ramo di
+albero dei file.
+
+A completare l'infrastruttura degli \textit{shared subtree} sono state
+previste due ulteriori funzionalità: la prima è quella di marcare un
+\textit{mount point} come ``\textit{slave}'', in tal caso le operazioni di
+montaggio e smontaggio effettuate al suo interno non verranno più propagate
+agli altri membri del \textit{mount peer group} di cui fa parte, ma continuerà
+a ricevere quelle eseguite negli altri membri.
+
+La seconda funzionalità è quella di marcare un \textit{mount point} come
+``\textit{unbindable}''; questo anzitutto impedirà che possa essere usato come
+sorgente di un \textit{bind mount} ed inoltre lo renderà privato, con la
+conseguenza che quando è presente all'interno di altri \textit{bind mount},
+all'interno di questi si vedrà solo il contenuto originale e non quello
+risultante da eventuali ulteriori montaggi effettuati al suo interno.
+
+\itindend{mount peer group}
+
+I \textit{mount flag} che controllano le operazioni relative agli
+\textit{shared subtree} sono descritti nella lista seguente. Si ricordi che
+sono mutuamente esclusivi, e compatibili solo con l'uso degli ulteriori flag
+\const{MS\_REC} (che applica ricorsivamente l'operazione a tutti gli eventuali
+\textit{mount point} sottostanti) e \const{MS\_SILENT}; in tutti gli altri
+casi \func{mount} fallirà con un errore di \errval{EINVAL}. L'unico altro
+argomento che deve essere specificato quando li si usano è \param{target};
+\param{source}, \param{data} e \param{filesystem} sono ignorati.
+
+\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come \textit{private
+ mount}. Di default, finché non lo si marca altrimenti con una delle altre
+ opzioni dell'interfaccia, ogni \textit{mount point} è privato. Ogni
+ \textit{bind mount} ottenuto da un \textit{mount point} privato si comporta
+ come descritto nella trattazione di \const{MS\_BIND}. Si usa questo flag
+ principalmente per revocare gli effetti delle altre opzioni e riportare il
+ comportamento a quello ordinario.
+
+\item[\constd{MS\_SHARED}] Marca un \textit{mount point} come \textit{shared
+ mount}. Lo scopo dell'opzione è ottenere che tutti i successivi
+ \textit{bind mount} ottenuti da un \textit{mount point} così marcato siano
+ di tipo \textit{shared} e vengano inseriti nello stesso \textit{mount peer
+ group} in modo da ``\textsl{condividere}'' ogni ulteriore operazione di
+ montaggio o smontaggio. Con questa opzione le operazioni di montaggio e
+ smontaggio effettuate al di sotto di uno \textit{shared mount} vengono
+ automaticamente ``\textsl{propagate}'' a tutti gli altri membri del
+ \textit{mount peer group} di cui fa parte, in modo che la sezione di albero
+ dei file visibile al di sotto di ciascuno di essi sia sempre la stessa.
+
+\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
+ mount}. Se il \textit{mount point} è parte di un \textit{mount peer group}
+ esso diventerà di tipo \textit{slave}: le operazioni di montaggio e
+ smontaggio al suo interno non verranno più propagate agli altri membri del
+ gruppo, ma continuerà a ricevere quelle eseguite negli altri membri. Se non
+ esistono altri membri nel gruppo il \textit{mount point} diventerà privato,
+ negli altri casi non subirà nessun cambiamento.
+
+\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
+ \textit{unbindable mount}. Un \textit{mount point} marcato in questo modo
+ non può essere usato per un \textit{bind mount} del suo contenuto. Si
+ comporta cioè come allo stesso modo di un \textit{mount point} ordinario di
+ tipo \textit{private} con in più la restrizione che nessuna sua
+ sottodirectory (anche se relativa ad un ulteriore montaggio) possa essere
+ utilizzata come sorgente di un \textit{bind mount}.
+
+\end{basedescript}
+\itindend{shared~subtree}
+
+L'ultimo \textit{mount flag} che controlla una modalità operativa di
+\func{mount} è \constd{MS\_MOVE}, che consente di effettuare lo spostamento
+del \textit{mount point} di un filesystem. La directory del \textit{mount
+ point} originale deve essere indicata nell'argomento \param{source}, e la
+sua nuova posizione nell'argomento \param{target}. Tutti gli altri argomenti
+della funzione vengono ignorati.
+
+Lo spostamento avviene atomicamente, ed il ramo di albero presente sotto
+\param{source} sarà immediatamente visibile sotto \param{target}. Non esiste
+cioè nessun momento in cui il filesystem non risulti montato in una o
+nell'altra directory e pertanto è garantito che la risoluzione di
+\textit{pathname} relativi all'interno del filesystem non possa fallire.
+
+Elenchiamo infine i restanti \textit{mount flag}, il cui utilizzo non attiene
+alle operazioni di \func{mount}, ma soltanto l'impostazione di opzioni
+generiche relative al funzionamento di un filesystem e che vengono per lo più
+utilizzati solo in fase di montaggio:
+
+\begin{basedescript}{\desclabelwidth{2.0cm}\desclabelstyle{\nextlinelabel}}
+\item[\constd{MS\_DIRSYNC}] Richiede che ogni modifica al contenuto di una
+ directory venga immediatamente registrata su disco in maniera sincrona
+ (introdotta a partire dai kernel della serie 2.6). L'opzione si applica a
+ tutte le directory del filesystem, ma su alcuni filesystem è possibile
+ impostarla a livello di singole directory o per i sotto-rami di una directory
+ con il comando \cmd{chattr}.\footnote{questo avviene tramite delle opportune
+ \texttt{ioctl} (vedi sez.~\ref{sec:file_fcntl_ioctl}).}
+
+ Questo consente di ridurre al minimo il rischio di perdita dei dati delle
+ directory in caso di crollo improvviso del sistema, al costo di una certa
+ perdita di prestazioni dato che le funzioni di scrittura relative ad
+ operazioni sulle directory non saranno più bufferizzate e si bloccheranno
+ fino all'arrivo dei dati sul disco prima che un programma possa proseguire.
+
+\item[\constd{MS\_LAZYTIME}] Modifica la modalità di registrazione di tempi
+ dei file (vedi sez.~\ref{sec:file_file_times}) per ridurre al massimo gli
+ accessi a disco (particolarmente utile per i portatili). Attivandolo i tempi
+ dei file vengono mantenuti in memoria e vengono salvati su disco solo in
+ quattro casi: quando c'è da eseguire un aggiornamento dei dati
+ dell'\textit{inode} per altri motivi, se viene usata una delle funzioni di
+ sincronizzazione dei dati su disco (vedi sez.~\ref{sec:file_sync}), se
+ l'\textit{inode} viene rimosso dalla memoria, o se è passato un giorno
+ dall'ultima registrazione. Introdotto a partire dal kernel 4.0.
+
+ In questo modo si possono ridurre significativamente le scritture su disco
+ mantenendo tutte le informazioni riguardo ai tempi dei file, riducendo anche
+ l'impatto dell'uso di \const{MS\_STRICTATIME}. Il costo da pagare è il
+ rischio, in caso di crash del sistema, di avere dati vecchi fino a 24 ore
+ per quel che riguarda i tempi dei file.
+
+\item[\constd{MS\_MANDLOCK}] Consente l'uso del \textit{mandatory locking}
+ (vedi sez.~\ref{sec:file_mand_locking}) sui file del filesystem. Per poterlo
+ utilizzare effettivamente però esso dovrà essere comunque attivato
+ esplicitamente per i singoli file impostando i permessi come illustrato in
+ sez.~\ref{sec:file_mand_locking}.
+
+\item[\constd{MS\_NOATIME}] Viene disabilitato sul filesystem l'aggiornamento
+ dell'\textit{access time} (vedi sez.~\ref{sec:file_file_times}) per
+ qualunque tipo di file. Dato che l'aggiornamento dell'\textit{access time} è
+ una funzionalità la cui utilità è spesso irrilevante ma comporta un costo
+ elevato visto che una qualunque lettura comporta comunque una scrittura su
+ disco, questa opzione consente di disabilitarla completamente. La soluzione
+ può risultare troppo drastica dato che l'informazione viene comunque
+ utilizzata da alcuni programmi, per cui nello sviluppo del kernel sono state
+ introdotte altre opzioni che forniscono soluzioni più appropriate e meno
+ radicali.
+
+\item[\constd{MS\_NODEV}] Viene disabilitato sul filesystem l'accesso ai file
+ di dispositivo eventualmente presenti su di esso. L'opzione viene usata come
+ misura di precauzione per rendere inutile la presenza di eventuali file di
+ dispositivo su filesystem che non dovrebbero contenerne.\footnote{si ricordi
+ che le convenzioni del \textit{Linux Filesystem Hierarchy Standard}
+ richiedono che questi siano mantenuti esclusivamente sotto \texttt{/dev}.}
+
+ Viene utilizzata, assieme a \const{MS\_NOEXEC} e \const{MS\_NOSUID}, per
+ fornire un accesso più controllato a quei filesystem di cui gli utenti hanno
+ il controllo dei contenuti, in particolar modo quelli posti su dispositivi
+ rimuovibili. In questo modo si evitano alla radice possibili situazioni in
+ cui un utente malizioso inserisce su uno di questi filesystem dei file di
+ dispositivo con permessi ``opportunamente'' ampliati che gli consentirebbero
+ di accedere anche a risorse cui non dovrebbe.
+
+\item[\constd{MS\_NODIRATIME}] Viene disabilitato sul filesystem
+ l'aggiornamento dell'\textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}) ma soltanto per le directory. Costituisce
+ una alternativa per \const{MS\_NOATIME}, che elimina l'informazione per le
+ directory, che in pratica che non viene mai utilizzata, mantenendola per i
+ file in cui invece ha un impiego, sia pur limitato.
+
+\item[\constd{MS\_NOEXEC}] Viene disabilitata sul filesystem l'esecuzione di un
+ qualunque file eseguibile eventualmente presente su di esso. L'opzione viene
+ usata come misura di precauzione per rendere impossibile l'uso di programmi
+ posti su filesystem che non dovrebbero contenerne.
+
+ Anche in questo caso viene utilizzata per fornire un accesso più controllato
+ a quei filesystem di cui gli utenti hanno il controllo dei contenuti. Da
+ questo punto di vista l'opzione è meno importante delle analoghe
+ \const{MS\_NODEV} e \const{MS\_NOSUID} in quanto l'esecuzione di un
+ programma creato dall'utente pone un livello di rischio nettamente
+ inferiore, ed è in genere consentita per i file contenuti nella sua home
+ directory.\footnote{cosa che renderebbe superfluo l'attivazione di questa
+ opzione, il cui uso ha senso solo per ambienti molto controllati in cui si
+ vuole che gli utenti eseguano solo i programmi forniti
+ dall'amministratore.}
+
+\item[\constd{MS\_NOSUID}] Viene disabilitato sul filesystem l'effetto dei bit
+ dei permessi \acr{suid} e \acr{sgid} (vedi sez.~\ref{sec:file_special_perm})
+ eventualmente presenti sui file in esso contenuti. L'opzione viene usata
+ come misura di precauzione per rendere inefficace l'effetto di questi bit
+ per filesystem in cui non ci dovrebbero essere file dotati di questi
+ permessi.
+
+ Di nuovo viene utilizzata, analogamente a \const{MS\_NOEXEC} e
+ \const{MS\_NODEV}, per fornire un accesso più controllato a quei filesystem
+ di cui gli utenti hanno il controllo dei contenuti. In questo caso si evita
+ che un utente malizioso possa inserire su uno di questi filesystem un
+ eseguibile con il bit \acr{suid} attivo e di proprietà dell'amministratore o
+ di un altro utente, che gli consentirebbe di eseguirlo per conto di
+ quest'ultimo.
+
+\item[\constd{MS\_RDONLY}] Esegue il montaggio del filesystem in sola lettura,
+ non sarà possibile nessuna modifica ai suoi contenuti. Viene usato tutte le
+ volte che si deve accedere ai contenuti di un filesystem con la certezza che
+ questo non venga modificato (ad esempio per ispezionare un filesystem
+ corrotto). All'avvio di default il kernel monta la radice in questa
+ modalità. Si tenga presente che se non viene indicato il filesystem verrà
+ montato, o rimontato nel caso lo si usi con \const{MS\_REMOUNT}, in
+ lettura/scrittura; questo significa in sostanza che non esiste una opzione
+ separata per indicare il montaggio in lettura/scrittura.
+
+\item[\constd{MS\_REC}] Applica ricorsivamente a tutti i \textit{mount point}
+ presenti al di sotto del \textit{mount point} indicato gli effetti della
+ opzione degli \textit{shared subtree} associata. In questo caso l'argomento
+ \param{target} deve fare riferimento ad un \textit{mount point} e tutti gli
+ altri argomenti sono ignorati, ed il flag deve essere indicato con uno fra
+ \const{MS\_PRIVATE}, \const{MS\_SHARED}, \const{MS\_SLAVE} e
+ \const{MS\_UNBINDABLE}. Può anche essere usato con \const{MS\_BIND} per
+ richiedere il montaggio ricorsivo anche degli eventuali ulteriori
+ \textit{bind mount} presenti sotto \param{target}.
+
+\item[\constd{MS\_RELATIME}] Indica di effettuare l'aggiornamento
+ dell'\textit{access time} sul filesystem soltanto quando questo risulti
+ antecedente il valore corrente del \textit{modification time} o del
+ \textit{change time} (per i tempi dei file si veda
+ sez.~\ref{sec:file_file_times}). L'opzione è disponibile a partire dal
+ kernel 2.6.20, mentre dal 2.6.30 questo è diventato il comportamento di
+ default del sistema, che può essere riportato a quello tradizionale con
+ l'uso di \const{MS\_STRICTATIME}. Sempre dal 2.6.30 il comportamento è stato
+ anche modificato e l'\textit{access time} viene comunque aggiornato se è più
+ vecchio di un giorno.
+
+ L'opzione consente di evitare i problemi di prestazioni relativi
+ all'aggiornamento dell'\textit{access time} senza avere impatti negativi
+ riguardo le funzionalità, il comportamento adottato infatti consente di
+ rendere evidente che vi è stato un accesso dopo la scrittura, ed evitando al
+ contempo ulteriori operazioni su disco negli accessi successivi. In questo
+ modo l'informazione relativa al fatto che un file sia stato letto resta
+ disponibile, ed i programmi che ne fanno uso continuano a funzionare. Con
+ l'introduzione di questo comportamento l'uso delle alternative
+ \const{MS\_NOATIME} e \const{MS\_NODIRATIME} è sostanzialmente inutile.
+
+\item[\constd{MS\_SILENT}] Richiede la soppressione di alcuni messaggi di
+ avvertimento nei log del kernel (vedi sez.~\ref{sec:sess_daemon}). L'opzione
+ è presente a partire dal kernel 2.6.17 e sostituisce, utilizzando un nome
+ non fuorviante, la precedente \const{MS\_VERBOSE}, introdotta nel kernel
+ 2.6.12, che aveva lo stesso effetto.
+
+\item[\constd{MS\_STRICTATIME}] Ripristina il comportamento tradizionale per
+ cui l'\textit{access time} viene aggiornato ad ogni accesso al
+ file. L'opzione è disponibile solo a partire dal kernel 2.6.30 quando il
+ comportamento di default del kernel è diventato quello fornito da
+ \const{MS\_RELATIME}.
+
+\item[\constd{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona richiedendo che
+ ogni modifica al contenuto del filesystem venga immediatamente registrata su
+ disco. Lo stesso comportamento può essere ottenuto con il flag
+ \const{O\_SYNC} di \func{open} (vedi sez.~\ref{sec:file_open_close}).
+
+ Questa opzione consente di ridurre al minimo il rischio di perdita dei dati
+ in caso di crollo improvviso del sistema, al costo di una pesante perdita di
+ prestazioni dato che tutte le funzioni di scrittura non saranno più
+ bufferizzate e si bloccheranno fino all'arrivo dei dati sul disco. Per un
+ compromesso in cui questo comportamento avviene solo per le directory, ed ha
+ quindi una incidenza nettamente minore, si può usare \const{MS\_DIRSYNC}.
+
+\end{basedescript}
+
+% NOTE: per l'opzione \texttt{lazytime} introdotta con il kernel 4.0,
+% vedi http://lwn.net/Articles/621046/
+
+% NOTE per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE} e
+% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, in particolare
+% * http://lwn.net/Articles/159077/ e
+% * Documentation/filesystems/sharedsubtree.txt
+
+% TODO: (bassa priorità) non documentati ma presenti in sys/mount.h:
+% * MS_POSIXACL
+% * MS_KERNMOUNT
+% * MS_I_VERSION
+% * MS_ACTIVE
+% * MS_NOUSER
+
+
+Una volta che non si voglia più utilizzare un certo filesystem è possibile
+``\textsl{smontarlo}'' usando la funzione di sistema \funcd{umount}, il cui
+prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount(const char *target)}
+\fdesc{Smonta un filesystem.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EBUSY}] il filesystem è occupato.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point}.
+ \item[\errcode{EPERM}] il processo non ha i privilegi di
+ amministratore.\footnotemark
+ \end{errlist}
+ ed inoltre \errval{EFAULT}, \errval{ELOOP}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{ENOMEM} nel loro significato generico. }
+\end{funcproto}
+
+\footnotetext{più precisamente la capacità \const{CAP\_SYS\_ADMIN}, vedi
+ sez.~\ref{sec:proc_capabilities}.}
+
+La funzione prende il nome della directory su cui il filesystem è montato e
+non il file o il dispositivo che è stato montato,\footnote{questo è vero a
+ partire dal kernel 2.3.99-pre7, prima esistevano due chiamate separate e la
+ funzione poteva essere usata anche specificando il file di dispositivo.} in
+quanto a partire dai kernel della serie 2.4.x è possibile montare lo stesso
+dispositivo in più punti. Nel caso più di un filesystem sia stato montato
+sullo stesso \textit{mount point} viene smontato quello che è stato montato
+per ultimo. Si tenga presente che la funzione fallisce se il filesystem è
+``\textsl{occupato}'', cioè quando ci sono ancora dei file aperti sul
+filesystem, se questo contiene la directory di lavoro (vedi
+sez.~\ref{sec:file_work_dir}) di un qualunque processo o il \textit{mount
+ point} di un altro filesystem.
+
+Linux provvede inoltre una seconda funzione di sistema, \funcd{umount2}, che
+consente un maggior controllo delle operazioni, come forzare lo smontaggio di
+un filesystem anche quando questo risulti occupato; il suo prototipo è:
+
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount2(const char *target, int flags)}
+\fdesc{Smonta un filesystem.}
+}
+{La funzione ritorna $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{EAGAIN}] si è chiamata la funzione con \const{MNT\_EXPIRE}
+ ed il filesystem non era occupato.
+ \item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
+ processo, o contiene dei file aperti, o un altro \textit{mount point}.
+ \item[\errcode{EINVAL}] \param{target} non è un \textit{mount point} o si
+ è usato \const{MNT\_EXPIRE} con \const{MNT\_FORCE} o
+ \const{MNT\_DETACH} o si è specificato un flag non esistente.
+ \end{errlist}
+ e tutti gli altri valori visti per \func{umount} con lo stesso significato.}
+\end{funcproto}
+
+Il valore di \param{flags} è una maschera binaria dei flag che controllano le
+modalità di smontaggio, che deve essere specificato con un OR aritmetico delle
+costanti illustrate in tab.~\ref{tab:umount2_flags}. Specificando
+\constd{MNT\_FORCE} la funzione cercherà di liberare il filesystem anche se è
+occupato per via di una delle condizioni descritte in precedenza. A seconda
+del tipo di filesystem alcune (o tutte) possono essere superate, evitando
+l'errore di \errcode{EBUSY}. In tutti i casi prima dello smontaggio viene
+eseguita una sincronizzazione dei dati.
+
+\begin{table}[!htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{8cm}|}
+ \hline
+ \textbf{Costante} & \textbf{Descrizione}\\
+ \hline
+ \hline
+ \const{MNT\_FORCE} & Forza lo smontaggio del filesystem anche se questo è
+ occupato (presente dai kernel della serie 2.2).\\
+ \const{MNT\_DETACH} & Esegue uno smontaggio ``\textsl{pigro}'', in cui si
+ blocca l'accesso ma si aspetta che il filesystem si
+ liberi (presente dal kernel 2.4.11 e dalla
+ \acr{glibc} 2.11).\\
+ \const{MNT\_EXPIRE} & Se non occupato marca un \textit{mount point} come
+ ``\textsl{in scadenza}'' in modo che ad una
+ successiva chiamata senza utilizzo del filesystem
+ questo venga smontato (presente dal
+ kernel 2.6.8 e dalla \acr{glibc} 2.11).\\
+ \const{UMOUNT\_NOFOLLOW}& Non dereferenzia \param{target} se questo è un
+ collegamento simbolico (vedi
+ sez.~\ref{sec:link_symlink_rename}) evitando
+ problemi di sicurezza (presente dal kernel
+ 2.6.34).\\
+ \hline
+ \end{tabular}
+ \caption{Costanti che identificano i bit dell'argomento \param{flags}
+ della funzione \func{umount2}.}
+ \label{tab:umount2_flags}
+\end{table}
+
+Con l'opzione \constd{MNT\_DETACH} si richiede invece uno smontaggio
+``\textsl{pigro}'' (o \textit{lazy umount}) in cui il filesystem diventa
+inaccessibile per i nuovi processi subito dopo la chiamata della funzione, ma
+resta accessibile per quelli che lo hanno ancora in uso e non viene smontato
+fintanto che resta occupato.
+
+Con \constd{MNT\_EXPIRE}, che non può essere specificato insieme agli altri
+due, si marca il \textit{mount point} di un filesystem non occupato come
+``\textsl{in scadenza}'', in tal caso \func{umount2} ritorna con un errore di
+\errcode{EAGAIN}, mentre in caso di filesystem occupato si sarebbe ricevuto
+\errcode{EBUSY}. Una volta marcato, se nel frattempo non viene fatto nessun
+uso del filesystem, ad una successiva chiamata con \const{MNT\_EXPIRE} questo
+verrà smontato. Questo flag consente di realizzare un meccanismo che smonti
+automaticamente i filesystem che restano inutilizzati per un certo periodo di
+tempo.
+
+Infine il flag \constd{UMOUNT\_NOFOLLOW} non dereferenzia \param{target} se
+questo è un collegamento simbolico (vedi
+sez.~\ref{sec:link_symlink_rename}). Questa è una misura di sicurezza
+introdotta per evitare, per quei filesystem per il quale è prevista una
+gestione diretta da parte degli utenti, come quelli basati su \itindex{FUSE}
+FUSE,\footnote{il \textit{Filesystem in USEr space} (FUSE) è una delle più
+ interessanti applicazioni del VFS che consente, tramite un opportuno modulo,
+ di implementarne le funzioni in \textit{user space}, così da rendere
+ possibile l'implementazione di un qualunque filesystem (con applicazioni di
+ grande interesse come il filesystem cifrato \textit{encfs} o il filesystem
+ di rete \textit{sshfs}) che possa essere usato direttamente per conto degli
+ utenti.} che si possano passare ai programmi che effettuano lo smontaggio
+dei filesystem, che in genere sono privilegiati ma consentono di agire solo
+sui propri \textit{mount point}, dei collegamenti simbolici che puntano ad
+altri \textit{mount point}, ottenendo così la possibilità di smontare
+qualunque filesystem.
+
+
+Altre due funzioni di sistema specifiche di Linux,\footnote{esse si trovano
+ anche su BSD, ma con una struttura diversa.} utili per ottenere in maniera
+diretta informazioni riguardo al filesystem su cui si trova un certo file,
+sono \funcd{statfs} e \funcd{fstatfs}, i cui prototipi sono:
+
+\begin{funcproto}{
+\fhead{sys/vfs.h}
+\fdecl{int statfs(const char *path, struct statfs *buf)}
+\fdecl{int fstatfs(int fd, struct statfs *buf)}
+\fdesc{Restituiscono informazioni relative ad un filesystem.}
+}
+{Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore,
+ nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
+ \item[\errcode{ENOSYS}] il filesystem su cui si trova il file specificato
+ non supporta la funzione.
+ \end{errlist} ed inoltre \errval{EFAULT} ed \errval{EIO} per entrambe,
+ \errval{EBADF} per \func{fstatfs}, \errval{ENOTDIR}, \errval{ENAMETOOLONG},
+ \errval{ENOENT}, \errval{EACCES}, \errval{ELOOP} per \func{statfs} nel loro
+ significato generico.}
+\end{funcproto}
+
+Queste funzioni permettono di ottenere una serie di informazioni generali
+riguardo al filesystem su cui si trova il file specificato con un
+\textit{pathname} per \func{statfs} e con un file descriptor (vedi
+sez.~\ref{sec:file_fd}) per \func{statfs}. Le informazioni vengono restituite
+all'indirizzo \param{buf} di una struttura \struct{statfs} definita come in
+fig.~\ref{fig:sys_statfs}, ed i campi che sono indefiniti per il filesystem in
+esame sono impostati a zero. I valori del campo \var{f\_type} sono definiti
+per i vari filesystem nei relativi file di header dei sorgenti del kernel da
+costanti del tipo \var{XXX\_SUPER\_MAGIC}, dove \var{XXX} in genere è il nome
+del filesystem stesso.
+
+\begin{figure}[!htb]
+ \footnotesize \centering
+ \begin{minipage}[c]{0.8\textwidth}
+ \includestruct{listati/statfs.h}
+ \end{minipage}
+ \normalsize
+ \caption{La struttura \structd{statfs}.}
+ \label{fig:sys_statfs}
+\end{figure}
+
+\conffilebeg{/etc/mtab}
+
+La \acr{glibc} provvede infine una serie di funzioni per la gestione dei due
+file \conffiled{/etc/fstab}\footnote{più precisamente \funcm{setfsent},
+ \funcm{getfsent}, \funcm{getfsfile}, \funcm{getfsspec}, \funcm{endfsent}.}
+ed \conffile{/etc/mtab}\footnote{più precisamente \funcm{setmntent},
+ \funcm{getmntent},\funcm{getmntent\_r}, \funcm{addmntent},\funcm{endmntent},
+ \funcm{hasmntopt}.} che convenzionalmente sono usati in quasi tutti i
+sistemi unix-like per mantenere rispettivamente le informazioni riguardo ai
+filesystem da montare e a quelli correntemente montati. Le funzioni servono a
+leggere il contenuto di questi file in opportune strutture \structd{fstab} e
+\structd{mntent}, e, nel caso di \conffile{/etc/mtab}, per inserire e
+rimuovere le voci presenti nel file.
+
+In generale si dovrebbero usare queste funzioni, in particolare quelle
+relative a \conffile{/etc/mtab}, quando si debba scrivere un programma che
+effettua il montaggio di un filesystem. In realtà in questi casi è molto più
+semplice invocare direttamente il programma \cmd{mount}. Inoltre l'uso stesso
+di \conffile{/etc/mtab} è considerato una pratica obsoleta, in quanto se non
+aggiornato correttamente (cosa che è impossibile se la radice è montata in
+sola lettura) il suo contenuto diventa fuorviante.
+
+Per questo motivo il suo utilizzo viene deprecato ed in molti casi viene già
+oggi sostituito da un collegamento simbolico a \procfile{/proc/mounts}, che
+contiene una versione degli stessi contenuti (vale a dire l'elenco dei
+filesystem montati) generata direttamente dal kernel, e quindi sempre
+disponibile e sempre aggiornata. Per questo motivo tralasceremo la
+trattazione, di queste funzioni, rimandando al manuale della \acr{glibc}
+\cite{GlibcMan} per la documentazione completa.
+
+\conffileend{/etc/mtab}
+
+% TODO (bassa priorità) scrivere delle funzioni (getfsent e getmntent &C)
+% TODO (bassa priorità) documentare ? swapon e swapoff (man 2 ...)