From fa441c81a71e74aaa4b81c2b4dd058bb46b3307a Mon Sep 17 00:00:00 2001 From: Simone Piccardi Date: Fri, 13 Jan 2012 18:22:47 +0000 Subject: [PATCH] Piccole correzioni --- filedir.tex | 72 +++++++++++++++++++++++++++++++++++------------------ intro.tex | 6 ++--- 2 files changed, 51 insertions(+), 27 deletions(-) diff --git a/filedir.tex b/filedir.tex index 999c5ee..e95c7af 100644 --- a/filedir.tex +++ b/filedir.tex @@ -661,9 +661,9 @@ il cui prototipo è:\footnote{la funzione è una versione specifica di Linux che significato generico.} \end{funcproto} -La funzione monta sulla directory indicata \param{target}, detta +La funzione monta sulla directory indicata da \param{target}, detta \itindex{mount~point} \textit{mount point}, il filesystem contenuto nel file -di dispositivo indicato \param{source}. In entrambi i casi, come daremo per +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 \itindex{pathname} @@ -713,14 +713,14 @@ qual caso vale comunque quanto detto in precedenza, e cioè che solo il contenuto dell'ultimo filesystem montato sarà visibile. 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 +forma della lista di parole chiave 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 +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 @@ -734,12 +734,13 @@ 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. + possibile 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 \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} @@ -776,22 +777,25 @@ riportati nell'elenco seguente: \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. + \const{MS\_RDONLY}. In questo modo si ottiene che l'accesso ai file sotto + \texttt{target} sia effettuabile esclusivamente 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}. - - + sez.~\ref{sec:file_link}) ottenendo un qualcosa di analogo in cui si può + 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 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} -\item[\const{MS\_DIRSYNC}] . +\item[\const{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). Questo significa che la + bufferizzazione effettuata dal \item[\const{MS\_MANDLOCK}] Consente il \textit{mandatory locking} \itindex{mandatory~locking} (vedi sez.~\ref{sec:file_mand_locking}). @@ -810,20 +814,40 @@ riportati nell'elenco seguente: \item[\const{MS\_NOSUID}] Ignora i bit \itindex{suid~bit} \acr{suid} e \itindex{sgid~bit} \acr{sgid}. +\item[\const{MS\_PRIVATE}] (non documentato). + \item[\const{MS\_RDONLY}] Monta in sola lettura. \item[\const{MS\_RELATIME}] . \item[\const{MS\_REMOUNT}] Rimonta il filesystem cambiando le opzioni. +\item[\const{MS\_SHARE}] Shared mount (non documentato). + \item[\const{MS\_SILENT}] . +\item[\const{MS\_SLAVE}] Slave mount (non documentato). + \item[\const{MS\_STRICTATIME}] . \item[\const{MS\_SYNCHRONOUS}] Abilita la scrittura sincrona. +\item[\const{MS\_UNBINDABLE}] (non documentato). + % TODO aggiornare con i nuovi flag di man mount -% verificare i readonly mount bind del 2.6.26 +% per \const{MS\_SLAVE},\const{MS\_SHARE}, \const{MS\_PRIVATE}, +% \const{MS\_UNBINDABLE} dal 2.6.15 vedi shared subtrees, +% http://lwn.net/Articles/159077/ e +% Documentation/filesystems/sharedsubtree.txt + +% TODO: non documentati ma presenti in sys/mount.h: +% MS_REC +% MS_POSIXACL +% MS_KERNMOUNT +% MS_I_VERSION +% MS_ACTIVE +% MS_NOUSER + \end{basedescript} La funzione \func{mount} può essere utilizzata anche per effettuare il diff --git a/intro.tex b/intro.tex index fcae631..2a34ea7 100644 --- a/intro.tex +++ b/intro.tex @@ -424,12 +424,12 @@ operazioni interne del kernel per la manipolazione sui file con le \textit{system call} relative alle operazioni di I/O, e gestisce poi l'organizzazione di dette operazioni nei vari modi in cui i diversi filesystem le effettuano, permettendo la coesistenza di filesystem differenti all'interno -dello stesso albero delle directory. Torneremo su questa interfaccia generica -fornita dal VFS in sez.~\ref{sec:file_vfs_work}. +dello stesso albero delle directory. Approfondiremo il funzionamento di +interfaccia generica fornita dal VFS in sez.~\ref{sec:file_vfs_work}. In sostanza quello che accade è che quando un processo esegue una \textit{system call} che opera su un file, il kernel chiama sempre una -funzione implementata nel VFS; la funzione eseguirà le manipolazioni sulle +funzione implementata nel VFS. La funzione eseguirà le manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle opportune funzioni del filesystem specifico a cui si fa riferimento. Saranno queste a chiamare le funzioni di più basso livello che eseguono le operazioni di I/O sul -- 2.30.2