+\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 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 resto
+disponibile nella directory specificata come \textit{mount point}, 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} (argometo che tratteremo più avanti);
+\item se è presente uno fra \const{MS\_SHARED}, \const{MS\_PRIVATE},
+ \const{MS\_SLAVE}, \const{MS\_UNBINDABLE} nel qual caso viene cambiata la
+ modalità di propagazione del montaggio (detti valori sono mutualmente
+ esclusivi).
+\item se è presente \const{MS\_MOVE}, nel qual caso viene 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, 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 filsystem per effettuare il
+cambiamento). In questo modo si possono 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 sul tempo di ultimo accesso
+(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.
+
+In sostanza quello che avviene è 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.\footnote{questo evita
+ anche il problema dei \textit{loop} di fig.~\ref{fig:file_link_loop}, dato
+ che se anche si montasse su \param{target} una directory in cui essa è
+ contenuta, il cerchio non potrebbe chiudersi perché ritornati a
+ \param{target} dentro il \textit{bind mount} vi si troverebbe solo il
+ contenuto originale e non si potrebbe tornare indietro.}
+
+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 nel nuovo \textit{mount point} vengono montati
+ricorsivamente anche tutti gli eventuali \textit{bind mount} presenti al di
+sotto della directory di origine.
+
+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, senza dover cambiare le opzione del \textit{mount-point} originale.
+
+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. 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} per rendere possibile
+propagare automaticamente o meno le eventuali operazioni di montaggio eseguite
+al di sotto di un \textit{bind mount} a tutti gli altri \textit{mount-point}
+
+
+consentendo di impostare le
+politiche di propagazione di ulteriori eventuali operazione di montaggio
+effettuate al di sotto di un \textit{bind-mount}.
+
+L'uso di uno di questi \textit{mount flag}, che si ricordi sono esclusivi fra
+loro, è compatibile solo con In tutti gli altri casi \func{mount} fallirà con
+un errore di \errval{EINVAL}.
+
+\begin{basedescript}{\desclabelwidth{1.9cm}\desclabelstyle{\nextlinelabel}}
+
+\item[\constd{MS\_PRIVATE}] Marca un \textit{mount point} come privato. In
+ questo caso \param{target} dovrà fare riferimento al \textit{mount point}
+ che si intende marcare, e tutti gli altri argomenti verranno ignorati.
+
+ Di default, finché non lo si marca altrimenti con una delle altre opzioni
+ dell'interfaccia come \textit{shared subtree}, ogni \textit{mount point} è
+ privato. Ogni \textit{bind mount} ottenuto da un \textit{mount point} di
+ tipo \textit{private} 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}. In questo caso \param{target} dovrà fare riferimento al
+ \textit{mount point} che si intende marcare, e tutti gli altri argomenti
+ verranno ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{shared}, cioè ``\textsl{condividano}'' con l'originale e fra di loro
+ ogni ulteriore operazione di montaggio o smontaggio che avviene su una
+ directory al di sotto di uno qualunque di essi. Le operazioni di montaggio e
+ smontaggio effettuate al di sotto di un qualunque \textit{mount point} così
+ marcato verranno ``\textsl{propagate}'' a tutti i \textit{mount point} della
+ stessa condivisione, e la sezione di albero di file vista al di sotto di
+ ciascuno di essi sarà sempre identica.
+
+\item[\constd{MS\_SLAVE}] Marca un \textit{mount point} come \textit{slave
+ mount}. In questo caso \param{target} dovrà fare riferimento al
+ \textit{mount point} che si intende marcare, e tutti gli altri argomenti
+ verranno ignorati.
+
+ Lo scopo dell'opzione è ottenere che tutti i successivi \textit{bind mount}
+ effettuati da un \textit{mount point} marcato da essa siano di tipo
+ \textit{slave}, cioè ``\textsl{condividano}'' ogni ulteriore operazione di
+ montaggio o smontaggio che avviene su una directory al di sotto del
+ \textit{mount point} originale. Le operazioni di montaggio e smontaggio in
+ questo caso vengono ``\textsl{propagate}'' soltanto dal \textit{mount point}
+ originale (detto anche \textit{master}) verso gli \textit{slave}, mentre
+ essi potranno eseguire al loro interno ulteriori montaggi che non saranno
+ propagati né negli altri né nel \textit{mount point} originale.
+
+\item[\constd{MS\_UNBINDABLE}] Marca un \textit{mount point} come
+ \textit{unbindable mount}. In questo caso \param{target} dovrà fare
+ riferimento al \textit{mount point} che si intende marcare, e tutti gli
+ altri argomenti verranno ignorati.
+
+ Un \textit{mount point} marcato in questo modo disabilita la capacità di
+ eseguire dei \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 per un
+ come sorgente di un \textit{bind mount}.