\subsection{Il funzionamento del \textit{Virtual File System} di Linux}
\label{sec:file_vfs_work}
-% articolo interessante:
+% 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}
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
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
-difunzionamento.
+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
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}
+
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
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'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.
+\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}
della corrispondente \kstruct{file\_system\_type} inserisce la \textit{dentry}
\texttt{lookup} adatta per effettuare la risoluzione dei nomi per quel
filesystem.
+\itindend{pathname}
+
% 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
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]{\textwidth}
\end{figure}
Come si può notare dall'estratto di fig.~\ref{fig:kstruct_file}, la struttura
-contiene, oltre ad alcune informazioni usate dall'interfaccia dei file
-descriptor il cui significato emergerà più avanti, il puntatore \struct{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.
+\kstruct{file} contiene, oltre ad alcune informazioni usate dall'interfaccia
+dei file descriptor il cui significato emergerà più avanti, il puntatore
+\struct{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
\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
+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 una \code{seek}
-non è realizzabile per un dispositivo come la porta seriale o per una fifo,
-mentre sui file del filesystem \texttt{vfat} non sono disponibili i permessi,
-ma resta il fatto che grazie al VFS le \textit{system call} per le operazioni
-sui file restano sempre le stesse nonostante le enormi differenze che possono
-esserci negli oggetti a cui si applicano.
+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 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}
+% 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}
per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
torneremo in sez.~\ref{sec:file_ext2}.
+\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
-\itindex{inode} \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.
+\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
\begin{figure}[!htb]
\centering
- \includegraphics[width=14cm]{img/filesys_struct}
+ \includegraphics[width=12cm]{img/filesys_struct}
\caption{Strutturazione dei dati all'interno di un filesystem.}
\label{fig:file_filesys_detail}
\end{figure}
directory che tratteremo nel prosieguo del capitolo. In particolare è
opportuno tenere sempre presente che:
+
\begin{enumerate}
-\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni, i
- cosiddetti \textsl{metadati}, riguardanti il file: 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
- \itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da
- qui in poi chiameremo una \textsl{voce}, che abbiamo scelto come traduzione
- dell'inglese \textit{directory entry}, che non useremo anche per evitare
- confusione con le \textit{dentry} del kernel di cui si parlava in
- sez.~\ref{sec:file_vfs_work}.
+\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} si possono avere più
- voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
- contatore che contiene il numero di riferimenti che sono stati fatti ad esso
- (il cosiddetto \textit{link count}); solo quando questo contatore si annulla
- i dati del file vengono effettivamente rimossi dal disco. Per questo la
- funzione per cancellare un file si chiama \func{unlink} (vedi
- sez.~\ref{sec:file_link}), 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 \itindex{inode} nell'\textit{inode}.
+\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:file_link}), 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} nella voce si riferisce ad un
- \textit{inode} a questo numero e non ci può essere una directory che
- contiene riferimenti ad \itindex{inode} \textit{inode} relativi ad altri
- filesystem. Questo limita l'uso del comando \cmd{ln} (che crea una nuova
- voce per un file esistente con la funzione \func{link}) al filesystem
- corrente.
+ 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:file_link}) a file nel filesystem corrente.
-\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
+\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 \itindex{inode} l'\textit{inode} in questione e rimossa la
- vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
- attraverso la funzione \func{rename}, vedi
- sez.~\ref{sec:file_remove}). Questa operazione non modifica minimamente
- neanche l'\textit{inode} del file dato che non si opera su questo ma sulla
- directory che lo contiene.
-
-\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
+ 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:file_remove}). 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 sia esaurire lo spazio disco (caso più comune) che lo spazio per
- gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+ 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.
+ creare nuovi file, ma si potranno estendere quelli che ci
+ sono.\footnote{questo comportamento non è generale, alcuni filesystem
+ evoluti possono evitare il problema dell'esaurimento degli \textit{inode}
+ riallocando lo spazio disco libero per i blocchi.}
\end{enumerate}
-Infine si noti che, essendo file pure loro, il numero di riferimenti esiste
-anche per le directory; per cui, 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 in
-fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
-di \itindex{inode} inode.
-
\begin{figure}[!htb]
\centering
- \includegraphics[width=14cm]{img/dir_links}
+ \includegraphics[width=12cm]{img/dir_links}
\caption{Organizzazione dei \textit{link} per le directory.}
\label{fig:file_dirs_link}
\end{figure}
-La nuova directory avrà allora 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 ``\texttt{.}'' che
-è sempre inserita in ogni directory; questo vale 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}.
+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{I filesystem di uso comune}
+
+\subsection{Alcuni dettagli sul filesystem \textsl{ext2} e successori}
\label{sec:file_ext2}
-Il filesystem standard più usato con Linux è il cosiddetto \textit{third
- extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa
- riferimento al momento della stesura di questo paragrafo, l'inizio del
- 2010.} Esso nasce come evoluzione del precedente \textit{second extended
- filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche
-di base, per questo motivo parleremo anzitutto di questo, dato che molto di
-quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
-stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore
-evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta
-iniziando a sostituirlo gradualmente.
-
-Il filesystem \acr{ext2} nasce come filesystem nativo di 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 in sostanza le caratteristiche fondamentali.
+
+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 \acr{ext3}, probabilmente ancora il filesystem più
+diffuso, ed una serie di ulteriori miglioramento con il successivo \acr{ext4},
+che sta iniziando a sostituirlo gradualmente. 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
questi termini si veda sez.~\ref{sec:file_access_control}), nel qual caso
file e subdirectory ereditano sia il \acr{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).
+ 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 link simbolici veloci, in cui il nome del file
- non è salvato su un blocco, ma tenuto all'interno \itindex{inode} dell'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).
+ non è salvato su un blocco, ma tenuto all'interno \itindex{inode}
+ 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 file immutabili (che possono solo essere letti) per
la protezione di file di configurazione sensibili, o file
\textit{append-only} che possono essere aperti in scrittura solo per
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.\footnote{non si confonda questa definizione con
- quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa
- riferimento alla struttura usata in user space per riportare i dati
- contenuti in una directory generica, questa fa riferimento alla struttura
- usata dal kernel per un filesystem \acr{ext2}, definita nel file
- \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
- kernel.}
+in gruppi di blocchi.
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
-una maggiore affidabilità e possibilità di recupero in caso di corruzione del
-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 \itindex{inode} inode.
+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 \itindex{inode} inode.
\begin{figure}[!htb]
\centering
\includegraphics[width=9cm]{img/dir_struct}
- \caption{Struttura delle directory nel \textit{second extented filesystem}.}
+ \caption{Struttura delle directory nel \textit{second extended filesystem}.}
\label{fig:file_ext2_dirs}
\end{figure}
è 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 anche
-alcune modifiche strutturali, la principale di queste è quella che
-\textit{ext3} è un filesystem \textit{jounrnaled}, è 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}
+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
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 hash al posto delle \textit{linked list}, ottenendo un
-forte guadagno di prestazioni in caso di directory contenenti un gran numero
-di file.
+indicizzazione tramite 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 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)
-\subsection{La gestione dei filesystem}
+\subsection{La gestione dell'uso dei filesystem}
\label{sec:sys_file_config}
Come accennato in sez.~\ref{sec:file_arch_overview} per poter accedere ai file
occorre prima rendere disponibile al sistema il filesystem su cui essi sono
memorizzati; l'operazione di attivazione del filesystem è chiamata
-\textsl{montaggio}, per far questo in Linux\footnote{la funzione è specifica
- di Linux e non è portabile.} si usa la funzione \funcd{mount} il cui
-prototipo è:
-\begin{prototype}{sys/mount.h}
-{mount(const char *source, const char *target, const char *filesystemtype,
- unsigned long mountflags, const void *data)}
+\textsl{montaggio}, per far questo in Linux si usa la funzione \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.}
+}
-Monta il filesystem di tipo \param{filesystemtype} contenuto in \param{source}
-sulla directory \param{target}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso gli errori comuni a tutti i filesystem che possono
- essere restituiti in \var{errno} sono:
+{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{EPERM}] il processo non ha i privilegi di amministratore.
- \item[\errcode{ENODEV}] \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{EACCES}] non si ha il permesso di accesso su uno dei
+ componenti del \itindex{pathname} \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 read-only perché ci sono ancora file aperti in scrittura, o
- \param{target} è ancora in uso.
- \item[\errcode{EINVAL}] il device \param{source} presenta un
+ 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
\itindex{mount~point} \textit{mount point} o di spostarlo
quando \param{target} non è un \itindex{mount~point} \textit{mount point}
- o è \file{/}.
- \item[\errcode{EACCES}] non si ha il permesso di accesso su uno dei
- componenti del \itindex{pathname} \textit{pathname}, o si è cercato
- di montare un filesystem disponibile in sola lettura senza averlo
- specificato o il device \param{source} è su un filesystem montato con
- l'opzione \const{MS\_NODEV}.
- \item[\errcode{ENXIO}] il \itindex{major~number} \textit{major number} del
- device \param{source} è sbagliato.
+ o è la radice.
\item[\errcode{EMFILE}] la tabella dei device \textit{dummy} è piena.
- \end{errlist}
- ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
- \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
-\end{prototype}
-
-La funzione monta sulla directory \param{target}, detta \itindex{mount~point}
-\textit{mount point}, il filesystem contenuto in \param{source}. In generale
-un filesystem è contenuto su un disco, e l'operazione di montaggio corrisponde
-a rendere visibile al sistema il contenuto del suddetto disco, identificato
-attraverso il file di dispositivo ad esso associato.
-
-Ma la struttura del \textit{Virtual File System} vista in
-sez.~\ref{sec:file_vfs_work} è molto più 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 un filesystem, inoltre alcuni filesystem, come \file{proc} o
-\file{devfs} sono del tutto virtuali, i loro dati sono generati al volo ad
-ogni lettura, e passati al kernel ad ogni scrittura.
-
-Il tipo di filesystem è specificato da \param{filesystemtype}, che deve essere
-una delle stringhe riportate nel file \procfile{/proc/filesystems}, che
-contiene l'elenco dei filesystem supportati dal kernel; nel caso si sia
-indicato uno dei filesystem virtuali, il contenuto di \param{source} viene
-ignorato.
+ \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 \itindex{major~number} \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{ELOOP}, \errval{ENOMEM},
+ \errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ENOTDIR} nel loro
+ significato generico.}
+\end{funcproto}
+
+La funzione monta sulla directory indicata \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
+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}
+\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 invece sono generati al volo ad ogni lettura, e passati
+indietro al kernel ad ogni scrittura.\footnote{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 \procfile{/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
+opzioni del filesystem che devono essere impostate, in sostanza viene usato 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.
Dopo l'esecuzione della funzione il contenuto del filesystem viene resto
disponibile nella directory specificata come \itindex{mount~point}
\itindex{mount~point} \textit{mount point} da una directory ad un'altra, sia
montare in diversi \itindex{mount~point} \textit{mount point} lo stesso
filesystem, sia montare più filesystem sullo stesso \itindex{mount~point}
-\textit{mount point} (nel qual caso vale quanto appena detto, e solo il
-contenuto dell'ultimo filesystem montato sarà visibile).
+\textit{mount point}, nel qual caso vale quanto appena detto, e solo il
+contenuto dell'ultimo filesystem montato sarà visibile.
Ciascun filesystem è dotato di caratteristiche specifiche che possono essere
attivate o meno, alcune di queste sono generali (anche se non è detto siano
\begin{table}[htb]
\footnotesize
\centering
- \begin{tabular}[c]{|l|r|l|}
+ \begin{tabular}[c]{|l|p{8cm}|}
\hline
- \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\
+ \textbf{Parametro} & \textbf{Significato}\\
\hline
\hline
- \const{MS\_RDONLY} & 1 & Monta in sola lettura.\\
- \const{MS\_NOSUID} & 2 & Ignora i bit \itindex{suid~bit} \acr{suid} e
- \itindex{sgid~bit} \acr{sgid}.\\
- \const{MS\_NODEV} & 4 & Impedisce l'accesso ai file di dispositivo.\\
- \const{MS\_NOEXEC} & 8 & Impedisce di eseguire programmi.\\
- \const{MS\_SYNCHRONOUS}& 16 & Abilita la scrittura sincrona.\\
- \const{MS\_REMOUNT} & 32 & Rimonta il filesystem cambiando le opzioni.\\
- \const{MS\_MANDLOCK} & 64 & Consente il \textit{mandatory locking}
- \itindex{mandatory~locking} (vedi
- sez.~\ref{sec:file_mand_locking}).\\
- \const{S\_WRITE} & 128 & Scrive normalmente.\\
- \const{S\_APPEND} & 256 & Consente la scrittura solo in
- \itindex{append~mode} \textit{append mode}
- (vedi sez.~\ref{sec:file_sharing}).\\
- \const{S\_IMMUTABLE} & 512 & Impedisce che si possano modificare i file.\\
- \const{MS\_NOATIME} &1024 & Non aggiorna gli \textit{access time} (vedi
- sez.~\ref{sec:file_file_times}).\\
- \const{MS\_NODIRATIME}&2048 & Non aggiorna gli \textit{access time} delle
- directory.\\
- \const{MS\_BIND} &4096 & Monta il filesystem altrove.\\
- \const{MS\_MOVE} &8192 & Sposta atomicamente il punto di montaggio.\\
+ \const{MS\_BIND} & Monta il filesystem altrove.\\
+ \const{MS\_DIRSYNC} & .\\
+ \const{MS\_MANDLOCK} & Consente il \textit{mandatory locking}
+ \itindex{mandatory~locking} (vedi
+ sez.~\ref{sec:file_mand_locking}).\\
+ \const{MS\_MOVE} & Sposta atomicamente il punto di montaggio.\\
+ \const{MS\_NOATIME} & Non aggiorna gli \textit{access time} (vedi
+ sez.~\ref{sec:file_file_times}).\\
+ \const{MS\_NODEV} & Impedisce l'accesso ai file di dispositivo.\\
+ \const{MS\_NODIRATIME} & Non aggiorna gli \textit{access time} delle
+ directory.\\
+ \const{MS\_NOEXEC} & Impedisce di eseguire programmi.\\
+ \const{MS\_NOSUID} & Ignora i bit \itindex{suid~bit} \acr{suid} e
+ \itindex{sgid~bit} \acr{sgid}.\\
+ \const{MS\_RDONLY} & Monta in sola lettura.\\
+ \const{MS\_RELATIME} & .\\
+ \const{MS\_REMOUNT} & Rimonta il filesystem cambiando le opzioni.\\
+ \const{MS\_SILENT} & .\\
+ \const{MS\_STRICTATIME}& .\\
+ \const{MS\_SYNCHRONOUS}& Abilita la scrittura sincrona.\\
+ % \const{S\_WRITE} & Scrive normalmente.\\
+ % \const{S\_APPEND} & Consente la scrittura solo in
+ % \itindex{append~mode} \textit{append mode}
+ % (vedi sez.~\ref{sec:file_sharing}).\\
+ % \const{S\_IMMUTABLE} & Impedisce che si possano modificare i file.\\
\hline
\end{tabular}
\caption{Tabella dei codici dei flag di montaggio di un filesystem.}
\end{table}
% TODO aggiornare con i nuovi flag di man mount
-% gli S_* non esistono più come segnalato da Alessio...
% verificare i readonly mount bind del 2.6.26
-Per l'impostazione delle caratteristiche particolari di ciascun filesystem si
-usa invece l'argomento \param{data} che serve per passare le ulteriori
-informazioni necessarie, che ovviamente variano da filesystem a filesystem.
-
La funzione \func{mount} può essere utilizzata anche per effettuare il
\textsl{rimontaggio} di un filesystem, cosa che permette di cambiarne al volo
alcune delle caratteristiche di funzionamento (ad esempio passare da sola
Una volta che non si voglia più utilizzare un certo filesystem è possibile
\textsl{smontarlo} usando la funzione \funcd{umount}, il cui prototipo è:
-\begin{prototype}{sys/mount.h}{umount(const char *target)}
-
- Smonta il filesystem montato sulla directory \param{target}.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e -1 in caso di
- fallimento, nel qual caso \var{errno} assumerà uno dei valori:
+
+\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{EPERM}] il processo non ha i privilegi di amministratore.
\item[\errcode{EBUSY}] \param{target} è la directory di lavoro di qualche
processo, o contiene dei file aperti, o un altro mount point.
- \end{errlist}
- ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
- \errval{ENAMETOOLONG}, \errval{ENOENT} o \errval{ELOOP}.}
-\end{prototype}
-\noindent 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 con il kernel 2.4.x è possibile montare lo stesso
-dispositivo in più punti. Nel caso più di un filesystem sia stato montato
-sullo stesso \itindex{mount~point} \textit{mount point} viene smontato quello
-che è stato montato per ultimo.
+\end{errlist}ed inoltre \errval{ENOTDIR}, \errval{EFAULT}, \errval{ENOMEM},
+\errval{ENAMETOOLONG}, \errval{ENOENT}, \errval{ELOOP} nel loro
+ significato generico.}
+\end{funcproto}
+
+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 con il kernel 2.4.x è possibile montare lo stesso dispositivo in più
+punti. Nel caso più di un filesystem sia stato montato sullo stesso
+\itindex{mount~point} \textit{mount point} viene smontato quello che è stato
+montato per ultimo.
Si tenga presente che la funzione fallisce quando il filesystem è
\textsl{occupato}, questo avviene quando ci sono ancora file aperti sul
Linux provvede inoltre una seconda funzione, \funcd{umount2}, che in alcuni
casi permette di forzare lo smontaggio di un filesystem, anche quando questo
risulti occupato; il suo prototipo è:
-\begin{prototype}{sys/mount.h}{umount2(const char *target, int flags)}
-
- La funzione è identica a \func{umount} per comportamento e codici di errore,
- ma con \param{flags} si può specificare se forzare lo smontaggio.
-\end{prototype}
+\begin{funcproto}{
+\fhead{sys/mount.h}
+\fdecl{umount2(const char *target, int flags)}
+\fdesc{Smonta un filesystem.}
+}
+{La funzione è identica a \func{umount} per valori di ritorno e codici di
+ errore. }
+\end{funcproto}
Il valore di \param{flags} è una maschera binaria, e al momento l'unico valore
definito è il bit \const{MNT\_FORCE}; gli altri bit devono essere nulli.
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{functions}
- \headdecl{sys/vfs.h}
- \funcdecl{int statfs(const char *path, struct statfs *buf)}
- \funcdecl{int fstatfs(int fd, struct statfs *buf)}
-
- Restituisce in \param{buf} le informazioni relative al filesystem su cui è
- posto il file specificato.
-
- \bodydesc{Le funzioni ritornano 0 in caso di successo e -1 in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
+\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}
- e \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}.}
-\end{functions}
+ \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; queste vengono
% LocalWords: forced allowed sendmail SYSLOG WAKE ALARM CLOCK BOOTTIME dqstats
% LocalWords: REALTIME securebits GETSTATS QFMT curspace curinodes btime itime
% LocalWords: QIF BLIMITS bhardlimit bsoftlimit ILIMITS ihardlimit isoftlimit
-% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace
+% LocalWords: INODES LIMITS USAGE valid dqi IIF BGRACE bgrace IGRACE igrace is
% LocalWords: Python Truelite Srl quotamodule Repository who nell' dall' KEEP
% LocalWords: SECURE KEEPCAPS prctl FIXUP NOROOT LOCKED dell'IPC dell'I IOPRIO
-% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS
+% LocalWords: CAPBSET CLASS IDLE dcookie overflow DIFFERS Virtual everything
+% LocalWords: dentry register resolution cache dcache operation llseek poll
+% LocalWords: multiplexing fsync fasync seek block superblock gapil tex img
+% LocalWords: second linked journaled source filesystemtype unsigned device
+% LocalWords: mountflags NODEV ENXIO dummy devfs magic MGC RDONLY NOSUID MOVE
+% LocalWords: NOEXEC SYNCHRONOUS REMOUNT MANDLOCK NODIRATIME umount MNT statfs
+% LocalWords: fstatfs fstab mntent ino bound orig new setpcap metadati sysfs
%%% Local Variables:
%%% mode: latex