%% license is included in the section entitled "GNU Free Documentation
%% License".
%%
-
\chapter{La gestione avanzata dei file}
\label{cha:file_advanced}
+
In questo capitolo affronteremo le tematiche relative alla gestione avanzata
dei file. Inizieremo con la trattazione delle problematiche del \textit{file
locking} e poi prenderemo in esame le varie funzionalità avanzate che
contemporaneamente sullo stesso file non è possibile determinare la sequenza
in cui essi opereranno.
-Questo causa la possibilità di una \itindex{race~condition} \textit{race
- condition}; in generale le situazioni più comuni sono due: l'interazione fra
-un processo che scrive e altri che leggono, in cui questi ultimi possono
-leggere informazioni scritte solo in maniera parziale o incompleta; o quella
-in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro
-output sul file.
+Questo causa la possibilità di una \textit{race condition}; in generale le
+situazioni più comuni sono due: l'interazione fra un processo che scrive e
+altri che leggono, in cui questi ultimi possono leggere informazioni scritte
+solo in maniera parziale o incompleta; o quella in cui diversi processi
+scrivono, mescolando in maniera imprevedibile il loro output sul file.
In tutti questi casi il \textit{file locking} è la tecnica che permette di
-evitare le \itindex{race~condition} \textit{race condition}, attraverso una
-serie di funzioni che permettono di bloccare l'accesso al file da parte di
-altri processi, così da evitare le sovrapposizioni, e garantire la atomicità
-delle operazioni di lettura o scrittura.
+evitare le \textit{race condition}, attraverso una serie di funzioni che
+permettono di bloccare l'accesso al file da parte di altri processi, così da
+evitare le sovrapposizioni, e garantire la atomicità delle operazioni di
+lettura o scrittura.
\subsection{L'\textit{advisory locking}}
fondamentale da capire è che un \textit{file lock}, qualunque sia
l'interfaccia che si usa, anche se richiesto attraverso un file descriptor,
agisce sempre su di un file; perciò le informazioni relative agli eventuali
-\textit{file lock} sono mantenute dal kernel a livello di \itindex{inode}
-\textit{inode}, dato che questo è l'unico riferimento in comune che possono
-avere due processi diversi che aprono lo stesso file.
+\textit{file lock} sono mantenute dal kernel a livello di \textit{inode}, dato
+che questo è l'unico riferimento in comune che possono avere due processi
+diversi che aprono lo stesso file.
In particolare, come accennato in fig.~\ref{fig:file_flock_struct}, i
-\textit{file lock} sono mantenuti in una \itindex{linked~list} \textit{linked
- list} di strutture \kstruct{file\_lock}. La lista è referenziata
-dall'indirizzo di partenza mantenuto dal campo \var{i\_flock} della struttura
-\kstruct{inode} (per le definizioni esatte si faccia riferimento al file
-\file{include/linux/fs.h} nei sorgenti del kernel). Un bit del campo
-\var{fl\_flags} di specifica se si tratta di un lock in semantica BSD
-(\const{FL\_FLOCK}) o POSIX (\const{FL\_POSIX}) o un \textit{file lease}
-(\const{FL\_LEASE}, vedi sez.~\ref{sec:file_asyncronous_lease}).
+\textit{file lock} sono mantenuti in una \textit{linked list} di strutture
+\kstruct{file\_lock}. La lista è referenziata dall'indirizzo di partenza
+mantenuto dal campo \var{i\_flock} della struttura \kstruct{inode} (per le
+definizioni esatte si faccia riferimento al file \file{include/linux/fs.h} nei
+sorgenti del kernel). Un bit del campo \var{fl\_flags} di specifica se si
+tratta di un lock in semantica BSD (\const{FL\_FLOCK}) o POSIX
+(\const{FL\_POSIX}) o un \textit{file lease} (\const{FL\_LEASE}, vedi
+sez.~\ref{sec:file_asyncronous_lease}).
\begin{figure}[!htb]
\centering
ulteriori istanze di un \textit{file lock} quanto piuttosto degli ulteriori
riferimenti allo stesso. Questo viene realizzato dal kernel secondo lo schema
di fig.~\ref{fig:file_flock_struct}, associando ad ogni nuovo \textit{file
- lock} un puntatore alla voce nella \itindex{file~table} \textit{file table}
-da cui si è richiesto il blocco, che così ne identifica il titolare. Il
-puntatore è mantenuto nel campo \var{fl\_file} di \kstruct{file\_lock}, e
-viene utilizzato solo per i \textit{file lock} creati con la semantica BSD.
+ lock} un puntatore alla voce nella \textit{file table} da cui si è richiesto
+il blocco, che così ne identifica il titolare. Il puntatore è mantenuto nel
+campo \var{fl\_file} di \kstruct{file\_lock}, e viene utilizzato solo per i
+\textit{file lock} creati con la semantica BSD.
Questa struttura prevede che, quando si richiede la rimozione di un
\textit{file lock}, il kernel acconsenta solo se la richiesta proviene da un
-file descriptor che fa riferimento ad una voce nella \itindex{file~table}
-\textit{file table} corrispondente a quella registrata nel blocco. Allora se
-ricordiamo quanto visto in sez.~\ref{sec:file_dup} e
-sez.~\ref{sec:file_shared_access}, e cioè che i file descriptor duplicati e
-quelli ereditati in un processo figlio puntano sempre alla stessa voce nella
-\itindex{file~table} \textit{file table}, si può capire immediatamente quali
-sono le conseguenze nei confronti delle funzioni \func{dup} e \func{fork}.
+file descriptor che fa riferimento ad una voce nella \textit{file table}
+corrispondente a quella registrata nel blocco. Allora se ricordiamo quanto
+visto in sez.~\ref{sec:file_dup} e sez.~\ref{sec:file_shared_access}, e cioè
+che i file descriptor duplicati e quelli ereditati in un processo figlio
+puntano sempre alla stessa voce nella \textit{file table}, si può capire
+immediatamente quali sono le conseguenze nei confronti delle funzioni
+\func{dup} e \func{fork}.
Sarà così possibile rimuovere un \textit{file lock} attraverso uno qualunque
-dei file descriptor che fanno riferimento alla stessa voce nella
-\itindex{file~table} \textit{file table}, anche se questo è diverso da quello
-con cui lo si è creato,\footnote{attenzione, questo non vale se il file
- descriptor fa riferimento allo stesso file, ma attraverso una voce diversa
- della \itindex{file~table} \textit{file table}, come accade tutte le volte
- che si apre più volte lo stesso file.} o se si esegue la rimozione in un
-processo figlio. Inoltre una volta tolto un \textit{file lock} su un file, la
-rimozione avrà effetto su tutti i file descriptor che condividono la stessa
-voce nella \itindex{file~table} \textit{file table}, e quindi, nel caso di
-file descriptor ereditati attraverso una \func{fork}, anche per processi
-diversi.
+dei file descriptor che fanno riferimento alla stessa voce nella \textit{file
+ table}, anche se questo è diverso da quello con cui lo si è
+creato,\footnote{attenzione, questo non vale se il file descriptor fa
+ riferimento allo stesso file, ma attraverso una voce diversa della
+ \textit{file table}, come accade tutte le volte che si apre più volte lo
+ stesso file.} o se si esegue la rimozione in un processo figlio. Inoltre una
+volta tolto un \textit{file lock} su un file, la rimozione avrà effetto su
+tutti i file descriptor che condividono la stessa voce nella \textit{file
+ table}, e quindi, nel caso di file descriptor ereditati attraverso una
+\func{fork}, anche per processi diversi.
Infine, per evitare che la terminazione imprevista di un processo lasci attivi
dei \textit{file lock}, quando un file viene chiuso il kernel provvede anche a
rimuovere tutti i blocchi ad esso associati. Anche in questo caso occorre
tenere presente cosa succede quando si hanno file descriptor duplicati; in tal
caso infatti il file non verrà effettivamente chiuso (ed il blocco rimosso)
-fintanto che non viene rilasciata la relativa voce nella \itindex{file~table}
-\textit{file table}; e questo avverrà solo quando tutti i file descriptor che
-fanno riferimento alla stessa voce sono stati chiusi. Quindi, nel caso ci
-siano duplicati o processi figli che mantengono ancora aperto un file
-descriptor, il \textit{file lock} non viene rilasciato.
+fintanto che non viene rilasciata la relativa voce nella \textit{file table};
+e questo avverrà solo quando tutti i file descriptor che fanno riferimento
+alla stessa voce sono stati chiusi. Quindi, nel caso ci siano duplicati o
+processi figli che mantengono ancora aperto un file descriptor, il
+\textit{file lock} non viene rilasciato.
\subsection{Il \textit{file locking} POSIX}
\item[\errcode{EDEADLK}] si è richiesto un \textit{lock} su una regione
bloccata da un altro processo che è a sua volta in attesa dello sblocco
di un \textit{lock} mantenuto dal processo corrente; si avrebbe pertanto
- un \itindex{deadlock} \textit{deadlock}. Non è garantito che il sistema
- riconosca sempre questa situazione.
+ un \textit{deadlock}. Non è garantito che il sistema riconosca sempre
+ questa situazione.
\item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima
di poter acquisire un \textit{file lock}.
\item[\errcode{ENOLCK}] il sistema non ha le risorse per il blocco: ci
\begin{figure}[!htb]
\centering \includegraphics[width=9cm]{img/file_lock_dead}
- \caption{Schema di una situazione di \itindex{deadlock} \textit{deadlock}.}
+ \caption{Schema di una situazione di \textit{deadlock}.}
\label{fig:file_flock_dead}
\end{figure}
del processo 2; il processo 1 si bloccherà fintanto che il processo 2 non
rilasci il blocco. Ma cosa accade se il processo 2 nel frattempo tenta a sua
volta di ottenere un lock sulla regione A? Questa è una tipica situazione che
-porta ad un \itindex{deadlock} \textit{deadlock}, dato che a quel punto anche
-il processo 2 si bloccherebbe, e niente potrebbe sbloccare l'altro processo.
-Per questo motivo il kernel si incarica di rilevare situazioni di questo tipo,
-ed impedirle restituendo un errore di \errcode{EDEADLK} alla funzione che
-cerca di acquisire un blocco che porterebbe ad un \itindex{deadlock}
-\textit{deadlock}.
+porta ad un \textit{deadlock}, dato che a quel punto anche il processo 2 si
+bloccherebbe, e niente potrebbe sbloccare l'altro processo. Per questo motivo
+il kernel si incarica di rilevare situazioni di questo tipo, ed impedirle
+restituendo un errore di \errcode{EDEADLK} alla funzione che cerca di
+acquisire un blocco che porterebbe ad un \textit{deadlock}.
Per capire meglio il funzionamento del \textit{file locking} in semantica
POSIX (che differisce alquanto rispetto da quello di BSD, visto
grazie ai campi \var{fl\_start} e \var{fl\_end}. La struttura è comunque la
stessa, solo che in questo caso nel campo \var{fl\_flags} è impostato il bit
\const{FL\_POSIX} ed il campo \var{fl\_file} non viene usato. Il blocco è
-sempre associato \itindex{inode} all'\textit{inode}, solo che in questo caso
-la titolarità non viene identificata con il riferimento ad una voce nella
-\itindex{file~table} \textit{file table}, ma con il valore del \ids{PID} del
-processo.
+sempre associato all'\textit{inode}, solo che in questo caso la titolarità non
+viene identificata con il riferimento ad una voce nella \textit{file table},
+ma con il valore del \ids{PID} del processo.
\begin{figure}[!htb]
\centering \includegraphics[width=12cm]{img/file_posix_lock}
\end{figure}
Quando si richiede un \textit{file lock} il kernel effettua una scansione di
-tutti i blocchi presenti sul file\footnote{scandisce cioè la
- \itindex{linked~list} \textit{linked list} delle strutture
- \kstruct{file\_lock}, scartando automaticamente quelle per cui
- \var{fl\_flags} non è \const{FL\_POSIX}, così che le due interfacce restano
- ben separate.} per verificare se la regione richiesta non si sovrappone ad
-una già bloccata, in caso affermativo decide in base al tipo di blocco, in
-caso negativo il nuovo blocco viene comunque acquisito ed aggiunto alla lista.
+tutti i blocchi presenti sul file\footnote{scandisce cioè la \textit{linked
+ list} delle strutture \kstruct{file\_lock}, scartando automaticamente
+ quelle per cui \var{fl\_flags} non è \const{FL\_POSIX}, così che le due
+ interfacce restano ben separate.} per verificare se la regione richiesta
+non si sovrappone ad una già bloccata, in caso affermativo decide in base al
+tipo di blocco, in caso negativo il nuovo blocco viene comunque acquisito ed
+aggiunto alla lista.
Nel caso di rimozione invece questa viene effettuata controllando che il
\ids{PID} del processo richiedente corrisponda a quello contenuto nel blocco.
opportune verifiche nei processi, questo verrebbe comunque rispettato.
Per poter utilizzare il \textit{mandatory locking} è stato introdotto un
-utilizzo particolare del bit \itindex{sgid~bit} \acr{sgid} dei permessi dei
-file. Se si ricorda quanto esposto in sez.~\ref{sec:file_special_perm}), esso
-viene di norma utilizzato per cambiare il \ids{GID} effettivo con cui viene
-eseguito un programma, ed è pertanto sempre associato alla presenza del
-permesso di esecuzione per il gruppo. Impostando questo bit su un file senza
-permesso di esecuzione in un sistema che supporta il \textit{mandatory
- locking}, fa sì che quest'ultimo venga attivato per il file in questione. In
-questo modo una combinazione dei permessi originariamente non contemplata, in
-quanto senza significato, diventa l'indicazione della presenza o meno del
-\textit{mandatory locking}.\footnote{un lettore attento potrebbe ricordare
- quanto detto in sez.~\ref{sec:file_perm_management} e cioè che il bit
- \acr{sgid} viene cancellato (come misura di sicurezza) quando di scrive su
- un file, questo non vale quando esso viene utilizzato per attivare il
- \textit{mandatory locking}.}
+utilizzo particolare del bit \acr{sgid} dei permessi dei file. Se si ricorda
+quanto esposto in sez.~\ref{sec:file_special_perm}), esso viene di norma
+utilizzato per cambiare il \ids{GID} effettivo con cui viene eseguito un
+programma, ed è pertanto sempre associato alla presenza del permesso di
+esecuzione per il gruppo. Impostando questo bit su un file senza permesso di
+esecuzione in un sistema che supporta il \textit{mandatory locking}, fa sì che
+quest'ultimo venga attivato per il file in questione. In questo modo una
+combinazione dei permessi originariamente non contemplata, in quanto senza
+significato, diventa l'indicazione della presenza o meno del \textit{mandatory
+ locking}.\footnote{un lettore attento potrebbe ricordare quanto detto in
+ sez.~\ref{sec:file_perm_management} e cioè che il bit \acr{sgid} viene
+ cancellato (come misura di sicurezza) quando di scrive su un file, questo
+ non vale quando esso viene utilizzato per attivare il \textit{mandatory
+ locking}.}
L'uso del \textit{mandatory locking} presenta vari aspetti delicati, dato che
neanche l'amministratore può passare sopra ad un \textit{file lock}; pertanto
un processo che blocchi un file cruciale può renderlo completamente
inaccessibile, rendendo completamente inutilizzabile il sistema\footnote{il
- problema si potrebbe risolvere rimuovendo il bit \itindex{sgid~bit}
- \acr{sgid}, ma non è detto che sia così facile fare questa operazione con un
- sistema bloccato.} inoltre con il \textit{mandatory locking} si può
-bloccare completamente un server NFS richiedendo una lettura su un file su cui
-è attivo un blocco. Per questo motivo l'abilitazione del \textit{mandatory
- locking} è di norma disabilitata, e deve essere attivata filesystem per
-filesystem in fase di montaggio, specificando l'apposita opzione di
-\func{mount} riportata in sez.~\ref{sec:filesystem_mounting}, o con l'opzione
-\code{-o mand} per il comando omonimo.
+ problema si potrebbe risolvere rimuovendo il bit \acr{sgid}, ma non è detto
+ che sia così facile fare questa operazione con un sistema bloccato.}
+inoltre con il \textit{mandatory locking} si può bloccare completamente un
+server NFS richiedendo una lettura su un file su cui è attivo un blocco. Per
+questo motivo l'abilitazione del \textit{mandatory locking} è di norma
+disabilitata, e deve essere attivata filesystem per filesystem in fase di
+montaggio, specificando l'apposita opzione di \func{mount} riportata in
+sez.~\ref{sec:filesystem_mounting}, o con l'opzione \code{-o mand} per il
+comando omonimo.
Si tenga presente inoltre che il \textit{mandatory locking} funziona solo
sull'interfaccia POSIX di \func{fcntl}. Questo ha due conseguenze: che non si
che in certi casi le funzioni di I/O eseguite su un file descriptor possono
bloccarsi indefinitamente. Questo non avviene mai per i file normali, per i
quali le funzioni di lettura e scrittura ritornano sempre subito, ma può
-avvenire per alcuni \index{file!di~dispositivo} file di dispositivo, come ad
-esempio una seriale o un terminale, o con l'uso di file descriptor collegati a
-meccanismi di intercomunicazione come le \textit{pipe} (vedi
-sez.~\ref{sec:ipc_unix}) ed i socket (vedi sez.~\ref{sec:sock_socket_def}). In
-casi come questi ad esempio una operazione di lettura potrebbe bloccarsi se
-non ci sono dati disponibili sul descrittore su cui la si sta effettuando.
+avvenire per alcuni file di dispositivo, come ad esempio una seriale o un
+terminale, o con l'uso di file descriptor collegati a meccanismi di
+intercomunicazione come le \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}) ed i
+socket (vedi sez.~\ref{sec:sock_socket_def}). In casi come questi ad esempio
+una operazione di lettura potrebbe bloccarsi se non ci sono dati disponibili
+sul descrittore su cui la si sta effettuando.
Questo comportamento è alla radice di una delle problematiche più comuni che
ci si trova ad affrontare nella gestione delle operazioni di I/O: la necessità
quella bloccata, mentre nel peggiore dei casi, quando la conclusione
dell'operazione bloccata dipende da quanto si otterrebbe dal file descriptor
``\textsl{disponibile}'', si potrebbe addirittura arrivare ad un
-\itindex{deadlock} \textit{deadlock}.
+\textit{deadlock}.
+
+\itindbeg{polling}
Abbiamo già accennato in sez.~\ref{sec:file_open_close} che è possibile
prevenire questo tipo di comportamento delle funzioni di I/O aprendo un file
immediatamente, restituendo l'errore \errcode{EAGAIN}. L'utilizzo di questa
modalità di I/O permette di risolvere il problema controllando a turno i vari
file descriptor, in un ciclo in cui si ripete l'accesso fintanto che esso non
-viene garantito. Ovviamente questa tecnica, detta \itindex{polling}
-\textit{polling}, è estremamente inefficiente: si tiene costantemente
-impiegata la CPU solo per eseguire in continuazione delle \textit{system call}
-che nella gran parte dei casi falliranno.
+viene garantito. Ovviamente questa tecnica, detta \textit{polling}, è
+estremamente inefficiente: si tiene costantemente impiegata la CPU solo per
+eseguire in continuazione delle \textit{system call} che nella gran parte dei
+casi falliranno.
+
+\itindend{polling}
É appunto per superare questo problema è stato introdotto il concetto di
\textit{I/O multiplexing}, una nuova modalità per la gestione dell'I/O che
Per specificare quali file descriptor si intende selezionare la funzione usa
un particolare oggetto, il \textit{file descriptor set}, identificato dal tipo
\type{fd\_set}, che serve ad identificare un insieme di file descriptor, in
-maniera analoga a come un \itindex{signal~set} \textit{signal set} (vedi
-sez.~\ref{sec:sig_sigset}) identifica un insieme di segnali. Per la
-manipolazione di questi \textit{file descriptor set} si possono usare delle
-opportune macro di preprocessore:
+maniera analoga a come un \textit{signal set} (vedi sez.~\ref{sec:sig_sigset})
+identifica un insieme di segnali. Per la manipolazione di questi \textit{file
+ descriptor set} si possono usare delle opportune macro di preprocessore:
{\centering
\vspace{3pt}
bloccante, quindi anche in caso di \textit{end-of-file}.} il secondo,
\param{writefds}, per verificare la possibilità di effettuare una scrittura ed
il terzo, \param{exceptfds}, per verificare l'esistenza di eccezioni come i
-dati urgenti \itindex{out-of-band} su un socket, (vedi
-sez.~\ref{sec:TCP_urgent_data}).
+dati urgenti su un socket, (vedi sez.~\ref{sec:TCP_urgent_data}).
Dato che in genere non si tengono mai sotto controllo fino a
\const{FD\_SETSIZE} file contemporaneamente, la funzione richiede di
\val{NULL} la funzione attende indefinitamente. Si può specificare anche un
tempo nullo (cioè una struttura \struct{timeval} con i campi impostati a
zero), qualora si voglia semplicemente controllare lo stato corrente dei file
-descriptor, e così può essere utilizzata eseguire il \itindex{polling}
-\textit{polling} su un gruppo di file descriptor. Usare questo argomento con
-tutti i \textit{file descriptor set} vuoti è un modo portabile, disponibile
-anche su sistemi in cui non sono disponibili le funzioni avanzate di
-sez.~\ref{sec:sig_timer_adv}, per tenere un processo in stato di
-\textit{sleep} con precisioni inferiori al secondo.
+descriptor, e così può essere utilizzata eseguire il \textit{polling} su un
+gruppo di file descriptor. Usare questo argomento con tutti i \textit{file
+ descriptor set} vuoti è un modo portabile, disponibile anche su sistemi in
+cui non sono disponibili le funzioni avanzate di sez.~\ref{sec:sig_timer_adv},
+per tenere un processo in stato di \textit{sleep} con precisioni inferiori al
+secondo.
In caso di successo la funzione restituisce il numero di file descriptor
pronti, seguendo il comportamento previsto dallo standard
viene sostituita da quella così indicata immediatamente prima di eseguire
l'attesa, e viene poi ripristinata al ritorno della funzione. L'uso
di \param{sigmask} è stato introdotto allo scopo di prevenire possibili
-\textit{race condition} \itindex{race~condition} quando oltre alla presenza di
-dati sui file descriptor come nella \func{select} ordinaria, ci si deve porre
-in attesa anche dell'arrivo di un segnale.
+\textit{race condition} quando oltre alla presenza di dati sui file descriptor
+come nella \func{select} ordinaria, ci si deve porre in attesa anche
+dell'arrivo di un segnale.
Come abbiamo visto in sez.~\ref{sec:sig_example} la tecnica classica per
rilevare l'arrivo di un segnale è quella di utilizzare il gestore per
-impostare una \index{variabili!globali} variabile globale e controllare questa
-nel corpo principale del programma; abbiamo visto in quell'occasione come
-questo lasci spazio a possibili \itindex{race~condition} \textit{race
- condition}, per cui diventa essenziale utilizzare \func{sigprocmask} per
-disabilitare la ricezione del segnale prima di eseguire il controllo e
-riabilitarlo dopo l'esecuzione delle relative operazioni, onde evitare
-l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe perso.
+impostare una variabile globale e controllare questa nel corpo principale del
+programma; abbiamo visto in quell'occasione come questo lasci spazio a
+possibili \textit{race condition}, per cui diventa essenziale utilizzare
+\func{sigprocmask} per disabilitare la ricezione del segnale prima di eseguire
+il controllo e riabilitarlo dopo l'esecuzione delle relative operazioni, onde
+evitare l'arrivo di un segnale immediatamente dopo il controllo, che andrebbe
+perso.
Nel nostro caso il problema si pone quando, oltre al segnale, si devono tenere
sotto controllo anche dei file descriptor con \func{select}, in questo caso si
e si potrebbero eseguire di conseguenza le operazioni relative al segnale e
alla gestione dati con un ciclo del tipo:
\includecodesnip{listati/select_race.c}
-qui però emerge una \itindex{race~condition} \textit{race condition}, perché
-se il segnale arriva prima della chiamata a \func{select}, questa non verrà
-interrotta, e la ricezione del segnale non sarà rilevata.
+qui però emerge una \textit{race condition}, perché se il segnale arriva prima
+della chiamata a \func{select}, questa non verrà interrotta, e la ricezione
+del segnale non sarà rilevata.
Per questo è stata introdotta \func{pselect} che attraverso l'argomento
\param{sigmask} permette di riabilitare la ricezione il segnale
contestualmente all'esecuzione della funzione,\footnote{in Linux però, fino al
kernel 2.6.16, non era presente la relativa \textit{system call}, e la
funzione era implementata nelle \acr{glibc} attraverso \func{select} (vedi
- \texttt{man select\_tut}) per cui la possibilità di \itindex{race~condition}
- \textit{race condition} permaneva; in tale situazione si può ricorrere ad
- una soluzione alternativa, chiamata \itindex{self-pipe trick}
- \textit{self-pipe trick}, che consiste nell'aprire una \textit{pipe} (vedi
- sez.~\ref{sec:ipc_pipes}) ed usare \func{select} sul capo in lettura della
- stessa; si può indicare l'arrivo di un segnale scrivendo sul capo in
- scrittura all'interno del gestore dello stesso; in questo modo anche se il
- segnale va perso prima della chiamata di \func{select} questa lo riconoscerà
- comunque dalla presenza di dati sulla \textit{pipe}.} ribloccandolo non
-appena essa ritorna, così che il precedente codice potrebbe essere riscritto
-nel seguente modo:
+ \texttt{man select\_tut}) per cui la possibilità di \textit{race condition}
+ permaneva; in tale situazione si può ricorrere ad una soluzione alternativa,
+ chiamata \itindex{self-pipe~trick} \textit{self-pipe trick}, che consiste
+ nell'aprire una \textit{pipe} (vedi sez.~\ref{sec:ipc_pipes}) ed usare
+ \func{select} sul capo in lettura della stessa; si può indicare l'arrivo di
+ un segnale scrivendo sul capo in scrittura all'interno del gestore dello
+ stesso; in questo modo anche se il segnale va perso prima della chiamata di
+ \func{select} questa lo riconoscerà comunque dalla presenza di dati sulla
+ \textit{pipe}.} ribloccandolo non appena essa ritorna, così che il
+precedente codice potrebbe essere riscritto nel seguente modo:
\includecodesnip{listati/pselect_norace.c}
in questo caso utilizzando \var{oldmask} durante l'esecuzione di
\func{pselect} la ricezione del segnale sarà abilitata, ed in caso di
\const{POLLIN} & È possibile la lettura.\\
\const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\
\const{POLLRDBAND}& Sono disponibili in lettura dati prioritari.\\
- \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati
- urgenti.\\
+ \const{POLLPRI} & È possibile la lettura di dati urgenti.\\
\hline
\const{POLLOUT} & È possibile la scrittura immediata.\\
\const{POLLWRNORM}& È possibile la scrittura di dati normali.\\
\footnotetext{si tratta di una estensione specifica di Linux, disponibile a
partire dal kernel 2.6.17 definendo la marco \macro{\_GNU\_SOURCE}, che
consente di riconoscere la chiusura in scrittura dell'altro capo di un
- socket, situazione che si viene chiamata appunto \itindex{half-close}
- \textit{half-close} (\textsl{mezza chiusura}) su cui torneremo con maggiori
- dettagli in sez.~\ref{sec:TCP_shutdown}.}
+ socket, situazione che si viene chiamata appunto \textit{half-close}
+ (\textsl{mezza chiusura}) su cui torneremo con maggiori dettagli in
+ sez.~\ref{sec:TCP_shutdown}.}
Il valore \const{POLLMSG} non viene utilizzato ed è definito solo per
compatibilità con l'implementazione di System V che usa i cosiddetti
librerie standard del C visti in sez.~\ref{sec:file_stream}. Da essa derivano
i nomi di alcune costanti poiché per quegli \textit{stream} sono definite tre
classi di dati: \textsl{normali}, \textit{prioritari} ed \textit{urgenti}. In
-Linux la distinzione ha senso solo per i dati urgenti \itindex{out-of-band}
-dei socket (vedi sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come
-\func{poll} reagisce alle varie condizioni dei socket torneremo in
-sez.~\ref{sec:TCP_serv_poll}, dove vedremo anche un esempio del suo utilizzo.
+Linux la distinzione ha senso solo per i dati urgenti dei socket (vedi
+sez.~\ref{sec:TCP_urgent_data}), ma su questo e su come \func{poll} reagisce
+alle varie condizioni dei socket torneremo in sez.~\ref{sec:TCP_serv_poll},
+dove vedremo anche un esempio del suo utilizzo.
Le costanti relative ai diversi tipi di dati normali e prioritari che fanno
riferimento alle implementazioni in stile System V sono \const{POLLRDNORM},
ha chiuso la connessione o il capo in scrittura
della stessa (vedi
sez.~\ref{sec:TCP_shutdown}).\footnotemark\\
- \const{EPOLLPRI} & Ci sono \itindex{out-of-band} dati urgenti
- disponibili in lettura (analogo di
- \const{POLLPRI}); questa condizione viene comunque
+ \const{EPOLLPRI} & Ci sono dati urgenti disponibili in lettura (analogo
+ di \const{POLLPRI}); questa condizione viene comunque
riportata in uscita, e non è necessaria impostarla
in ingresso.\\
\hline
Abbiamo visto in sez.~\ref{sec:file_select} come il meccanismo classico delle
notifiche di eventi tramite i segnali, presente da sempre nei sistemi
unix-like, porti a notevoli problemi nell'interazione con le funzioni per
-l'\textit{I/O multiplexing}, tanto che per evitare possibili
-\itindex{race~condition} \textit{race condition} sono state introdotte
-estensioni dello standard POSIX e funzioni apposite come \func{pselect},
-\func{ppoll} e \funcd{epoll\_pwait}.
+l'\textit{I/O multiplexing}, tanto che per evitare possibili \textit{race
+ condition} sono state introdotte estensioni dello standard POSIX e funzioni
+apposite come \func{pselect}, \func{ppoll} e \funcd{epoll\_pwait}.
Benché i segnali siano il meccanismo più usato per effettuare notifiche ai
processi, la loro interfaccia di programmazione, che comporta l'esecuzione di
asincrone in qualunque momento. Questo comporta la necessità di dover
gestire, quando si deve tener conto di entrambi i tipi di eventi, le
interruzioni delle funzioni di attesa sincrone, ed evitare possibili
-\itindex{race~condition} \textit{race conditions}. In sostanza se non ci
-fossero i segnali non ci sarebbe da preoccuparsi, fintanto che si effettuano
-operazioni all'interno di un processo, della non atomicità delle
-\index{system~call~lente} \textit{system call} lente che vengono interrotte e
-devono essere riavviate.
+\textit{race conditions}. In sostanza se non ci fossero i segnali non ci
+sarebbe da preoccuparsi, fintanto che si effettuano operazioni all'interno di
+un processo, della non atomicità delle \index{system~call~lente}
+\textit{system call} lente che vengono interrotte e devono essere riavviate.
Abbiamo visto però in sez.~\ref{sec:sig_real_time} che insieme ai segnali
\textit{real-time} sono state introdotte anche delle interfacce di gestione
\item[\errcode{EINVAL}] il file descriptor \param{fd} non è stato ottenuto
con \func{signalfd} o il valore di \param{flags} non è valido.
\item[\errcode{ENODEV}] il kernel non può montare internamente il
- dispositivo per la gestione anonima degli \itindex{inode} \textit{inode}
+ dispositivo per la gestione anonima degli \textit{inode}
associati al file descriptor.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
\var{ssi\_ptr} e \var{ssi\_int} per segnali inviati con \func{sigqueue}.}
Come esempio di questa nuova interfaccia ed anche come esempio di applicazione
-della interfaccia di \itindex{epoll} \textit{epoll}, si è scritto un programma
-elementare che stampi sullo standard output sia quanto viene scritto da terzi
-su una \textit{named fifo}, che l'avvenuta ricezione di alcuni segnali. Il
-codice completo si trova al solito nei sorgenti allegati alla guida (nel file
+della interfaccia di \textit{epoll}, si è scritto un programma elementare che
+stampi sullo \textit{standard output} sia quanto viene scritto da terzi su una
+\textit{named fifo}, che l'avvenuta ricezione di alcuni segnali. Il codice
+completo si trova al solito nei sorgenti allegati alla guida (nel file
\texttt{FifoReporter.c}).
In fig.~\ref{fig:fiforeporter_code_init} si è riportata la parte iniziale del
programma in cui vengono effettuate le varie inizializzazioni necessarie per
-l'uso di \itindex{epoll} \textit{epoll} e \func{signalfd}, a partire
-(\texttt{\small 12-16}) dalla definizione delle varie variabili e strutture
-necessarie. Al solito si è tralasciata la parte dedicata alla decodifica delle
-opzioni che consentono ad esempio di cambiare il nome del file associato alla
-\textit{fifo}.
+l'uso di \textit{epoll} e \func{signalfd}, a partire (\texttt{\small 12-16})
+dalla definizione delle varie variabili e strutture necessarie. Al solito si è
+tralasciata la parte dedicata alla decodifica delle opzioni che consentono ad
+esempio di cambiare il nome del file associato alla \textit{fifo}.
Il primo passo (\texttt{\small 19-20}) è la creazione di un file descriptor
-\texttt{epfd} di \itindex{epoll} \textit{epoll} con \func{epoll\_create} che è
-quello che useremo per il controllo degli altri. É poi necessario
-disabilitare la ricezione dei segnali (nel caso \signal{SIGINT},
-\signal{SIGQUIT} e \signal{SIGTERM}) per i quali si vuole la notifica tramite
-file descriptor. Per questo prima li si inseriscono (\texttt{\small 22-25}) in
-una maschera di segnali \texttt{sigmask} che useremo con (\texttt{\small 26})
+\texttt{epfd} di \textit{epoll} con \func{epoll\_create} che è quello che
+useremo per il controllo degli altri. É poi necessario disabilitare la
+ricezione dei segnali (nel caso \signal{SIGINT}, \signal{SIGQUIT} e
+\signal{SIGTERM}) per i quali si vuole la notifica tramite file
+descriptor. Per questo prima li si inseriscono (\texttt{\small 22-25}) in una
+maschera di segnali \texttt{sigmask} che useremo con (\texttt{\small 26})
\func{sigprocmask} per disabilitarli. Con la stessa maschera si potrà per
passare all'uso (\texttt{\small 28-29}) di \func{signalfd} per abilitare la
notifica sul file descriptor \var{sigfd}. Questo poi (\texttt{\small 30-33})
controllati con \texttt{epfd}.
Occorrerà infine (\texttt{\small 35-38}) creare la \textit{named fifo} se
-questa non esiste ed aprirla per la lettura (\texttt{\small 39-40}); una
-volta fatto questo sarà necessario aggiungere il relativo file descriptor
-(\var{fifofd}) a quelli osservati da \itindex{epoll} \textit{epoll} in maniera
-del tutto analoga a quanto fatto con quello relativo alla notifica dei
-segnali.
+questa non esiste ed aprirla per la lettura (\texttt{\small 39-40}); una volta
+fatto questo sarà necessario aggiungere il relativo file descriptor
+(\var{fifofd}) a quelli osservati da \textit{epoll} in maniera del tutto
+analoga a quanto fatto con quello relativo alla notifica dei segnali.
\begin{figure}[!htb]
\footnotesize \centering
l'argomento \param{flag} non è valido, o è diverso da zero per kernel
precedenti il 2.6.27.
\item[\errcode{ENODEV}] il kernel non può montare internamente il
- dispositivo per la gestione anonima degli \itindex{inode} \textit{inode}
- associati al file descriptor.
+ dispositivo per la gestione anonima degli \textit{inode} associati al file
+ descriptor.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per creare un nuovo file
descriptor di \func{signalfd}.
\end{errlist}
Per questo motivo Stevens, ed anche le pagine di manuale di Linux, chiamano
questa modalità ``\textit{Signal driven I/O}''. Si tratta di un'altra
-modalità di gestione dell'I/O, alternativa all'uso di \itindex{epoll}
+modalità di gestione dell'I/O, alternativa all'uso di
\textit{epoll},\footnote{anche se le prestazioni ottenute con questa tecnica
sono inferiori, il vantaggio è che questa modalità è utilizzabile anche con
kernel che non supportano \textit{epoll}, come quelli della serie 2.4,
all'origine di Unix i soli programmi che potevano avere una tale esigenza
erano i demoni, attenendosi a uno dei criteri base della progettazione, che
era di far fare al kernel solo le operazioni strettamente necessarie e
-lasciare tutto il resto a processi in user space, non era stata prevista
-nessuna funzionalità di notifica.
+lasciare tutto il resto a processi in \textit{user space}, non era stata
+prevista nessuna funzionalità di notifica.
Visto però il crescente interesse nei confronti di una funzionalità di questo
tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad
filesystem, sono state successivamente introdotte delle estensioni che
permettessero la creazione di meccanismi di notifica più efficienti dell'unica
soluzione disponibile con l'interfaccia tradizionale, che è quella del
-\itindex{polling} \textit{polling}.
+\textit{polling}.
Queste nuove funzionalità sono delle estensioni specifiche, non
standardizzate, che sono disponibili soltanto su Linux (anche se altri kernel
(\textit{pipe} e dispositivi sono quindi esclusi). Inoltre un processo non
privilegiato può ottenere un \textit{lease} soltanto per un file appartenente
ad un \ids{UID} corrispondente a quello del processo. Soltanto un processo con
-privilegi di amministratore (cioè con la \itindex{capabilities} capability
-\const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può acquisire
-\textit{lease} su qualunque file.
+privilegi di amministratore (cioè con la capacità \const{CAP\_LEASE}, vedi
+sez.~\ref{sec:proc_capabilities}) può acquisire \textit{lease} su qualunque
+file.
Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
esegue una \func{truncate} o una \func{open} che confligge con
\const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in
lettura.\\
\const{IN\_ATTRIB} &$\bullet$& Ci sono stati cambiamenti sui dati
- dell'\itindex{inode} \textit{inode}
+ dell'\textit{inode}
(o sugli attributi estesi, vedi
sez.~\ref{sec:file_xattr}).\\
\const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in
rispetto a quelle usate normalmente.
In generale questa interfaccia è completamente astratta e può essere
-implementata sia direttamente nel kernel che in user space attraverso l'uso di
-\itindex{thread} \textit{thread}. Per le versioni del kernel meno recenti
-esiste una implementazione di questa interfaccia fornita completamente delle
-\acr{glibc} a partire dalla versione 2.1, che è realizzata completamente in
-user space, ed è accessibile linkando i programmi con la libreria
+implementata sia direttamente nel kernel che in \textit{user space} attraverso
+l'uso di \textit{thread}. Per le versioni del kernel meno recenti esiste una
+implementazione di questa interfaccia fornita completamente delle \acr{glibc}
+a partire dalla versione 2.1, che è realizzata completamente in \textit{user
+ space}, ed è accessibile linkando i programmi con la libreria
\file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
una nuova infrastruttura per l'I/O asincrono, ma ancora il supporto è parziale
ed insufficiente ad implementare tutto l'AIO POSIX.
operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
richiesta. Questo comporta che non si devono usare per \param{aiocbp}
-\index{variabili!automatiche} variabili automatiche e che non si deve
-riutilizzare la stessa struttura per un'altra operazione fintanto che la
-precedente non sia stata ultimata. In generale per ogni operazione si deve
-utilizzare una diversa struttura \struct{aiocb}.
+variabili automatiche e che non si deve riutilizzare la stessa struttura per
+un'altra operazione fintanto che la precedente non sia stata ultimata. In
+generale per ogni operazione si deve utilizzare una diversa struttura
+\struct{aiocb}.
Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
\func{aio\_write} non implica che le operazioni siano state effettivamente
\label{sec:file_memory_map}
\itindbeg{memory~mapping}
+
Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
rispetto a quella classica vista in sez.~\ref{sec:file_unix_interface}, è il
cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della
-\textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
+\textsl{paginazione} usato dalla memoria virtuale (vedi
sez.~\ref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un
file in una sezione dello spazio di indirizzi del processo che lo ha allocato.
specificato con uno dei valori riportati in
tab.~\ref{tab:madvise_advice_values}; si tenga presente che i valori indicati
nella seconda parte della tabella sono specifici di Linux e non sono previsti
-dallo standard POSIX.1b.
-La funzione non ha, tranne il caso di \const{MADV\_DONTFORK}, nessun effetto
-sul comportamento di un programma, ma può influenzarne le prestazioni fornendo
-al kernel indicazioni sulle esigenze dello stesso, così che sia possibile
-scegliere le opportune strategie per la gestione del \itindex{read-ahead}
-\textit{read-ahead} e del caching dei dati.
+dallo standard POSIX.1b. La funzione non ha, tranne il caso di
+\const{MADV\_DONTFORK}, nessun effetto sul comportamento di un programma, ma
+può influenzarne le prestazioni fornendo al kernel indicazioni sulle esigenze
+dello stesso, così che sia possibile scegliere le opportune strategie per la
+gestione del \textit{read-ahead} (vedi sez.~\ref{sec:file_fadvise}) e del
+caching dei dati.
\begin{table}[!htb]
\centering
dell'ulteriore argomento il comportamento delle funzioni è identico alle
precedenti \func{readv} e \func{writev}.
-Con l'uso di queste funzioni si possono evitare eventuali
-\itindex{race~condition} \textit{race condition} quando si deve eseguire la
-una operazione di lettura e scrittura vettorizzata a partire da una certa
-posizione su un file, mentre al contempo si possono avere in concorrenza
-processi che utilizzano lo stesso file descriptor (si ricordi quanto visto in
-sez.~\ref{sec:file_adv_func}) con delle chiamate a \func{lseek}.
+Con l'uso di queste funzioni si possono evitare eventuali \textit{race
+ condition} quando si deve eseguire la una operazione di lettura e scrittura
+vettorizzata a partire da una certa posizione su un file, mentre al contempo
+si possono avere in concorrenza processi che utilizzano lo stesso file
+descriptor (si ricordi quanto visto in sez.~\ref{sec:file_adv_func}) con delle
+chiamate a \func{lseek}.
file descriptor, e permetteva di sostituire la invocazione successiva di una
\func{read} e una \func{write} (e l'allocazione del relativo buffer) con una
sola chiamata a \funcd{sendfile}. In questo modo si poteva diminuire il numero
-di chiamate al sistema e risparmiare in trasferimenti di dati da kernel space
-a user space e viceversa. La massima utilità della funzione si ottiene
-comunque per il trasferimento di dati da un file su disco ad un socket di
-rete,\footnote{questo è il caso classico del lavoro eseguito da un server web,
- ed infatti Apache ha una opzione per il supporto esplicito di questa
- funzione.} dato che in questo caso diventa possibile effettuare il
-trasferimento diretto via DMA dal controller del disco alla scheda di rete,
-senza neanche allocare un buffer nel kernel (il meccanismo è detto
-\textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel, che si
-limita a programmare solo le operazioni di lettura e scrittura via DMA)
+di chiamate al sistema e risparmiare in trasferimenti di dati da
+\textit{kernel space} a \textit{user space} e viceversa. La massima utilità
+della funzione si ottiene comunque per il trasferimento di dati da un file su
+disco ad un socket di rete,\footnote{questo è il caso classico del lavoro
+ eseguito da un server web, ed infatti Apache ha una opzione per il supporto
+ esplicito di questa funzione.} dato che in questo caso diventa possibile
+effettuare il trasferimento diretto via DMA dal controller del disco alla
+scheda di rete, senza neanche allocare un buffer nel kernel (il meccanismo è
+detto \textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel,
+che si limita a programmare solo le operazioni di lettura e scrittura via DMA)
ottenendo la massima efficienza possibile senza pesare neanche sul processore.
In seguito però ci si accorse che, fatta eccezione per il trasferimento
\func{write}. Nel caso generico infatti il kernel deve comunque allocare un
buffer ed effettuare la copia dei dati, e in tal caso spesso il guadagno
ottenibile nel ridurre il numero di chiamate al sistema non compensa le
-ottimizzazioni che possono essere fatte da una applicazione in user space che
-ha una conoscenza diretta su come questi sono strutturati, per cui in certi
-casi si potevano avere anche dei peggioramenti. Questo ha portato, per i
-kernel della serie 2.6,\footnote{per alcune motivazioni di questa scelta si
- può fare riferimento a quanto illustrato da Linus Torvalds in
- \url{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}.} alla
-decisione di consentire l'uso della funzione soltanto quando il file da cui si
-legge supporta le operazioni di \textit{memory mapping} (vale a dire non è un
-socket) e quello su cui si scrive è un socket; in tutti gli altri casi l'uso
-di \func{sendfile} da luogo ad un errore di \errcode{EINVAL}.
+ottimizzazioni che possono essere fatte da una applicazione in \textit{user
+ space} che ha una conoscenza diretta su come questi sono strutturati, per
+cui in certi casi si potevano avere anche dei peggioramenti. Questo ha
+portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
+ questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
+ in \url{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}.}
+alla decisione di consentire l'uso della funzione soltanto quando il file da
+cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
+non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
+casi l'uso di \func{sendfile} da luogo ad un errore di \errcode{EINVAL}.
Nonostante ci possano essere casi in cui \func{sendfile} non migliora le
prestazioni, resta il dubbio se la scelta di disabilitarla sempre per il
In realtà le due \textit{system call} sono profondamente diverse nel loro
meccanismo di funzionamento;\footnote{questo fino al kernel 2.6.23, dove
\func{sendfile} è stata reimplementata in termini di \func{splice}, pur
- mantenendo disponibile la stessa interfaccia verso l'user space.}
+ mantenendo disponibile la stessa interfaccia verso l'\textit{user space}.}
\func{sendfile} infatti, come accennato, non necessita di avere a disposizione
un buffer interno, perché esegue un trasferimento diretto di dati; questo la
rende in generale più efficiente, ma anche limitata nelle sue applicazioni,
generica delle operazioni di trasferimento di dati fra un file e un buffer
gestito interamente in \textit{kernel space}. In questo caso il cuore della
funzione (e delle affini \func{vmsplice} e \func{tee}, che tratteremo più
-avanti) è appunto l'uso di un buffer in kernel space, e questo è anche quello
-che ne ha semplificato l'adozione, perché l'infrastruttura per la gestione di
-un tale buffer è presente fin dagli albori di Unix per la realizzazione delle
-\textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di vista concettuale
-allora \func{splice} non è altro che una diversa interfaccia (rispetto alle
-\textit{pipe}) con cui utilizzare in \textit{user space} l'oggetto
-``\textsl{buffer in kernel space}''.
+avanti) è appunto l'uso di un buffer in \textit{kernel space}, e questo è
+anche quello che ne ha semplificato l'adozione, perché l'infrastruttura per la
+gestione di un tale buffer è presente fin dagli albori di Unix per la
+realizzazione delle \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di
+vista concettuale allora \func{splice} non è altro che una diversa interfaccia
+(rispetto alle \textit{pipe}) con cui utilizzare in \textit{user space}
+l'oggetto ``\textsl{buffer in kernel space}''.
Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
\begin{funcproto}{
\fhead{fcntl.h}
\fdecl{long splice(int fd\_in, off\_t *off\_in, int fd\_out, off\_t
- *off\_out, size\_t len, unsigned int flags)}
+ *off\_out, size\_t len, \\
+\phantom{long splice(}unsigned int flags)}
\fdesc{Trasferisce dati da un file verso una \textit{pipe} o viceversa.}
}
copiarle: per una maggiore efficienza
\func{splice} usa quando possibile i
meccanismi della memoria virtuale per
- eseguire i trasferimenti di dati; in maniera
+ eseguire i trasferimenti di dati. In maniera
analoga a \func{mmap}), qualora le pagine non
possano essere spostate dalla \textit{pipe} o
il buffer non corrisponda a pagine intere
Per capire meglio il funzionamento di \func{splice} vediamo un esempio con un
semplice programma che usa questa funzione per effettuare la copia di un file
-su un altro senza utilizzare buffer in user space. Lo scopo del programma è
-quello di eseguire la copia dei dati con \func{splice}, questo significa che
-si dovrà usare la funzione due volte, prima per leggere i dati dal file di
-ingresso e poi per scriverli su quello di uscita, appoggiandosi ad una
-\textit{pipe}: lo schema del flusso dei dati è illustrato in
+su un altro senza utilizzare buffer in \textit{user space}. Lo scopo del
+programma è quello di eseguire la copia dei dati con \func{splice}, questo
+significa che si dovrà usare la funzione due volte, prima per leggere i dati
+dal file di ingresso e poi per scriverli su quello di uscita, appoggiandosi ad
+una \textit{pipe}: lo schema del flusso dei dati è illustrato in
fig.~\ref{fig:splicecp_data_flux}.
\begin{figure}[htb]
\centering
- \includegraphics[height=4cm]{img/splice_copy}
+ \includegraphics[height=3.5cm]{img/splice_copy}
\caption{Struttura del flusso di dati usato dal programma \texttt{splicecp}.}
\label{fig:splicecp_data_flux}
\end{figure}
Si noti come il programma sia concettualmente identico a quello che si sarebbe
scritto usando \func{read} al posto della prima \func{splice} e \func{write}
-al posto della seconda, utilizzando un buffer in user space per eseguire la
-copia dei dati, solo che in questo caso non è stato necessario allocare nessun
-buffer e non si è trasferito nessun dato in user space.
-
-Si noti anche come si sia usata la combinazione \texttt{SPLICE\_F\_MOVE |
- SPLICE\_F\_MORE } per l'argomento \param{flags} di \func{splice}, infatti
-anche se un valore nullo avrebbe dato gli stessi risultati, l'uso di questi
-flag, che si ricordi servono solo a dare suggerimenti al kernel, permette in
-genere di migliorare le prestazioni.
+al posto della seconda, utilizzando un buffer in \textit{user space} per
+eseguire la copia dei dati, solo che in questo caso non è stato necessario
+allocare nessun buffer e non si è trasferito nessun dato in \textit{user
+ space}. Si noti anche come si sia usata la combinazione
+\texttt{SPLICE\_F\_MOVE | SPLICE\_F\_MORE } per l'argomento \param{flags} di
+\func{splice}, infatti anche se un valore nullo avrebbe dato gli stessi
+risultati, l'uso di questi flag, che si ricordi servono solo a dare
+suggerimenti al kernel, permette in genere di migliorare le prestazioni.
Come accennato con l'introduzione di \func{splice} sono state realizzate anche
altre due \textit{system call}, \func{vmsplice} e \func{tee}, che utilizzano
la stessa infrastruttura e si basano sullo stesso concetto di manipolazione e
-trasferimento di dati attraverso un buffer in kernel space; benché queste non
-attengono strettamente ad operazioni di trasferimento dati fra file
+trasferimento di dati attraverso un buffer in \textit{kernel space}; benché
+queste non attengono strettamente ad operazioni di trasferimento dati fra file
descriptor, le tratteremo qui, essendo strettamente correlate fra loro.
La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
indica il suo nome consente di trasferire i dati dalla memoria virtuale di un
processo (ad esempio per un file mappato in memoria) verso una \textit{pipe};
il suo prototipo è:
-\begin{functions}
- \headdecl{fcntl.h}
- \headdecl{sys/uio.h}
- \funcdecl{long vmsplice(int fd, const struct iovec *iov, unsigned long
- nr\_segs, unsigned int flags)}
-
- Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fhead{sys/uio.h}
+\fdecl{long vmsplice(int fd, const struct iovec *iov, unsigned long nr\_segs,\\
+\phantom{long vmsplice(}unsigned int flags)}
+\fdesc{Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.}
+}
- \bodydesc{La funzione restituisce il numero di byte trasferiti in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+{La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
+ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
fa riferimento ad una \textit{pipe}.
\item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
file descriptor corrispondente al suo capo aperto in scrittura (di nuovo si
eseguire una copia dei dati che contengono.
La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
-suo nome all'omonimo comando in user space, perché in analogia con questo
-permette di duplicare i dati in ingresso su una \textit{pipe} su un'altra
-\textit{pipe}. In sostanza, sempre nell'ottica della manipolazione dei dati su
-dei buffer in kernel space, la funzione consente di eseguire una copia del
-contenuto del buffer stesso. Il prototipo di \funcd{tee} è il seguente:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{long tee(int fd\_in, int fd\_out, size\_t len, unsigned int
+suo nome all'omonimo comando in \textit{user space}, perché in analogia con
+questo permette di duplicare i dati in ingresso su una \textit{pipe} su
+un'altra \textit{pipe}. In sostanza, sempre nell'ottica della manipolazione
+dei dati su dei buffer in \textit{kernel space}, la funzione consente di
+eseguire una copia del contenuto del buffer stesso. Il prototipo di
+\funcd{tee} è il seguente:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{long tee(int fd\_in, int fd\_out, size\_t len, unsigned int
flags)}
-
- Duplica \param{len} byte da una \textit{pipe} ad un'altra.
+\fdesc{Duplica i dati da una \textit{pipe} ad un'altra.}
+}
- \bodydesc{La funzione restituisce il numero di byte copiati in caso di
- successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno
- dei valori:
- \begin{errlist}
+{La funzione ritorna restituisce il numero di byte copiati in caso di successo
+ e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
+ \begin{errlist}
\item[\errcode{EINVAL}] o uno fra \param{fd\_in} e \param{fd\_out} non fa
riferimento ad una \textit{pipe} o entrambi fanno riferimento alla
stessa \textit{pipe}.
\item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
richiesta.
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di
un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
La funzione restituisce il numero di byte copiati da una \textit{pipe}
all'altra (o $-1$ in caso di errore), un valore nullo indica che non ci sono
byte disponibili da copiare e che il capo in scrittura della \textit{pipe} è
-stato chiuso.\footnote{si tenga presente però che questo non avviene se si è
- impostato il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si
- avrebbe un errore di \errcode{EAGAIN}.} Un esempio di realizzazione del
-comando \texttt{tee} usando questa funzione, ripreso da quello fornito nella
-pagina di manuale e dall'esempio allegato al patch originale, è riportato in
+stato chiuso; si tenga presente però che questo non avviene se si è impostato
+il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si avrebbe un errore
+di \errcode{EAGAIN}. Un esempio di realizzazione del comando \texttt{tee}
+usando questa funzione, ripreso da quello fornito nella pagina di manuale e
+dall'esempio allegato al patch originale, è riportato in
fig.~\ref{fig:tee_example}. Il programma consente di copiare il contenuto
-dello standard input sullo standard output e su un file specificato come
-argomento, il codice completo si trova nel file \texttt{tee.c} dei sorgenti
-allegati alla guida.
+dello \textit{standard input} sullo \textit{standard output} e su un file
+specificato come argomento, il codice completo si trova nel file
+\texttt{tee.c} dei sorgenti allegati alla guida.
-\begin{figure}[!htbp]
+\begin{figure}[!htb]
\footnotesize \centering
\begin{minipage}[c]{\codesamplewidth}
\includecodesample{listati/tee.c}
\label{fig:tee_example}
\end{figure}
-La prima parte del programma (\texttt{\small 10-35}) si cura semplicemente di
-controllare (\texttt{\small 11-14}) che sia stato fornito almeno un argomento
-(il nome del file su cui scrivere), di aprirlo ({\small 15-19}) e che sia lo
-standard input (\texttt{\small 20-27}) che lo standard output (\texttt{\small
- 28-35}) corrispondano ad una \textit{pipe}.
+La prima parte del programma, che si è omessa per brevità, si cura
+semplicemente di controllare che sia stato fornito almeno un argomento (il
+nome del file su cui scrivere), di aprirlo e che sia lo standard input che lo
+standard output corrispondano ad una \textit{pipe}.
-Il ciclo principale (\texttt{\small 37-58}) inizia con la chiamata a
+Il ciclo principale (\texttt{\small 11-32}) inizia con la chiamata a
\func{tee} che duplica il contenuto dello standard input sullo standard output
-(\texttt{\small 39}), questa parte è del tutto analoga ad una lettura ed
+(\texttt{\small 13}), questa parte è del tutto analoga ad una lettura ed
infatti come nell'esempio di fig.~\ref{fig:splice_example} si controlla il
valore di ritorno della funzione in \var{len}; se questo è nullo significa che
-non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 40}), se
+non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 14}), se
è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
-dovuto ad una interruzione (\texttt{\small 42-44}) o si stampa un messaggio
-di errore e si esce negli altri casi (\texttt{\small 44-47}).
-
-Una volta completata la copia dei dati sullo standard output si possono
-estrarre dalla standard input e scrivere sul file, di nuovo su usa un ciclo di
-scrittura (\texttt{\small 50-58}) in cui si ripete una chiamata a
-\func{splice} (\texttt{\small 51}) fintanto che non si sono scritti tutti i
-\var{len} byte copiati in precedenza con \func{tee} (il funzionamento è
-identico all'analogo ciclo di scrittura del precedente esempio di
+dovuto ad una interruzione (\texttt{\small 15-48}) o si stampa un messaggio
+di errore e si esce negli altri casi (\texttt{\small 18-21}).
+
+Una volta completata la copia dei dati sullo \textit{standard output} si
+possono estrarre dallo \textit{standard input} e scrivere sul file, di nuovo
+su usa un ciclo di scrittura (\texttt{\small 24-31}) in cui si ripete una
+chiamata a \func{splice} (\texttt{\small 25}) fintanto che non si sono scritti
+tutti i \var{len} byte copiati in precedenza con \func{tee} (il funzionamento
+è identico all'analogo ciclo di scrittura del precedente esempio di
fig.~\ref{fig:splice_example}).
Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
\itindbeg{read-ahead}
Una prima funzione che può essere utilizzata per modificare la gestione
-ordinaria dell'I/O su un file è \funcd{readahead},\footnote{questa è una
- funzione specifica di Linux, introdotta con il kernel 2.4.13, e non deve
- essere usata se si vogliono scrivere programmi portabili.} che consente di
-richiedere una lettura anticipata del contenuto dello stesso in cache, così
-che le seguenti operazioni di lettura non debbano subire il ritardo dovuto
-all'accesso al disco; il suo prototipo è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{ssize\_t readahead(int fd, off64\_t *offset, size\_t count)}
-
- Esegue una lettura preventiva del contenuto di un file in cache.
+ordinaria dell'I/O su un file è \funcd{readahead} (questa è una funzione
+specifica di Linux, introdotta con il kernel 2.4.13, e non deve essere usata
+se si vogliono scrivere programmi portabili), che consente di richiedere una
+lettura anticipata del contenuto dello stesso in cache, così che le seguenti
+operazioni di lettura non debbano subire il ritardo dovuto all'accesso al
+disco; il suo prototipo è:
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{ssize\_t readahead(int fd, off64\_t *offset, size\_t count)}
+\fdesc{Esegue una lettura preventiva del contenuto di un file in cache.}
+}
+
+{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{EBADF}] l'argomento \param{fd} non è un file descriptor
valido o non è aperto in lettura.
\item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
file che non supporta l'operazione (come una \textit{pipe} o un socket).
- \end{errlist}
- }
-\end{functions}
+ \end{errlist}
+}
+\end{funcproto}
La funzione richiede che venga letto in anticipo il contenuto del file
\param{fd} a partire dalla posizione \param{offset} e per un ammontare di
in blocchi corrispondenti alle dimensioni delle pagine di memoria, ed i valori
di \param{offset} e \param{count} vengono arrotondati di conseguenza.
-La funzione estende quello che è un comportamento normale del kernel che
+La funzione estende quello che è un comportamento normale del kernel che,
quando si legge un file, aspettandosi che l'accesso prosegua, esegue sempre
una lettura preventiva di una certa quantità di dati; questo meccanismo di
lettura anticipata viene chiamato \textit{read-ahead}, da cui deriva il nome
\itindend{read-ahead}
Il concetto di \func{readahead} viene generalizzato nello standard
-POSIX.1-2001 dalla funzione \func{posix\_fadvise},\footnote{anche se
- l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
- nella revisione POSIX.1-2003 TC5.} che consente di ``\textsl{avvisare}'' il
+POSIX.1-2001 dalla funzione \func{posix\_fadvise} (anche se
+l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
+nella revisione POSIX.1-2003 TC1) che consente di ``\textsl{avvisare}'' il
kernel sulle modalità con cui si intende accedere nel futuro ad una certa
-porzione di un file,\footnote{la funzione però è stata introdotta su Linux
- solo a partire dal kernel 2.5.60.} così che esso possa provvedere le
-opportune ottimizzazioni; il prototipo di \funcd{posix\_fadvise}, che è
-disponibile soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad
-valore di almeno 600, è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
-
- Dichiara al kernel le future modalità di accesso ad un file.
+porzione di un file, così che esso possa provvedere le opportune
+ottimizzazioni; il prototipo di \funcd{posix\_fadvise}\footnote{la funzione è
+ stata introdotta su Linux solo a partire dal kernel 2.5.60, ed è disponibile
+ soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad valore di
+ almeno \texttt{600} o la macro \macro{\_POSIX\_C\_SOURCE} ad valore di
+ almeno \texttt{200112L}.} è:
- \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di
- errore, nel qual caso \var{errno} assumerà uno dei valori:
- \begin{errlist}
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
+\fdesc{Dichiara al kernel le future modalità di accesso ad un file.}
+}
+
+{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{EBADF}] l'argomento \param{fd} non è un file descriptor
valido.
\item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
\param{fd} si riferisce ad un tipo di file che non supporta l'operazione
(come una \textit{pipe} o un socket).
- \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una \textit{pipe} o
- un socket (ma su Linux viene restituito \errcode{EINVAL}).
- \end{errlist}
- }
-\end{functions}
+ \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una
+ \textit{pipe} o un socket (ma su Linux viene restituito
+ \errcode{EINVAL}).
+ \end{errlist}
+}
+\end{funcproto}
La funzione dichiara al kernel le modalità con cui intende accedere alla
regione del file indicato da \param{fd} che inizia alla posizione
\param{offset} e si estende per \param{len} byte. Se per \param{len} si usa un
-valore nullo la regione coperta sarà da \param{offset} alla fine del
-file.\footnote{questo è vero solo per le versioni più recenti, fino al kernel
- 2.6.6 il valore nullo veniva interpretato letteralmente.} Le modalità sono
-indicate dall'argomento \param{advice} che è una maschera binaria dei valori
-illustrati in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato
-degli analoghi già visti in sez.~\ref{sec:file_memory_map} per
+valore nullo la regione coperta sarà da \param{offset} alla fine del file, ma
+questo è vero solo per le versioni più recenti, fino al kernel 2.6.6 il valore
+nullo veniva interpretato letteralmente. Le modalità sono indicate
+dall'argomento \param{advice} che è una maschera binaria dei valori illustrati
+in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato degli
+analoghi già visti in sez.~\ref{sec:file_memory_map} per
\func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
in questo caso applicata direttamente al sistema ai contenuti di un file
invece che alla sua mappatura in memoria.} Si tenga presente comunque che la
Questa è una indicazione utile che permette di alleggerire il carico sulla
cache, ed un programma può utilizzare periodicamente questa funzione per
liberare pagine di memoria da dati che non sono più utilizzati per far posto a
-nuovi dati utili.\footnote{la pagina di manuale riporta l'esempio dello
- streaming di file di grosse dimensioni, dove le pagine occupate dai dati già
- inviati possono essere tranquillamente scartate.}
+nuovi dati utili; la pagina di manuale riporta l'esempio dello streaming di
+file di grosse dimensioni, dove le pagine occupate dai dati già inviati
+possono essere tranquillamente scartate.
Sia \func{posix\_fadvise} che \func{readahead} attengono alla ottimizzazione
dell'accesso in lettura; lo standard POSIX.1-2001 prevede anche una funzione
-specifica per le operazioni di scrittura,
-\funcd{posix\_fallocate},\footnote{la funzione è stata introdotta a partire
- dalle glibc 2.1.94.} che consente di preallocare dello spazio disco per
-assicurarsi che una seguente scrittura non fallisca, il suo prototipo,
-anch'esso disponibile solo se si definisce la macro \macro{\_XOPEN\_SOURCE} ad
-almeno 600, è:
-\begin{functions}
- \headdecl{fcntl.h}
-
- \funcdecl{int posix\_fallocate(int fd, off\_t offset, off\_t len)}
-
- Richiede la allocazione di spazio disco per un file.
+specifica per le operazioni di scrittura, \funcd{posix\_fallocate} (la
+funzione è stata introdotta a partire dalle glibc 2.1.94), che consente di
+preallocare dello spazio disco per assicurarsi che una seguente scrittura non
+fallisca, il suo prototipo, anch'esso disponibile solo se si definisce la
+macro \macro{\_XOPEN\_SOURCE} ad almeno 600, è:
+
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int posix\_fallocate(int fd, off\_t offset, off\_t len)}
+\fdesc{Richiede la allocazione di spazio disco per un file.}
+}
- \bodydesc{La funzione restituisce 0 in caso di successo e direttamente un
- codice di errore, in caso di fallimento, in questo caso \var{errno} non
- viene impostata, ma sarà restituito direttamente uno dei valori:
- \begin{errlist}
+{La funzione ritorna $0$ in caso di successo e direttamente un codice di
+ errore altrimenti, in tal caso \var{errno} non viene impostato, e si otterrà
+ direttamente uno dei valori:
+ \begin{errlist}
\item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
valido o non è aperto in scrittura.
\item[\errcode{EINVAL}] o \param{offset} o \param{len} sono minori di
l'operazione.
\item[\errcode{ESPIPE}] l'argomento \param{fd} è una \textit{pipe}.
\end{errlist}
- }
-\end{functions}
+}
+\end{funcproto}
La funzione assicura che venga allocato sufficiente spazio disco perché sia
possibile scrivere sul file indicato dall'argomento \param{fd} nella regione
Ci si può chiedere a cosa possa servire una funzione come
\func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
-eseguendo esplicitamente sul file la scrittura\footnote{usando \funcd{pwrite}
- per evitare spostamenti della posizione corrente sul file.} di una serie di
-zeri per l'estensione di spazio necessaria qualora il \itindex{sparse~file}
-file debba essere esteso o abbia dei \index{file!\textit{hole}}
-buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e che
- l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
- \itindex{sparse~file} \textit{sparse file} (vedi sez.~\ref{sec:file_lseek})
- senza una effettiva allocazione dello spazio disco.} In realtà questa è la
-modalità con cui la funzione veniva realizzata nella prima versione fornita
-dalle \acr{glibc}, per cui la funzione costituiva in sostanza soltanto una
-standardizzazione delle modalità di esecuzione di questo tipo di allocazioni.
+eseguendo esplicitamente sul file la scrittura di una serie di zeri (usando
+\funcd{pwrite} per evitare spostamenti della posizione corrente sul file) per
+l'estensione di spazio necessaria qualora il file debba essere esteso o abbia
+dei buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e
+ che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
+ \textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
+ allocazione dello spazio disco.} In realtà questa è la modalità con cui la
+funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
+cui la funzione costituiva in sostanza soltanto una standardizzazione delle
+modalità di esecuzione di questo tipo di allocazioni.
Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
scrittura su tutto lo spazio disco necessario, da fare al momento della
richiesta di allocazione, pagandone il conseguente prezzo in termini di
prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
spazio per poi andarci a scrivere, una sola volta, quando il contenuto finale
-diventa effettivamente disponibile.
-
-Per poter fare tutto questo è però necessario il supporto da parte del kernel,
-e questo è divenuto disponibile solo a partire dal kernel 2.6.23 in cui è
-stata introdotta la nuova \textit{system call} \func{fallocate},\footnote{non
- è detto che la funzione sia disponibile per tutti i filesystem, ad esempio
- per XFS il supporto è stato introdotto solo a partire dal kernel 2.6.25.}
-che consente di realizzare direttamente all'interno del kernel l'allocazione
-dello spazio disco così da poter realizzare una versione di
-\func{posix\_fallocate} con prestazioni molto più elevate.\footnote{nelle
- \acr{glibc} la nuova \textit{system call} viene sfruttata per la
- realizzazione di \func{posix\_fallocate} a partire dalla versione 2.10.}
+diventa effettivamente disponibile. Per poter fare tutto questo è però
+necessario il supporto da parte del kernel, e questo è divenuto disponibile
+solo a partire dal kernel 2.6.23 in cui è stata introdotta la nuova
+\textit{system call} \func{fallocate},\footnote{non è detto che la funzione
+ sia disponibile per tutti i filesystem, ad esempio per XFS il supporto è
+ stato introdotto solo a partire dal kernel 2.6.25.} che consente di
+realizzare direttamente all'interno del kernel l'allocazione dello spazio
+disco così da poter realizzare una versione di \func{posix\_fallocate} con
+prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
+viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
+dalla versione 2.10.
Trattandosi di una funzione di servizio, ed ovviamente disponibile
esclusivamente su Linux, inizialmente \funcd{fallocate} non era stata definita
sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
stato fornito un supporto esplicito; il suo prototipo è:
-\begin{functions}
- \headdecl{linux/fcntl.h}
- \funcdecl{int fallocate(int fd, int mode, off\_t offset, off\_t len)}
+\begin{funcproto}{
+\fhead{fcntl.h}
+\fdecl{int fallocate(int fd, int mode, off\_t offset, off\_t len)}
+\fdesc{Prealloca dello spazio disco per un file.}
+}
- Prealloca dello spazio disco per un file.
-
- \bodydesc{La funzione ritorna 0 in caso di successo e $-1$ in caso di errore,
- nel qual caso \var{errno} può assumere i valori:
- \begin{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{EBADF}] \param{fd} non fa riferimento ad un file descriptor
valido aperto in scrittura.
\item[\errcode{EFBIG}] la somma di \param{offset} e \param{len} eccede le
minore o uguale a zero.
\item[\errcode{ENODEV}] \param{fd} non fa riferimento ad un file ordinario
o a una directory.
- \item[\errcode{ENOSPC}] non c'è spazio disco sufficiente per l'operazione.
+ \item[\errcode{EPERM}] il file è immutabile o \textit{append-only} (vedi
+ sez.~\ref{sec:file_perm_overview}).
\item[\errcode{ENOSYS}] il filesystem contenente il file associato
a \param{fd} non supporta \func{fallocate}.
\item[\errcode{EOPNOTSUPP}] il filesystem contenente il file associato
a \param{fd} non supporta l'operazione \param{mode}.
- \end{errlist}
- ed inoltre \errval{EINTR}, \errval{EIO}.
-}
-\end{functions}
+ \end{errlist}
+ ed inoltre \errval{EINTR}, \errval{EIO} e \errval{ENOSPC} nel loro significato
+ generico.}
+\end{funcproto}
La funzione prende gli stessi argomenti di \func{posix\_fallocate} con lo
stesso significato, a cui si aggiunge l'argomento \param{mode} che indica le
-modalità di allocazione; al momento quest'ultimo può soltanto essere nullo o
-assumere il valore \const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la
-dimensione del file\footnote{quella ottenuta nel campo \var{st\_size} di una
- struttura \struct{stat} dopo una chiamata a \texttt{fstat}.} non venga
-modificata anche quando la somma di \param{offset} e \param{len} eccede la
-dimensione corrente.
-
-Se \param{mode} è nullo invece la dimensione totale del file in caso di
-estensione dello stesso viene aggiornata, come richiesto per
-\func{posix\_fallocate}, ed invocata in questo modo si può considerare
-\func{fallocate} come l'implementazione ottimale di \func{posix\_fallocate} a
-livello di kernel.
+modalità di allocazione; se questo è nullo il comportamento è identico a
+quello di \func{posix\_fallocate} e si può considerare \func{fallocate} come
+l'implementazione ottimale della stessa a livello di kernel.
+
+Inizialmente l'unico altro valore possibile per \param{mode} era
+\const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la dimensione del file (quella
+ottenuta nel campo \var{st\_size} di una struttura \struct{stat} dopo una
+chiamata a \texttt{fstat}) non venga modificata anche quando la somma
+di \param{offset} e \param{len} eccede la dimensione corrente, che serve
+quando si deve comunque preallocare dello spazio per scritture in append. In
+seguito sono stati introdotti altri valori, riassunti in
+tab.\ref{tab:fallocate_mode}, per compiere altre operazioni relative alla
+allocazione dello spazio disco dei file.
+
+\begin{table}[htb]
+ \centering
+ \footnotesize
+ \begin{tabular}[c]{|l|p{10cm}|}
+ \hline
+ \textbf{Valore} & \textbf{Significato} \\
+ \hline
+ \hline
+ \const{FALLOC\_FL\_INSERT} & .\\
+ \const{FALLOC\_FL\_COLLAPSE\_RANGE}& .\\
+ \const{FALLOC\_FL\_KEEP\_SIZE} & Mantiene invariata la dimensione del
+ file, pur allocando lo spazio disco anche
+ oltre la dimensione corrente del file.\\
+ \const{FALLOC\_FL\_PUNCH\_HOLE}& Crea un \textsl{buco} nel file (vedi
+ sez.~\ref{sec:file_lseek}) rendendolo una
+ \textit{sparse file} (dal kernel
+ 2.6.38).\\
+ \const{FALLOC\_FL\_ZERO\_RANGE}& .\\
+ \hline
+ \end{tabular}
+ \caption{Valori delle costanti usabili per l'argomento \param{mode} di
+ \func{fallocate}.}
+ \label{tab:fallocate_mode}
+\end{table}
+
+In particolare con \const{FALLOC\_FL\_PUNCH\_HOLE} è possibile scartare il
+contenuto della sezione di file indicata da \param{offser} e \param{len},
+creando un \textsl{buco} (si ricordi quanto detto in
+sez.~\ref{sec:file_lseek}); i blocchi del file interamente contenuti
+nell'intervallo verranno disallocati, la parte di intervallo contenuta
+parzialmente in altri blocchi verrà riempita con zeri e la lettura dal file
+restituirà degli zeri per tutto l'intervallo indicato. In sostanza si rende il
+file uno \textit{sparse file} a posteriori.
% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
% http://kernelnewbies.org/Linux_2_6_23