-Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
-attivate o meno, alcune di queste sono generali (anche se non è detto siano
-disponibili in ogni filesystem), e vengono specificate come opzioni di
-montaggio con l'argomento \param{mountflags}.
-
-In Linux \param{mountflags} deve essere un intero a 32 bit i cui 16 più
-significativi sono un \itindex{magic~number} \textit{magic
- number}\footnote{che nel caso è \code{0xC0ED}, si può usare la costante
- \const{MS\_MGC\_MSK} per ottenere la parte di \param{mountflags} riservata
- al \textit{magic number}.} mentre i 16 meno significativi sono usati per
-specificare le opzioni; essi sono usati come maschera binaria e vanno
-impostati con un OR aritmetico della costante \const{MS\_MGC\_VAL} con i
-valori riportati nell'elenco seguente:
-
-\begin{basedescript}{\desclabelstyle{\pushlabel}}
-
-\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in
- sostanza .
+Oltre alle opzioni specifiche di ciascun filesystem, che si passano nella
+forma delle opzioni indicata con l'argomento \param{data}, esistono pure
+alcune opzioni che si possono applicare in generale, anche se non è detto che
+tutti i filesystem le supportino, che si specificano tramite
+l'argomento \param{mountflags}. L'argomento inoltre può essere utilizzato per
+modificare il comportamento della funzione, facendole compiere una operazione
+diversa (ad esempio un rimontaggio, invece che un montaggio).
+
+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
+ \itindex{magic~number} \textit{magic number} \code{0xC0ED}, si può usare la
+ costante \const{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 \const{MS\_MGC\_VAL}.} oggi invece sono
+ignorati mentre i 16 meno significativi sono usati per specificare le opzioni
+come maschera binaria e vanno impostati con un OR aritmetico dei valori
+riportati nell'elenco seguente:
+
+\begin{basedescript}{\desclabelwidth{2.cm}\desclabelstyle{\nextlinelabel}}
+\itindbeg{bind~mount}
+\item[\const{MS\_BIND}] Effettua un cosiddetto \textit{bind mount}, in cui è
+ possibile montare una directory di un filesystem in un'altra directory. In
+ questo caso verranno presi in considerazione solo gli argomenti
+ \texttt{source}, che stavolta indicherà la directory che si vuole montare (e
+ non un file di dispositivo) e \texttt{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 \index{pathname}
+ \textit{pathname} indicato da \texttt{target} viene montato l'\textit{inode}
+ di \texttt{source}, così che la porzione di albero dei file presente sotto
+ \texttt{source} diventi visibile allo stesso modo sotto
+ \texttt{target}. Trattandosi esattamente di 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 \itindex{Virtual~File~System} VFS l'operazione è
+ analoga al montaggio di un filesystem proprio nel fatto che anche in questo
+ caso si inserisce in corripondenza 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 \texttt{target} comparirà il
+ contenuto che è presente sotto \texttt{source} all'interno del filesystem in
+ cui quest'ultima è contenuta. Questo potrebbe non corrispondere alla
+ porzione di albero che sta sotto \texttt{source} qualora in una
+ sottodirectory di quest'ultima si fosse effettuato un altro montaggio. In
+ tal caso infatti nella porzione di albero sotto \texttt{source} si
+ troverebbe il contenuto del nuovo filesystem (o di un altro \textit{bind
+ mount}) mentre sotto \texttt{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 \texttt{target} una directory in cui essa è contenuta, il
+ cerchio non potrebbe chiudersi perché ritornati a \texttt{target} dentro
+ il \textit{bind mount} vi si troverebbe solo il contenuto originale e non
+ si potrebbe tornare indietro.}
+
+ Fino al kernel 2.6.26 questo flag doveva essere usato da solo, in quanto il
+ \textit{bind mount} continuava ad utilizzare le stesse opzioni del montaggio
+ originale, dal 2.6.26 è stato introdotto il supporto per il cosiddetto
+ \textit{read-only bind mount} e viene onorata la presenza del flag
+ \const{MS\_RDONLY}. In questo modo si può far sì che l'accesso ai file sotto
+ \texttt{target} possa avvenire soltanto in sola lettura.
+
+ 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:file_link}) e di poter far comparire una qualunque porzione
+ dell'albero dei file all'interno di una qualunque directory, anche se questa
+ sta su un filesystem diverso, fornendo una alternativa all'uso dei link
+ simbolici (di cui parleremo in sez.~\ref{sec:file_symlink}) che funziona
+ correttamente anche all'intero di un \textit{chroot} (argomento su cui
+ torneremo in sez.~\ref{sec:file_chroot}.
+
+
+\itindend{bind~mount}
projects / gapil.git / blobdiff