\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}
\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.
+ 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 su questo 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.
-\subsection{I filesystem di uso comune}
+\itindend{inode}
+
+
+\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}, che nonostante il nome è stato il primo ad essere
+usato in maniera estensiva. 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
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 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.
+ \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}.
+
+In generale un filesystem è contenuto su un disco, e come illustrato in
+sez.~\ref{sec:file_vfs_work} l'operazione di montaggio corrisponde a rendere
+visibile il contenuto del suddetto disco, identificato attraverso il file di
+dispositivo ad esso associato, all'interno di una directory dell'albero dei
+file.
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
+sez.~\ref{sec:file_vfs_work} è 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 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 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 uno dei filesystem virtuali, 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 opzioni del
+filesytem 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}
\textit{mount point}, il precedente contenuto di detta directory viene
\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|r|p{8cm}|}
\hline
\textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\
\hline
% 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
%%% Local Variables:
%%% mode: latex
processo non è uscito e $-1$ per un errore, nel qual caso \var{errno}
assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
non è figlio del processo chiamante.
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
{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{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
- la funzione è stata interrotta da un segnale.
\item[\errcode{ECHILD}] il processo specificato da \param{pid} non esiste o
non è figlio del processo chiamante.
+ \item[\errcode{EINTR}] non è stata specificata l'opzione \const{WNOHANG} e
+ la funzione è stata interrotta da un segnale.
\item[\errcode{EINVAL}] si è specificato un valore non valido per
l'argomento \param{options}.
\end{errlist}}
eseguibili, o il file è su un filesystem montato con l'opzione
\cmd{noexec}, o manca il permesso di attraversamento di una delle
directory del pathname.
- \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
- \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene
- tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}.
+ \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
+ \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
+ interprete.
+ \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
+ riconoscibile.
\item[\errcode{ENOEXEC}] il file è in un formato non eseguibile o non
riconosciuto come tale, o compilato per un'altra architettura.
\item[\errcode{ENOENT}] il file o una delle librerie dinamiche o l'interprete
necessari per eseguirlo non esistono.
+ \item[\errcode{EPERM}] il file ha i bit \itindex{suid~bit} \acr{suid} o
+ \itindex{sgid~bit} \acr{sgid} e l'utente non è root, ed il processo viene
+ tracciato, oppure il filesystem è montato con l'opzione \cmd{nosuid}.
\item[\errcode{ETXTBSY}] l'eseguibile è aperto in scrittura da uno o più
processi.
- \item[\errcode{EINVAL}] l'eseguibile ELF ha più di un segmento
- \const{PF\_INTERP}, cioè chiede di essere eseguito da più di un
- interprete.
- \item[\errcode{ELIBBAD}] un interprete ELF non è in un formato
- riconoscibile.
\item[\errcode{E2BIG}] la lista degli argomenti è troppo grande.
\end{errlist}
- ed inoltre \errval{EFAULT}, \errval{ENOMEM},
- \errval{EIO}, \errval{ENAMETOOLONG}, \errval{ELOOP}, \errval{ENOTDIR},
- \errval{EISDIR}, \errval{ENFILE}, \errval{EMFILE} nel loro significato
- generico.
-}
+ ed inoltre \errval{EFAULT}, \errval{EIO}, \errval{EISDIR}, \errval{ELOOP},
+ \errval{EMFILE}, \errval{ENAMETOOLONG}, \errval{ENFILE}, \errval{ENOMEM},
+ \errval{ENOTDIR} nel loro significato generico. }
\end{funcproto}
La funzione \func{execve} esegue il programma o lo script indicato dal
caso \var{errno} assumerà uno dei valori:
\begin{errlist}
\item[\errcode{EFAULT}] \param{list} non ha un indirizzo valido.
-\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\item[\errcode{EINVAL}] il valore di \param{size} è maggiore del valore
massimo consentito di gruppi supplementari.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}}
\end{funcproto}
{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{ENOMEM}] non c'è memoria sufficiente per allocare lo spazio per
informazioni dei gruppi.
+\item[\errcode{EPERM}] il processo non ha i privilegi di amministratore.
\end{errlist}}
\end{funcproto}
{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{ESRCH}] non c'è nessun processo che corrisponda ai valori di
- \param{which} e \param{who}.
\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
+ \param{which} e \param{who}.
\end{errlist}}
\end{funcproto}
{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}] si è richiesto un aumento di priorità senza avere
+ sufficienti privilegi.
+\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
+ elencati in tab.~\ref{tab:proc_getpriority}.
+\item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
+ cercato di modificare la priorità di un processo di un altro utente.
\item[\errcode{ESRCH}] non c'è nessun processo che corrisponda ai valori di
\param{which} e \param{who}.
-\item[\errcode{EINVAL}] il valore di \param{which} non è uno di quelli
- elencati in tab.~\ref{tab:proc_getpriority}.
- \item[\errcode{EACCES}] si è richiesto un aumento di priorità senza avere
- sufficienti privilegi.
- \item[\errcode{EPERM}] un processo senza i privilegi di amministratore ha
- cercato di modificare la priorità di un processo di un altro utente.
\end{errlist}}
\end{funcproto}
{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{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{policy} non esiste o il
relativo valore di \param{p} non è valido per la politica scelta.
\item[\errcode{EPERM}] il processo non ha i privilegi per attivare la
politica richiesta.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
\fdecl{int sched\_getparam(pid\_t pid, struct sched\_param *param)}
\fdesc{Legge la priorità statica di un processo.}
}
-{La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
+{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{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{param} non ha senso per la
politica usata dal processo.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
l'operazione.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
{La funzione ritorna la politica di \textit{scheduling} in caso di successo e
$-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
\begin{errlist}
- \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EPERM}] non si hanno privilegi sufficienti per eseguire
l'operazione.
+ \item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}}
\end{funcproto}
{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{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] l'argomento \param{pid} non è valido.
\item[\errcode{ENOSYS}] la \textit{system call} non è presente (solo per
kernel arcaici).
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
{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{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] il valore di \param{mask} contiene riferimenti a
processori non esistenti nel sistema o a cui non è consentito l'accesso.
\item[\errcode{EPERM}] il processo non ha i privilegi sufficienti per
eseguire l'operazione.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
{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{ESRCH}] il processo \param{pid} non esiste.
\item[\errcode{EINVAL}] \param{setsize} è più piccolo delle dimensioni
della maschera di affinità usata dal kernel.
+\item[\errcode{ESRCH}] il processo \param{pid} non esiste.
\end{errlist}
ed inoltre anche \errval{EFAULT} nel suo significato generico.}
\end{funcproto}
successo e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei
valori:
\begin{errlist}
-\item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
\item[\errcode{EINVAL}] i valori di \param{which} o di \param{ioprio} non
sono validi.
\item[\errcode{EPERM}] non si hanno i privilegi per eseguire
l'impostazione (solo per \func{ioprio\_set}).
+\item[\errcode{ESRCH}] non esiste un processo corrispondente alle indicazioni.
\end{errlist}}
\end{funcproto}
projects / gapil.git / commitdiff