1 capacità \const{CAP\_LEASE}, vedi sez.~\ref{sec:proc_capabilities}) può
2 acquisire \textit{lease} su qualunque file.
4 Se su un file è presente un \textit{lease} quando il \textit{lease breaker}
5 esegue una \func{truncate} o una \func{open} che confligge con
6 esso,\footnote{in realtà \func{truncate} confligge sempre, mentre \func{open},
7 se eseguita in sola lettura, non confligge se si tratta di un \textit{read
8 lease}.} la funzione si blocca (a meno di non avere aperto il file con
9 \const{O\_NONBLOCK}, nel qual caso \func{open} fallirebbe con un errore di
10 \errcode{EWOULDBLOCK}) e viene eseguita la notifica al \textit{lease holder},
11 così che questo possa completare le sue operazioni sul file e rilasciare il
12 \textit{lease}. In sostanza con un \textit{read lease} si rilevano i
13 tentativi di accedere al file per modificarne i dati da parte di un altro
14 processo, mentre con un \textit{write lease} si rilevano anche i tentativi di
15 accesso in lettura. Si noti comunque che le operazioni di notifica avvengono
16 solo in fase di apertura del file e non sulle singole operazioni di lettura e
19 L'utilizzo dei \textit{file lease} consente al \textit{lease holder} di
20 assicurare la consistenza di un file, a seconda dei due casi, prima che un
21 altro processo inizi con le sue operazioni di scrittura o di lettura su di
22 esso. In genere un \textit{lease holder} che riceve una notifica deve
23 provvedere a completare le necessarie operazioni (ad esempio scaricare
24 eventuali buffer), per poi rilasciare il \textit{lease} così che il
25 \textit{lease breaker} possa eseguire le sue operazioni. Questo si fa con il
26 comando \const{F\_SETLEASE}, o rimuovendo il \textit{lease} con
27 \const{F\_UNLCK}, o, nel caso di \textit{write lease} che confligge con una
28 operazione di lettura, declassando il \textit{lease} a lettura con
31 Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro
32 il numero di secondi specificato dal parametro di sistema mantenuto in
33 \sysctlfile{fs/lease-break-time} sarà il kernel stesso a rimuoverlo o
34 declassarlo automaticamente (questa è una misura di sicurezza per evitare che
35 un processo blocchi indefinitamente l'accesso ad un file acquisendo un
36 \textit{lease}). Una volta che un \textit{lease} è stato rilasciato o
37 declassato (che questo sia fatto dal \textit{lease holder} o dal kernel è lo
38 stesso) le chiamate a \func{open} o \func{truncate} eseguite dal \textit{lease
39 breaker} rimaste bloccate proseguono automaticamente.
41 Benché possa risultare utile per sincronizzare l'accesso ad uno stesso file da
42 parte di più processi, l'uso dei \textit{file lease} non consente comunque di
43 risolvere il problema di rilevare automaticamente quando un file o una
44 directory vengono modificati,\footnote{questa funzionalità venne aggiunta
45 principalmente ad uso di Samba per poter facilitare l'emulazione del
46 comportamento di Windows sui file, ma ad oggi viene considerata una
47 interfaccia mal progettata ed il suo uso è fortemente sconsigliato a favore
48 di \textit{inotify}.} che è quanto necessario ad esempio ai programma di
49 gestione dei file dei vari desktop grafici.
53 Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata
54 un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia
55 specifica di Linux che deve essere evitata se si vogliono scrivere programmi
56 portabili, e che le funzionalità illustrate sono disponibili soltanto se è
57 stata definita la macro \macro{\_GNU\_SOURCE}.} chiamata \textit{dnotify},
58 che consente di richiedere una notifica quando una directory, o uno qualunque
59 dei file in essa contenuti, viene modificato. Come per i \textit{file lease}
60 la notifica avviene di default attraverso il segnale \signal{SIGIO}, ma se ne
61 può utilizzare un altro, e di nuovo, per le ragioni già esposte in precedenza,
62 è opportuno che si utilizzino dei segnali \textit{real-time}. Inoltre, come
63 in precedenza, si potrà ottenere nel gestore del segnale il file descriptor
64 che è stato modificato tramite il contenuto della struttura
72 \begin{tabular}[c]{|l|p{8cm}|}
74 \textbf{Valore} & \textbf{Significato} \\
77 \const{DN\_ACCESS} & Un file è stato acceduto, con l'esecuzione di una fra
78 \func{read}, \func{pread}, \func{readv}.\\
79 \const{DN\_MODIFY} & Un file è stato modificato, con l'esecuzione di una
80 fra \func{write}, \func{pwrite}, \func{writev},
81 \func{truncate}, \func{ftruncate}.\\
82 \const{DN\_CREATE} & È stato creato un file nella directory, con
83 l'esecuzione di una fra \func{open}, \func{creat},
84 \func{mknod}, \func{mkdir}, \func{link},
85 \func{symlink}, \func{rename} (da un'altra
87 \const{DN\_DELETE} & È stato cancellato un file dalla directory con
88 l'esecuzione di una fra \func{unlink}, \func{rename}
89 (su un'altra directory), \func{rmdir}.\\
90 \const{DN\_RENAME} & È stato rinominato un file all'interno della
91 directory (con \func{rename}).\\
92 \const{DN\_ATTRIB} & È stato modificato un attributo di un file con
93 l'esecuzione di una fra \func{chown}, \func{chmod},
95 \const{DN\_MULTISHOT}& Richiede una notifica permanente di tutti gli
99 \caption{Le costanti che identificano le varie classi di eventi per i quali
100 si richiede la notifica con il comando \const{F\_NOTIFY} di \func{fcntl}.}
101 \label{tab:file_notify}
104 Ci si può registrare per le notifiche dei cambiamenti al contenuto di una
105 certa directory eseguendo la funzione \func{fcntl} su un file descriptor
106 associato alla stessa con il comando \const{F\_NOTIFY}. In questo caso
107 l'argomento \param{arg} di \func{fcntl} serve ad indicare per quali classi
108 eventi si vuole ricevere la notifica, e prende come valore una maschera
109 binaria composta dall'OR aritmetico di una o più delle costanti riportate in
110 tab.~\ref{tab:file_notify}.
112 A meno di non impostare in maniera esplicita una notifica permanente usando il
113 valore \const{DN\_MULTISHOT}, la notifica è singola: viene cioè inviata una
114 sola volta quando si verifica uno qualunque fra gli eventi per i quali la si è
115 richiesta. Questo significa che un programma deve registrarsi un'altra volta
116 se desidera essere notificato di ulteriori cambiamenti. Se si eseguono diverse
117 chiamate con \const{F\_NOTIFY} e con valori diversi per \param{arg} questi
118 ultimi si \textsl{accumulano}; cioè eventuali nuovi classi di eventi
119 specificate in chiamate successive vengono aggiunte a quelle già impostate
120 nelle precedenti. Se si vuole rimuovere la notifica si deve invece
121 specificare un valore nullo.
125 Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve
126 usare un file descriptor per ciascuna directory che si vuole tenere sotto
127 controllo, il che porta facilmente ad avere un eccesso di file aperti. Inoltre
128 quando la directory che si controlla è all'interno di un dispositivo
129 rimovibile, mantenere il relativo file descriptor aperto comporta
130 l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere
131 complica notevolmente la gestione dell'uso di questi dispositivi.
133 Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di
134 tenere sotto controllo il contenuto di una directory; la modifica di un file
135 viene segnalata, ma poi è necessario verificare di quale file si tratta
136 (operazione che può essere molto onerosa quando una directory contiene un gran
137 numero di file). Infine l'uso dei segnali come interfaccia di notifica
138 comporta tutti i problemi di gestione visti in sez.~\ref{sec:sig_management} e
139 sez.~\ref{sec:sig_adv_control}. Per tutta questa serie di motivi in generale
140 quella di \textit{dnotify} viene considerata una interfaccia di usabilità
141 problematica ed il suo uso oggi è fortemente sconsigliato.
145 Per risolvere i problemi appena illustrati è stata introdotta una nuova
146 interfaccia per l'osservazione delle modifiche a file o directory, chiamata
147 \textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel
148 2.6.13, le relative funzioni sono state introdotte nelle glibc 2.4.} Anche
149 questa è una interfaccia specifica di Linux (pertanto non deve essere usata se
150 si devono scrivere programmi portabili), ed è basata sull'uso di una coda di
151 notifica degli eventi associata ad un singolo file descriptor, il che permette
152 di risolvere il principale problema di \itindex{dnotify} \textit{dnotify}. La
153 coda viene creata attraverso la funzione di sistema \funcd{inotify\_init}, il
157 \fhead{sys/inotify.h}
158 \fdecl{int inotify\_init(void)}
159 \fdesc{Inizializza una istanza di \textit{inotify}.}
162 {La funzione ritornaun file descriptor in caso di successo, o $-1$ in caso di
163 errore, nel qual caso \var{errno} assumerà uno dei valori:
165 \item[\errcode{EMFILE}] si è raggiunto il numero massimo di istanze di
166 \textit{inotify} consentite all'utente.
167 \item[\errcode{ENFILE}] si è raggiunto il massimo di file descriptor aperti
169 \item[\errcode{ENOMEM}] non c'è sufficiente memoria nel kernel per creare
175 La funzione non prende alcun argomento; inizializza una istanza di
176 \textit{inotify} e restituisce un file descriptor attraverso il quale verranno
177 effettuate le operazioni di notifica; si tratta di un file descriptor speciale
178 che non è associato a nessun file su disco, e che viene utilizzato solo per
179 notificare gli eventi che sono stati posti in osservazione. Per evitare abusi
180 delle risorse di sistema è previsto che un utente possa utilizzare un numero
181 limitato di istanze di \textit{inotify}; il valore di default del limite è di
182 128, ma questo valore può essere cambiato con \func{sysctl} o usando il file
183 \sysctlfile{fs/inotify/max\_user\_instances}.
185 Dato che questo file descriptor non è associato a nessun file o directory
186 reale, l'inconveniente di non poter smontare un filesystem i cui file sono
187 tenuti sotto osservazione viene completamente eliminato; anzi, una delle
188 capacità dell'interfaccia di \textit{inotify} è proprio quella di notificare
189 il fatto che il filesystem su cui si trova il file o la directory osservata è
192 Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà
193 essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e
194 con l'interfaccia di \textit{epoll}, ed a partire dal kernel 2.6.25 è stato
195 introdotto anche il supporto per il \itindex{signal~driven~I/O}
196 \texttt{signal-driven I/O}. Siccome gli eventi vengono notificati come dati
197 disponibili in lettura, dette funzioni ritorneranno tutte le volte che si avrà
198 un evento di notifica.
200 Così, invece di dover utilizzare i segnali, considerati una pessima scelta dal
201 punto di vista dell'interfaccia utente, si potrà gestire l'osservazione degli
202 eventi con una qualunque delle modalità di \textit{I/O multiplexing}
203 illustrate in sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare
204 l'osservazione, sarà sufficiente chiudere il file descriptor e tutte le
205 risorse allocate saranno automaticamente rilasciate. Infine l'interfaccia di
206 \textit{inotify} consente di mettere sotto osservazione, oltre che una
207 directory, anche singoli file.
209 Una volta creata la coda di notifica si devono definire gli eventi da tenere
210 sotto osservazione; questo viene fatto attraverso una \textsl{lista di
211 osservazione} (o \textit{watch list}) che è associata alla coda. Per gestire
212 la lista di osservazione l'interfaccia fornisce due funzioni di sistema, la
213 prima di queste è \funcd{inotify\_add\_watch}, il cui prototipo è:
216 \fhead{sys/inotify.h}
217 \fdecl{int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)}
218 \fdesc{Aggiunge un evento di osservazione a una lista di osservazione.}
221 {La funzione ritorna un valore positivo in caso di successo, o $-1$ per un
222 errore, nel qual caso \var{errno} assumerà uno dei valori:
224 \item[\errcode{EACCES}] non si ha accesso in lettura al file indicato.
225 \item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd}
226 non è un file descriptor di \textit{inotify}.
227 \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di
228 osservazione o il kernel non ha potuto allocare una risorsa necessaria.
230 ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF} nel loro
231 significato generico.}
234 La funzione consente di creare un ``\textsl{osservatore}'' (il cosiddetto
235 ``\textit{watch}'') nella lista di osservazione di una coda di notifica, che
236 deve essere indicata specificando il file descriptor ad essa associato
237 nell'argomento \param{fd}, che ovviamente dovrà essere un file descriptor
238 creato con \func{inotify\_init}. Il file o la directory da porre sotto
239 osservazione vengono invece indicati per nome, da passare
240 nell'argomento \param{pathname}. Infine il terzo argomento, \param{mask},
241 indica che tipo di eventi devono essere tenuti sotto osservazione e le
242 modalità della stessa. L'operazione può essere ripetuta per tutti i file e le
243 directory che si vogliono tenere sotto osservazione,\footnote{anche in questo
244 caso c'è un limite massimo che di default è pari a 8192, ed anche questo
245 valore può essere cambiato con \func{sysctl} o usando il file
246 \sysctlfile{fs/inotify/max\_user\_watches}.} e si utilizzerà sempre un solo
249 Il tipo di evento che si vuole osservare deve essere specificato
250 nell'argomento \param{mask} come maschera binaria, combinando i valori delle
251 costanti riportate in tab.~\ref{tab:inotify_event_watch} che identificano i
252 singoli bit della maschera ed il relativo significato. In essa si sono marcati
253 con un ``$\bullet$'' gli eventi che, quando specificati per una directory,
254 vengono osservati anche su tutti i file che essa contiene. Nella seconda
255 parte della tabella si sono poi indicate alcune combinazioni predefinite dei
256 flag della prima parte.
261 \begin{tabular}[c]{|l|c|p{8cm}|}
263 \textbf{Valore} & & \textbf{Significato} \\
266 \const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in
268 \const{IN\_ATTRIB} &$\bullet$& Ci sono stati cambiamenti sui dati
269 dell'\itindex{inode} \textit{inode}
270 (o sugli attributi estesi, vedi
271 sez.~\ref{sec:file_xattr}).\\
272 \const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in
274 \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in
276 \const{IN\_CREATE} &$\bullet$& È stato creato un file o una
277 directory in una directory sotto
279 \const{IN\_DELETE} &$\bullet$& È stato cancellato un file o una
280 directory in una directory sotto
282 \const{IN\_DELETE\_SELF} & -- & È stato cancellato il file (o la
283 directory) sotto osservazione.\\
284 \const{IN\_MODIFY} &$\bullet$& È stato modificato il file.\\
285 \const{IN\_MOVE\_SELF} & & È stato rinominato il file (o la
286 directory) sotto osservazione.\\
287 \const{IN\_MOVED\_FROM} &$\bullet$& Un file è stato spostato fuori dalla
288 directory sotto osservazione.\\
289 \const{IN\_MOVED\_TO} &$\bullet$& Un file è stato spostato nella
290 directory sotto osservazione.\\
291 \const{IN\_OPEN} &$\bullet$& Un file è stato aperto.\\
293 \const{IN\_CLOSE} & & Combinazione di
294 \const{IN\_CLOSE\_WRITE} e
295 \const{IN\_CLOSE\_NOWRITE}.\\
296 \const{IN\_MOVE} & & Combinazione di
297 \const{IN\_MOVED\_FROM} e
298 \const{IN\_MOVED\_TO}.\\
299 \const{IN\_ALL\_EVENTS} & & Combinazione di tutti i flag
303 \caption{Le costanti che identificano i bit della maschera binaria
304 dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano il
305 tipo di evento da tenere sotto osservazione.}
306 \label{tab:inotify_event_watch}
309 Oltre ai flag di tab.~\ref{tab:inotify_event_watch}, che indicano il tipo di
310 evento da osservare e che vengono utilizzati anche in uscita per indicare il
311 tipo di evento avvenuto, \func{inotify\_add\_watch} supporta ulteriori
312 flag,\footnote{i flag \const{IN\_DONT\_FOLLOW}, \const{IN\_MASK\_ADD} e
313 \const{IN\_ONLYDIR} sono stati introdotti a partire dalle glibc 2.5, se si
314 usa la versione 2.4 è necessario definirli a mano.} riportati in
315 tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di
316 osservazione (da passare sempre nell'argomento \param{mask}) e che al
317 contrario dei precedenti non vengono mai impostati nei risultati in uscita.
322 \begin{tabular}[c]{|l|p{8cm}|}
324 \textbf{Valore} & \textbf{Significato} \\
327 \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un
329 \const{IN\_MASK\_ADD} & Aggiunge a quelli già impostati i flag indicati
330 nell'argomento \param{mask}, invece di
332 \const{IN\_ONESHOT} & Esegue l'osservazione su \param{pathname} per una
333 sola volta, rimuovendolo poi dalla \textit{watch
335 \const{IN\_ONLYDIR} & Se \param{pathname} è una directory riporta
336 soltanto gli eventi ad essa relativi e non
337 quelli per i file che contiene.\\
340 \caption{Le costanti che identificano i bit della maschera binaria
341 dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano le
342 modalità di osservazione.}
343 \label{tab:inotify_add_watch_flag}
346 Se non esiste nessun \textit{watch} per il file o la directory specificata
347 questo verrà creato per gli eventi specificati dall'argomento \param{mask},
348 altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che
349 non si sia usato il flag \const{IN\_MASK\_ADD}, nel qual caso gli eventi
350 specificati saranno aggiunti a quelli già presenti.
352 Come accennato quando si tiene sotto osservazione una directory vengono
353 restituite le informazioni sia riguardo alla directory stessa che ai file che
354 essa contiene; questo comportamento può essere disabilitato utilizzando il
355 flag \const{IN\_ONLYDIR}, che richiede di riportare soltanto gli eventi
356 relativi alla directory stessa. Si tenga presente inoltre che quando si
357 osserva una directory vengono riportati solo gli eventi sui file che essa
358 contiene direttamente, non quelli relativi a file contenuti in eventuali
359 sottodirectory; se si vogliono osservare anche questi sarà necessario creare
360 ulteriori \textit{watch} per ciascuna sottodirectory.
362 Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica
363 singola;\footnote{questa funzionalità però è disponibile soltanto a partire dal
364 kernel 2.6.16.} una volta verificatosi uno qualunque fra gli eventi
365 richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà
366 automaticamente rimosso dalla lista di osservazione e nessun ulteriore evento
369 In caso di successo \func{inotify\_add\_watch} ritorna un intero positivo,
370 detto \textit{watch descriptor}, che identifica univocamente un
371 \textsl{osservatore} su una coda di notifica; esso viene usato per farvi
372 riferimento sia riguardo i risultati restituiti da \textit{inotify}, che per
373 la eventuale rimozione dello stesso.
375 La seconda funzione di sistema per la gestione delle code di notifica, che
376 permette di rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch},
377 ed il suo prototipo è:
380 \fhead{sys/inotify.h}
381 \fdecl{int inotify\_rm\_watch(int fd, uint32\_t wd)}
382 \fdesc{Rimuove un \textsl{osservatore} da una coda di notifica.}
385 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
386 caso \var{errno} assumerà uno dei valori:
388 \item[\errcode{EBADF}] non si è specificato in \param{fd} un file descriptor
390 \item[\errcode{EINVAL}] il valore di \param{wd} non è corretto, o \param{fd}
391 non è associato ad una coda di notifica.
396 La funzione rimuove dalla coda di notifica identificata dall'argomento
397 \param{fd} l'osservatore identificato dal \textit{watch descriptor}
398 \param{wd}; ovviamente deve essere usato per questo argomento un valore
399 ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore di
400 \errval{EINVAL}. In caso di successo della rimozione, contemporaneamente alla
401 cancellazione dell'osservatore, sulla coda di notifica verrà generato un
402 evento di tipo \const{IN\_IGNORED} (vedi
403 tab.~\ref{tab:inotify_read_event_flag}). Si tenga presente che se un file
404 viene cancellato o un filesystem viene smontato i relativi osservatori vengono
405 rimossi automaticamente e non è necessario utilizzare
406 \func{inotify\_rm\_watch}.
408 Come accennato l'interfaccia di \textit{inotify} prevede che gli eventi siano
409 notificati come dati presenti in lettura sul file descriptor associato alla
410 coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file
411 con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di
412 una o più strutture di tipo \struct{inotify\_event} (la cui definizione è
413 riportata in fig.~\ref{fig:inotify_event}). Qualora non siano presenti dati la
414 \func{read} si bloccherà (a meno di non aver impostato il file descriptor in
415 modalità non bloccante) fino all'arrivo di almeno un evento.
418 \footnotesize \centering
419 \begin{minipage}[c]{0.90\textwidth}
420 \includestruct{listati/inotify_event.h}
423 \caption{La struttura \structd{inotify\_event} usata dall'interfaccia di
424 \textit{inotify} per riportare gli eventi.}
425 \label{fig:inotify_event}
428 Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa
429 permette di ottenere con \func{ioctl}, come per i file descriptor associati ai
430 socket (si veda sez.~\ref{sec:sock_ioctl_IP}), il numero di byte disponibili
431 in lettura sul file descriptor, utilizzando su di esso l'operazione
432 \const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file
433 (vedi sez.~\ref{sec:file_fcntl_ioctl}), che è disponibile solo per i socket
434 e per i file descriptor creati con \func{inotify\_init}.} Si può così
435 utilizzare questa operazione, oltre che per predisporre una operazione di
436 lettura con un buffer di dimensioni adeguate, anche per ottenere rapidamente
437 il numero di file che sono cambiati.
439 Una volta effettuata la lettura con \func{read} a ciascun evento sarà
440 associata una struttura \struct{inotify\_event} contenente i rispettivi dati.
441 Per identificare a quale file o directory l'evento corrisponde viene
442 restituito nel campo \var{wd} il \textit{watch descriptor} con cui il relativo
443 osservatore è stato registrato. Il campo \var{mask} contiene invece una
444 maschera di bit che identifica il tipo di evento verificatosi; in essa
445 compariranno sia i bit elencati nella prima parte di
446 tab.~\ref{tab:inotify_event_watch}, che gli eventuali valori aggiuntivi di
447 tab.~\ref{tab:inotify_read_event_flag} (questi compaiono solo nel campo
448 \var{mask} di \struct{inotify\_event}, e non sono utilizzabili in fase di
449 registrazione dell'osservatore).
454 \begin{tabular}[c]{|l|p{10cm}|}
456 \textbf{Valore} & \textbf{Significato} \\
459 \const{IN\_IGNORED} & L'osservatore è stato rimosso, sia in maniera
460 esplicita con l'uso di \func{inotify\_rm\_watch},
461 che in maniera implicita per la rimozione
462 dell'oggetto osservato o per lo smontaggio del
463 filesystem su cui questo si trova.\\
464 \const{IN\_ISDIR} & L'evento avvenuto fa riferimento ad una directory
465 (consente così di distinguere, quando si pone
466 sotto osservazione una directory, fra gli eventi
467 relativi ad essa e quelli relativi ai file che
469 \const{IN\_Q\_OVERFLOW}& Si sono eccedute le dimensioni della coda degli
470 eventi (\textit{overflow} della coda); in questo
471 caso il valore di \var{wd} è $-1$.\footnotemark\\
472 \const{IN\_UNMOUNT} & Il filesystem contenente l'oggetto posto sotto
473 osservazione è stato smontato.\\
476 \caption{Le costanti che identificano i bit aggiuntivi usati nella maschera
477 binaria del campo \var{mask} di \struct{inotify\_event}.}
478 \label{tab:inotify_read_event_flag}
481 \footnotetext{la coda di notifica ha una dimensione massima che viene
482 controllata dal parametro di sistema
483 \sysctlfile{fs/inotify/max\_queued\_events}, che indica il numero massimo di
484 eventi che possono essere mantenuti sulla stessa; quando detto valore viene
485 ecceduto gli ulteriori eventi vengono scartati, ma viene comunque generato
486 un evento di tipo \const{IN\_Q\_OVERFLOW}.}
488 Il campo \var{cookie} contiene invece un intero univoco che permette di
489 identificare eventi correlati (per i quali avrà lo stesso valore), al momento
490 viene utilizzato soltanto per rilevare lo spostamento di un file, consentendo
491 così all'applicazione di collegare la corrispondente coppia di eventi
492 \const{IN\_MOVED\_TO} e \const{IN\_MOVED\_FROM}.
494 Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando
495 l'evento è relativo ad un file presente in una directory posta sotto
496 osservazione, in tal caso essi contengono rispettivamente il nome del file
497 (come \itindsub{pathname}{relativo} \textit{pathname} relativo alla directory
498 osservata) e la relativa dimensione in byte. Il campo \var{name} viene sempre
499 restituito come stringa terminata da NUL, con uno o più zeri di terminazione,
500 a seconda di eventuali necessità di allineamento del risultato, ed il valore
501 di \var{len} corrisponde al totale della dimensione di \var{name}, zeri
502 aggiuntivi compresi. La stringa con il nome del file viene restituita nella
503 lettura subito dopo la struttura \struct{inotify\_event}; questo significa che
504 le dimensioni di ciascun evento di \textit{inotify} saranno pari a
505 \code{sizeof(\struct{inotify\_event}) + len}.
507 Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un
508 semplice programma che permette di mettere sotto osservazione uno o più file e
509 directory. Il programma si chiama \texttt{inotify\_monitor.c} ed il codice
510 completo è disponibile coi sorgenti allegati alla guida, il corpo principale
511 del programma, che non contiene la sezione di gestione delle opzioni e le
512 funzioni di ausilio è riportato in fig.~\ref{fig:inotify_monitor_example}.
514 \begin{figure}[!htbp]
515 \footnotesize \centering
516 \begin{minipage}[c]{\codesamplewidth}
517 \includecodesample{listati/inotify_monitor.c}
520 \caption{Esempio di codice che usa l'interfaccia di \textit{inotify}.}
521 \label{fig:inotify_monitor_example}
524 Una volta completata la scansione delle opzioni il corpo del programma inizia
525 controllando (\texttt{\small 11-15}) che sia rimasto almeno un argomento che
526 indichi quale file o directory mettere sotto osservazione (e qualora questo
527 non avvenga esce stampando la pagina di aiuto); dopo di che passa
528 (\texttt{\small 16-20}) all'inizializzazione di \textit{inotify} ottenendo con
529 \func{inotify\_init} il relativo file descriptor (o si esce in caso di
532 Il passo successivo è aggiungere (\texttt{\small 21-30}) alla coda di
533 notifica gli opportuni osservatori per ciascuno dei file o directory indicati
534 all'invocazione del comando; questo viene fatto eseguendo un ciclo
535 (\texttt{\small 22-29}) fintanto che la variabile \var{i}, inizializzata a
536 zero (\texttt{\small 21}) all'inizio del ciclo, è minore del numero totale di
537 argomenti rimasti. All'interno del ciclo si invoca (\texttt{\small 23})
538 \func{inotify\_add\_watch} per ciascuno degli argomenti, usando la maschera
539 degli eventi data dalla variabile \var{mask} (il cui valore viene impostato
540 nella scansione delle opzioni), in caso di errore si esce dal programma
541 altrimenti si incrementa l'indice (\texttt{\small 29}).
543 Completa l'inizializzazione di \textit{inotify} inizia il ciclo principale
544 (\texttt{\small 32-56}) del programma, nel quale si resta in attesa degli
545 eventi che si intendono osservare. Questo viene fatto eseguendo all'inizio del
546 ciclo (\texttt{\small 33}) una \func{read} che si bloccherà fintanto che non
547 si saranno verificati eventi.
549 Dato che l'interfaccia di \textit{inotify} può riportare anche più eventi in
550 una sola lettura, si è avuto cura di passare alla \func{read} un buffer di
551 dimensioni adeguate, inizializzato in (\texttt{\small 7}) ad un valore di
552 approssimativamente 512 eventi (si ricordi che la quantità di dati restituita
553 da \textit{inotify} è variabile a causa della diversa lunghezza del nome del
554 file restituito insieme a \struct{inotify\_event}). In caso di errore di
555 lettura (\texttt{\small 35-40}) il programma esce con un messaggio di errore
556 (\texttt{\small 37-39}), a meno che non si tratti di una interruzione della
557 \textit{system call}, nel qual caso (\texttt{\small 36}) si ripete la lettura.
559 Se la lettura è andata a buon fine invece si esegue un ciclo (\texttt{\small
560 43-52}) per leggere tutti gli eventi restituiti, al solito si inizializza
561 l'indice \var{i} a zero (\texttt{\small 42}) e si ripetono le operazioni
562 (\texttt{\small 43}) fintanto che esso non supera il numero di byte restituiti
563 in lettura. Per ciascun evento all'interno del ciclo si assegna alla variabile
564 \var{event} (si noti come si sia eseguito un opportuno \textit{casting} del
565 puntatore) l'indirizzo nel buffer della corrispondente struttura
566 \struct{inotify\_event} (\texttt{\small 44}), e poi si stampano il numero di
567 \textit{watch descriptor} (\texttt{\small 45}) ed il file a cui questo fa
568 riferimento (\texttt{\small 46}), ricavato dagli argomenti passati a riga di
569 comando sfruttando il fatto che i \textit{watch descriptor} vengono assegnati
570 in ordine progressivo crescente a partire da 1.
572 Qualora sia presente il riferimento ad un nome di file associato all'evento lo
573 si stampa (\texttt{\small 47-49}); si noti come in questo caso si sia
574 controllato il valore del campo \var{event->len} e non il fatto che
575 \var{event->name} riporti o meno un puntatore nullo. L'interfaccia infatti,
576 qualora il nome non sia presente, non tocca il campo \var{event->name}, che
577 si troverà pertanto a contenere quello che era precedentemente presente nella
578 rispettiva locazione di memoria, nel caso più comune il puntatore al nome di
579 un file osservato in precedenza.
581 Si utilizza poi (\texttt{\small 50}) la funzione \code{printevent}, che
582 interpreta il valore del campo \var{event->mask}, per stampare il tipo di
583 eventi accaduti.\footnote{per il relativo codice, che non riportiamo in quanto
584 non essenziale alla comprensione dell'esempio, si possono utilizzare
585 direttamente i sorgenti allegati alla guida.} Infine (\texttt{\small 51}) si
586 provvede ad aggiornare l'indice \var{i} per farlo puntare all'evento
589 Se adesso usiamo il programma per mettere sotto osservazione una directory, e
590 da un altro terminale eseguiamo il comando \texttt{ls} otterremo qualcosa del
593 piccardi@gethen:~/gapil/sources$ \textbf{./inotify_monitor -a /home/piccardi/gapil/}
595 Observed event on /home/piccardi/gapil/
598 Observed event on /home/piccardi/gapil/
603 I lettori più accorti si saranno resi conto che nel ciclo di lettura degli
604 eventi appena illustrato non viene trattato il caso particolare in cui la
605 funzione \func{read} restituisce in \var{nread} un valore nullo. Lo si è fatto
606 perché con \textit{inotify} il ritorno di una \func{read} con un valore nullo
607 avviene soltanto, come forma di avviso, quando si sia eseguita la funzione
608 specificando un buffer di dimensione insufficiente a contenere anche un solo
609 evento. Nel nostro caso le dimensioni erano senz'altro sufficienti, per cui
610 tale evenienza non si verificherà mai.
612 Ci si potrà però chiedere cosa succede se il buffer è sufficiente per un
613 evento, ma non per tutti gli eventi verificatisi. Come si potrà notare nel
614 codice illustrato in precedenza non si è presa nessuna precauzione per
615 verificare che non ci fossero stati troncamenti dei dati. Anche in questo caso
616 il comportamento scelto è corretto, perché l'interfaccia di \textit{inotify}
617 garantisce automaticamente, anche quando ne sono presenti in numero maggiore,
618 di restituire soltanto il numero di eventi che possono rientrare completamente
619 nelle dimensioni del buffer specificato.\footnote{si avrà cioè, facendo
620 riferimento sempre al codice di fig.~\ref{fig:inotify_monitor_example}, che
621 \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale
622 soltanto qualora gli eventi corrispondano esattamente alle dimensioni di
623 quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che
624 entrano interamente nel buffer e gli altri saranno restituiti alla successiva
625 chiamata di \func{read}.
627 Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli
628 eventi restituiti nella lettura formano una sequenza ordinata, è cioè
629 garantito che se si esegue uno spostamento di un file gli eventi vengano
630 generati nella sequenza corretta. L'interfaccia garantisce anche che se si
631 verificano più eventi consecutivi identici (vale a dire con gli stessi valori
632 dei campi \var{wd}, \var{mask}, \var{cookie}, e \var{name}) questi vengono
633 raggruppati in un solo evento.
637 % TODO trattare fanotify, vedi http://lwn.net/Articles/339399/ e
638 % http://lwn.net/Articles/343346/ (incluso nel 2.6.36)
641 \subsection{L'interfaccia POSIX per l'I/O asincrono}
642 \label{sec:file_asyncronous_io}
644 Una modalità alternativa all'uso dell'\textit{I/O multiplexing} per gestione
645 dell'I/O simultaneo su molti file è costituita dal cosiddetto \textsl{I/O
646 asincrono} o ``AIO''. Il concetto base dell'\textsl{I/O asincrono} è che le
647 funzioni di I/O non attendono il completamento delle operazioni prima di
648 ritornare, così che il processo non viene bloccato. In questo modo diventa ad
649 esempio possibile effettuare una richiesta preventiva di dati, in modo da
650 poter effettuare in contemporanea le operazioni di calcolo e quelle di I/O.
652 Benché la modalità di apertura asincrona di un file vista in
653 sez.~\ref{sec:signal_driven_io} possa risultare utile in varie occasioni (in
654 particolar modo con i socket e gli altri file per i quali le funzioni di I/O
655 sono \index{system~call~lente} \textit{system call} lente), essa è comunque
656 limitata alla notifica della disponibilità del file descriptor per le
657 operazioni di I/O, e non ad uno svolgimento asincrono delle medesime. Lo
658 standard POSIX.1b definisce una interfaccia apposita per l'I/O asincrono vero
659 e proprio,\footnote{questa è stata ulteriormente perfezionata nelle successive
660 versioni POSIX.1-2001 e POSIX.1-2008.} che prevede un insieme di funzioni
661 dedicate per la lettura e la scrittura dei file, completamente separate
662 rispetto a quelle usate normalmente.
664 In generale questa interfaccia è completamente astratta e può essere
665 implementata sia direttamente nel kernel che in \textit{user space} attraverso
666 l'uso di \itindex{thread} \textit{thread}. Per le versioni del kernel meno
667 recenti esiste una implementazione di questa interfaccia fornita completamente
668 delle \acr{glibc} a partire dalla versione 2.1, che è realizzata completamente
669 in \textit{user space}, ed è accessibile linkando i programmi con la libreria
670 \file{librt}. A partire dalla versione 2.5.32 è stato introdotto nel kernel
671 una nuova infrastruttura per l'I/O asincrono, ma ancora il supporto è parziale
672 ed insufficiente ad implementare tutto l'AIO POSIX.
674 Lo standard POSIX prevede che tutte le operazioni di I/O asincrono siano
675 controllate attraverso l'uso di una apposita struttura \struct{aiocb} (il cui
676 nome sta per \textit{asyncronous I/O control block}), che viene passata come
677 argomento a tutte le funzioni dell'interfaccia. La sua definizione, come
678 effettuata in \headfile{aio.h}, è riportata in
679 fig.~\ref{fig:file_aiocb}. Nello steso file è definita la macro
680 \macro{\_POSIX\_ASYNCHRONOUS\_IO}, che dichiara la disponibilità
681 dell'interfaccia per l'I/O asincrono.
684 \footnotesize \centering
685 \begin{minipage}[c]{0.90\textwidth}
686 \includestruct{listati/aiocb.h}
689 \caption{La struttura \structd{aiocb}, usata per il controllo dell'I/O
691 \label{fig:file_aiocb}
694 Le operazioni di I/O asincrono possono essere effettuate solo su un file già
695 aperto; il file deve inoltre supportare la funzione \func{lseek}, pertanto
696 terminali e \textit{pipe} sono esclusi. Non c'è limite al numero di operazioni
697 contemporanee effettuabili su un singolo file. Ogni operazione deve
698 inizializzare opportunamente un \textit{control block}. Il file descriptor su
699 cui operare deve essere specificato tramite il campo \var{aio\_fildes}; dato
700 che più operazioni possono essere eseguita in maniera asincrona, il concetto
701 di posizione corrente sul file viene a mancare; pertanto si deve sempre
702 specificare nel campo \var{aio\_offset} la posizione sul file da cui i dati
703 saranno letti o scritti. Nel campo \var{aio\_buf} deve essere specificato
704 l'indirizzo del buffer usato per l'I/O, ed in \var{aio\_nbytes} la lunghezza
705 del blocco di dati da trasferire.
707 Il campo \var{aio\_reqprio} permette di impostare la priorità delle operazioni
708 di I/O, in generale perché ciò sia possibile occorre che la piattaforma
709 supporti questa caratteristica, questo viene indicato dal fatto che le macro
710 \macro{\_POSIX\_PRIORITIZED\_IO}, e \macro{\_POSIX\_PRIORITY\_SCHEDULING} sono
711 definite. La priorità viene impostata a partire da quella del processo
712 chiamante (vedi sez.~\ref{sec:proc_priority}), cui viene sottratto il valore
713 di questo campo. Il campo \var{aio\_lio\_opcode} è usato solo dalla funzione
714 \func{lio\_listio}, che, come vedremo, permette di eseguire con una sola
715 chiamata una serie di operazioni, usando un vettore di \textit{control
716 block}. Tramite questo campo si specifica quale è la natura di ciascuna di
719 Infine il campo \var{aio\_sigevent} è una struttura di tipo \struct{sigevent}
720 (illustrata in in fig.~\ref{fig:struct_sigevent}) che serve a specificare il
721 modo in cui si vuole che venga effettuata la notifica del completamento delle
722 operazioni richieste; per la trattazione delle modalità di utilizzo della
723 stessa si veda quanto già visto in proposito in sez.~\ref{sec:sig_timer_adv}.
725 Le due funzioni base dell'interfaccia per l'I/O asincrono sono
726 \funcd{aio\_read} ed \funcd{aio\_write}. Esse permettono di richiedere una
727 lettura od una scrittura asincrona di dati usando la struttura \struct{aiocb}
728 appena descritta; i rispettivi prototipi sono:
732 \fdecl{int aio\_read(struct aiocb *aiocbp)}
733 \fdesc{Richiede una lettura asincrona.}
734 \fdecl{int aio\_write(struct aiocb *aiocbp)}
735 \fdesc{Richiede una scrittura asincrona.}
738 {Le funzioni ritornano $0$ in caso di successo e $-1$ per un errore, nel qual
739 caso \var{errno} assumerà uno dei valori:
741 \item[\errcode{EAGAIN}] la coda delle richieste è momentaneamente piena.
742 \item[\errcode{EBADF}] si è specificato un file descriptor sbagliato.
743 \item[\errcode{EINVAL}] si è specificato un valore non valido per i campi
744 \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}.
745 \item[\errcode{ENOSYS}] la funzione non è implementata.
751 Entrambe le funzioni ritornano immediatamente dopo aver messo in coda la
752 richiesta, o in caso di errore. Non è detto che gli errori \errcode{EBADF} ed
753 \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata,
754 potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e
755 scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che
756 il file non sia stato aperto in \textit{append mode} (vedi
757 sez.~\ref{sec:file_open_close}), nel qual caso le scritture vengono effettuate
758 comunque alla fine del file, nell'ordine delle chiamate a \func{aio\_write}.
760 Si tenga inoltre presente che deallocare la memoria indirizzata da
761 \param{aiocbp} o modificarne i valori prima della conclusione di una
762 operazione può dar luogo a risultati impredicibili, perché l'accesso ai vari
763 campi per eseguire l'operazione può avvenire in un momento qualsiasi dopo la
764 richiesta. Questo comporta che non si devono usare per \param{aiocbp}
765 variabili automatiche e che non si deve riutilizzare la stessa struttura per
766 un'altra operazione fintanto che la precedente non sia stata ultimata. In
767 generale per ogni operazione si deve utilizzare una diversa struttura
770 Dato che si opera in modalità asincrona, il successo di \func{aio\_read} o
771 \func{aio\_write} non implica che le operazioni siano state effettivamente
772 eseguite in maniera corretta; per verificarne l'esito l'interfaccia prevede
773 altre due funzioni, che permettono di controllare lo stato di esecuzione. La
774 prima è \funcd{aio\_error}, che serve a determinare un eventuale stato di
775 errore; il suo prototipo è:
779 \fdecl{int aio\_error(const struct aiocb *aiocbp)}
780 \fdesc{Determina lo stato di errore di una operazione di I/O asincrono.}
783 {La funzione ritorna $0$ se le operazioni si sono concluse con successo,
784 altrimenti restituisce \errval{EINPROGRESS} se non sono concluse,
785 \errcode{ECANCELED} se sono state cancellate o il relativo codice di errore
789 Se l'operazione non si è ancora completata viene sempre restituito l'errore di
790 \errcode{EINPROGRESS}, mentre se è stata cancellata ritorna
791 \errcode{ECANCELED}. La funzione ritorna zero quando l'operazione si è
792 conclusa con successo, altrimenti restituisce il codice dell'errore
793 verificatosi, ed esegue la corrispondente impostazione di \var{errno}. Il
794 codice può essere sia \errcode{EINVAL} ed \errcode{EBADF}, dovuti ad un valore
795 errato per \param{aiocbp}, che uno degli errori possibili durante l'esecuzione
796 dell'operazione di I/O richiesta, nel qual caso saranno restituiti, a seconda
797 del caso, i codici di errore delle \textit{system call} \func{read},
798 \func{write}, \func{fsync} e \func{fdatasync}.
800 Una volta che si sia certi che le operazioni siano state concluse (cioè dopo
801 che una chiamata ad \func{aio\_error} non ha restituito
802 \errcode{EINPROGRESS}), si potrà usare la funzione \funcd{aio\_return}, che
803 permette di verificare il completamento delle operazioni di I/O asincrono; il
808 \fdecl{ssize\_t aio\_return(const struct aiocb *aiocbp)}
809 \fdesc{Ottiene lo stato dei risultati di una operazione di I/O asincrono.}
812 {La funzione ritorna lo stato di uscita dell'operazione eseguita (il valore
813 che avrebbero restituito le equivalenti funzioni eseguite in maniera
817 La funzione recupera il valore dello stato di ritorno delle operazioni di I/O
818 associate a \param{aiocbp} e deve essere chiamata una sola volta per ciascuna
819 operazione asincrona, essa infatti fa sì che il sistema rilasci le risorse ad
820 essa associate. É per questo motivo che occorre chiamare la funzione solo dopo
821 che l'operazione cui \param{aiocbp} fa riferimento si è completata
822 verificandolo con \func{aio\_error}, ed usarla una sola volta. Una chiamata
823 precedente il completamento delle operazioni darebbe risultati indeterminati,
824 così come chiamarla più di una volta.
826 La funzione restituisce il valore di ritorno relativo all'operazione eseguita,
827 così come ricavato dalla sottostante \textit{system call} (il numero di byte
828 letti, scritti o il valore di ritorno di \func{fsync} o \func{fdatasync}). É
829 importante chiamare sempre questa funzione, altrimenti le risorse disponibili
830 per le operazioni di I/O asincrono non verrebbero liberate, rischiando di
831 arrivare ad un loro esaurimento.
833 Oltre alle operazioni di lettura e scrittura l'interfaccia POSIX.1b mette a
834 disposizione un'altra operazione, quella di sincronizzazione dell'I/O,
835 compiuta dalla funzione \funcd{aio\_fsync}, che ha lo stesso effetto della
836 analoga \func{fsync}, ma viene eseguita in maniera asincrona; il suo prototipo
841 \fdecl{int aio\_fsync(int op, struct aiocb *aiocbp)}
842 \fdesc{Richiede la sincronizzazione dei dati su disco.}
845 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
846 caso \var{errno} assumerà gli stessi valori visti \func{aio\_read} con lo
851 La funzione richiede la sincronizzazione dei dati delle operazioni di I/O
852 relative al file descriptor indicato in \texttt{aiocbp->aio\_fildes},
853 ritornando immediatamente. Si tenga presente che la funzione mette
854 semplicemente in coda la richiesta, l'esecuzione effettiva della
855 sincronizzazione dovrà essere verificata con \func{aio\_error} e
856 \func{aio\_return} come per le operazioni di lettura e
857 scrittura. L'argomento \param{op} permette di indicare la modalità di
858 esecuzione, se si specifica il valore \const{O\_DSYNC} le operazioni saranno
859 completate con una chiamata a \func{fdatasync}, se si specifica
860 \const{O\_SYNC} con una chiamata a \func{fsync} (per i dettagli vedi
861 sez.~\ref{sec:file_sync}).
863 Il successo della chiamata assicura la richiesta di sincronizzazione dei dati
864 relativi operazioni di I/O asincrono richieste fino a quel momento, niente è
865 garantito riguardo la sincronizzazione dei dati relativi ad eventuali
866 operazioni richieste successivamente. Se si è specificato un meccanismo di
867 notifica questo sarà innescato una volta che le operazioni di sincronizzazione
868 dei dati saranno completate (\texttt{aio\_sigevent} è l'unico altro campo
869 di \param{aiocbp} che viene usato.
871 In alcuni casi può essere necessario interrompere le operazioni di I/O (in
872 genere quando viene richiesta un'uscita immediata dal programma), per questo
873 lo standard POSIX.1b prevede una funzione apposita, \funcd{aio\_cancel}, che
874 permette di cancellare una operazione richiesta in precedenza; il suo
879 \fdecl{int aio\_cancel(int fd, struct aiocb *aiocbp)}
880 \fdesc{Richiede la cancellazione delle operazioni di I/O asincrono.}
883 {La funzione ritorna un intero positivo che indica il risultato
884 dell'operazione in caso di successo e $-1$ per un errore, nel qual caso
885 \var{errno} assumerà uno dei valori:
887 \item[\errcode{EBADF}] \param{fd} non è un file descriptor valido.
888 \item[\errcode{ENOSYS}] la funzione non è implementata.
893 La funzione permette di cancellare una operazione specifica sul file
894 \param{fd}, idicata con \param{aiocbp}, o tutte le operazioni pendenti,
895 specificando \val{NULL} come valore di \param{aiocbp}. Quando una operazione
896 viene cancellata una successiva chiamata ad \func{aio\_error} riporterà
897 \errcode{ECANCELED} come codice di errore, ed mentre il valore di ritorno per
898 \func{aio\_return} sarà $-1$, inoltre il meccanismo di notifica non verrà
899 invocato. Se con \param{aiocbp} si specifica una operazione relativa ad un
900 file descriptor diverso da \param{fd} il risultato è indeterminato. In caso
901 di successo, i possibili valori di ritorno per \func{aio\_cancel} (anch'essi
902 definiti in \headfile{aio.h}) sono tre:
903 \begin{basedescript}{\desclabelwidth{3.0cm}}
904 \item[\const{AIO\_ALLDONE}] indica che le operazioni di cui si è richiesta la
905 cancellazione sono state già completate,
907 \item[\const{AIO\_CANCELED}] indica che tutte le operazioni richieste sono
910 \item[\const{AIO\_NOTCANCELED}] indica che alcune delle operazioni erano in
911 corso e non sono state cancellate.
914 Nel caso si abbia \const{AIO\_NOTCANCELED} occorrerà chiamare
915 \func{aio\_error} per determinare quali sono le operazioni effettivamente
916 cancellate. Le operazioni che non sono state cancellate proseguiranno il loro
917 corso normale, compreso quanto richiesto riguardo al meccanismo di notifica
918 del loro avvenuto completamento.
920 Benché l'I/O asincrono preveda un meccanismo di notifica, l'interfaccia
921 fornisce anche una apposita funzione, \funcd{aio\_suspend}, che permette di
922 sospendere l'esecuzione del processo chiamante fino al completamento di una
923 specifica operazione; il suo prototipo è:
927 \fdecl{int aio\_suspend(const struct aiocb * const list[], int nent, \\
928 \phantom{int aio\_suspend(}const struct timespec *timeout)}
929 \fdesc{Attende il completamento di una operazione di I/O asincrono.}
932 {La funzione ritorna $0$ se una (o più) operazioni sono state completate e
933 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
935 \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
937 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
938 \item[\errcode{ENOSYS}] la funzione non è implementata.
943 La funzione permette di bloccare il processo fintanto che almeno una delle
944 \param{nent} operazioni specificate nella lista \param{list} è completata, per
945 un tempo massimo specificato dalla struttura \struct{timespec} puntata
946 da \param{timout}, o fintanto che non arrivi un segnale (si tenga conto che
947 questo segnale potrebbe essere anche quello utilizzato come meccanismo di
948 notifica). La lista deve essere inizializzata con delle strutture
949 \struct{aiocb} relative ad operazioni effettivamente richieste, ma può
950 contenere puntatori nulli, che saranno ignorati. In caso si siano specificati
951 valori non validi l'effetto è indefinito.
952 Un valore \val{NULL} per \param{timout} comporta l'assenza di timeout, mentre
953 se si vuole effettuare un \textit{polling} sulle operazioni occorrerà
954 specificare un puntatore valido ad una struttura \texttt{timespec} (vedi
955 fig.~\ref{fig:sys_timespec_struct}) contenente valori nulli, e verificare poi
956 con \func{aio\_error} quale delle operazioni della lista \param{list} è stata
959 Lo standard POSIX.1b infine ha previsto pure una funzione, \funcd{lio\_listio},
960 che permette di effettuare la richiesta di una intera lista di operazioni di
961 lettura o scrittura; il suo prototipo è:
966 \fdecl{int lio\_listio(int mode, struct aiocb * const list[], int nent, struct
969 \fdesc{Richiede l'esecuzione di una serie di operazioni di I/O.}
972 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
973 caso \var{errno} assumerà uno dei valori:
975 \item[\errcode{EAGAIN}] nessuna operazione è stata completata entro
977 \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale.
978 \item[\errcode{EINVAL}] si è passato un valore di \param{mode} non valido
979 o un numero di operazioni \param{nent} maggiore di
980 \const{AIO\_LISTIO\_MAX}.
981 \item[\errcode{ENOSYS}] la funzione non è implementata.
986 La funzione esegue la richiesta delle \param{nent} operazioni indicate nella
987 lista \param{list} un vettore di puntatori a strutture \struct{aiocb}
988 indicanti le operazioni da compiere (che verranno eseguite senza un ordine
989 particolare). La lista può contenere anche puntatori nulli, che saranno
990 ignorati (si possono così eliminare facilmente componenti della lista senza
993 Ciascuna struttura \struct{aiocb} della lista deve contenere un
994 \textit{control block} opportunamente inizializzato; in particolare per
995 ognuna di esse dovrà essere specificato il tipo di operazione con il campo
996 \var{aio\_lio\_opcode}, che può prendere i valori:
997 \begin{basedescript}{\desclabelwidth{2.0cm}}
998 \item[\const{LIO\_READ}] si richiede una operazione di lettura.
999 \item[\const{LIO\_WRITE}] si richiede una operazione di scrittura.
1002 dove \const{LIO\_NOP} viene usato quando si ha a che fare con un vettore di
1003 dimensione fissa, per poter specificare solo alcune operazioni, o quando si
1004 sono dovute cancellare delle operazioni e si deve ripetere la richiesta per
1005 quelle non completate.
1007 L'argomento \param{mode} controlla il comportamento della funzione, se viene
1008 usato il valore \const{LIO\_WAIT} la funzione si blocca fino al completamento
1009 di tutte le operazioni richieste; se si usa \const{LIO\_NOWAIT} la funzione
1010 ritorna immediatamente dopo aver messo in coda tutte le richieste. In tal caso
1011 il chiamante può richiedere la notifica del completamento di tutte le
1012 richieste, impostando l'argomento \param{sig} in maniera analoga a come si fa
1013 per il campo \var{aio\_sigevent} di \struct{aiocb}.
1015 % TODO: trattare libaio e le system call del kernel per l'I/O asincrono, vedi
1016 % http://lse.sourceforge.net/io/aio.html,
1017 % http://webfiveoh.com/content/guides/2012/aug/mon-13th/linux-asynchronous-io-and-libaio.html,
1018 % https://code.google.com/p/kernel/wiki/AIOUserGuide,
1019 % http://bert-hubert.blogspot.de/2012/05/on-linux-asynchronous-file-io.html
1022 \section{Altre modalità di I/O avanzato}
1023 \label{sec:file_advanced_io}
1025 Oltre alle precedenti modalità di \textit{I/O multiplexing} e \textsl{I/O
1026 asincrono}, esistono altre funzioni che implementano delle modalità di
1027 accesso ai file più evolute rispetto alle normali funzioni di lettura e
1028 scrittura che abbiamo esaminato in sez.~\ref{sec:file_unix_interface}. In
1029 questa sezione allora prenderemo in esame le interfacce per l'\textsl{I/O
1030 mappato in memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O
1034 \subsection{File mappati in memoria}
1035 \label{sec:file_memory_map}
1037 \itindbeg{memory~mapping}
1038 Una modalità alternativa di I/O, che usa una interfaccia completamente diversa
1039 rispetto a quella classica vista in sez.~\ref{sec:file_unix_interface}, è il
1040 cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della
1041 \textsl{paginazione} \index{paginazione} usato dalla memoria virtuale (vedi
1042 sez.~\ref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un
1043 file in una sezione dello spazio di indirizzi del processo che lo ha allocato.
1047 \includegraphics[width=12cm]{img/mmap_layout}
1048 \caption{Disposizione della memoria di un processo quando si esegue la
1049 mappatura in memoria di un file.}
1050 \label{fig:file_mmap_layout}
1053 Il meccanismo è illustrato in fig.~\ref{fig:file_mmap_layout}, una sezione del
1054 file viene \textsl{mappata} direttamente nello spazio degli indirizzi del
1055 programma. Tutte le operazioni di lettura e scrittura su variabili contenute
1056 in questa zona di memoria verranno eseguite leggendo e scrivendo dal contenuto
1057 del file attraverso il sistema della memoria virtuale illustrato in
1058 sez.~\ref{sec:proc_mem_gen} che in maniera analoga a quanto avviene per le
1059 pagine che vengono salvate e rilette nella \textit{swap}, si incaricherà di
1060 sincronizzare il contenuto di quel segmento di memoria con quello del file
1061 mappato su di esso. Per questo motivo si può parlare tanto di \textsl{file
1062 mappato in memoria}, quanto di \textsl{memoria mappata su file}.
1064 L'uso del \textit{memory-mapping} comporta una notevole semplificazione delle
1065 operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer
1066 intermedi su cui appoggiare i dati da traferire, poiché questi potranno essere
1067 acceduti direttamente nella sezione di memoria mappata; inoltre questa
1068 interfaccia è più efficiente delle usuali funzioni di I/O, in quanto permette
1069 di caricare in memoria solo le parti del file che sono effettivamente usate ad
1072 Infatti, dato che l'accesso è fatto direttamente attraverso la memoria
1073 virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta
1074 o scritta sul file una pagina alla volta e solo per le parti effettivamente
1075 usate, il tutto in maniera completamente trasparente al processo; l'accesso
1076 alle pagine non ancora caricate avverrà allo stesso modo con cui vengono
1077 caricate in memoria le pagine che sono state salvate sullo \textit{swap}.
1079 Infine in situazioni in cui la memoria è scarsa, le pagine che mappano un file
1080 vengono salvate automaticamente, così come le pagine dei programmi vengono
1081 scritte sulla \textit{swap}; questo consente di accedere ai file su dimensioni
1082 il cui solo limite è quello dello spazio di indirizzi disponibile, e non della
1083 memoria su cui possono esserne lette delle porzioni.
1085 L'interfaccia POSIX implementata da Linux prevede varie funzioni di sistema
1086 per la gestione del \textit{memory mapped I/O}, la prima di queste, che serve
1087 ad eseguire la mappatura in memoria di un file, è \funcd{mmap}; il suo
1093 \fdecl{void * mmap(void * start, size\_t length, int prot, int flags, int
1095 \fdesc{Esegue la mappatura in memoria di una sezione di un file.}
1098 {La funzione ritorna il puntatore alla zona di memoria mappata in caso di
1099 successo, e \const{MAP\_FAILED} (\texttt{(void *) -1}) per un errore, nel
1100 qual caso \var{errno} assumerà uno dei valori:
1102 \item[\errcode{EACCES}] o \param{fd} non si riferisce ad un file regolare,
1103 o si è usato \const{MAP\_PRIVATE} ma \param{fd} non è aperto in lettura,
1104 o si è usato \const{MAP\_SHARED} e impostato \const{PROT\_WRITE} ed
1105 \param{fd} non è aperto in lettura/scrittura, o si è impostato
1106 \const{PROT\_WRITE} ed \param{fd} è in \textit{append-only}.
1107 \item[\errcode{EAGAIN}] il file è bloccato, o si è bloccata troppa memoria
1108 rispetto a quanto consentito dai limiti di sistema (vedi
1109 sez.~\ref{sec:sys_resource_limit}).
1110 \item[\errcode{EBADF}] il file descriptor non è valido, e non si è usato
1111 \const{MAP\_ANONYMOUS}.
1112 \item[\errcode{EINVAL}] i valori di \param{start}, \param{length} o
1113 \param{offset} non sono validi (o troppo grandi o non allineati sulla
1114 dimensione delle pagine), o \param{lengh} è zero (solo dal 2.6.12)
1115 o \param{flags} contiene sia \const{MAP\_PRIVATE} che
1116 \const{MAP\_SHARED} o nessuno dei due.
1117 \item[\errcode{ENFILE}] si è superato il limite del sistema sul numero di
1118 file aperti (vedi sez.~\ref{sec:sys_resource_limit}).
1119 \item[\errcode{ENODEV}] il filesystem di \param{fd} non supporta il memory
1121 \item[\errcode{ENOMEM}] non c'è memoria o si è superato il limite sul
1122 numero di mappature possibili.
1123 \item[\errcode{EOVERFLOW}] su architettura a 32 bit con il supporto per i
1124 \textit{large file} (che hanno una dimensione a 64 bit) il numero di
1125 pagine usato per \param{lenght} aggiunto a quello usato
1126 per \param{offset} eccede i 32 bit (\texttt{unsigned long}).
1127 \item[\errcode{EPERM}] l'argomento \param{prot} ha richiesto
1128 \const{PROT\_EXEC}, ma il filesystem di \param{fd} è montato con
1129 l'opzione \texttt{noexec}.
1130 \item[\errcode{ETXTBSY}] si è impostato \const{MAP\_DENYWRITE} ma
1131 \param{fd} è aperto in scrittura.
1136 La funzione richiede di mappare in memoria la sezione del file \param{fd} a
1137 partire da \param{offset} per \param{length} byte, preferibilmente
1138 all'indirizzo \param{start}. Il valore \param{start} viene normalmente
1139 considerato come un suggerimento, ma l'uso di un qualunque valore diverso da
1140 \val{NULL}, in cui si rimette completamente al kernel la scelta
1141 dell'indirizzo, viene sconsigliato per ragioni di portabilità. Il valore
1142 di \param{offset} deve essere un multiplo della dimensione di una pagina di
1148 \begin{tabular}[c]{|l|l|}
1150 \textbf{Valore} & \textbf{Significato} \\
1153 \const{PROT\_EXEC} & Le pagine possono essere eseguite.\\
1154 \const{PROT\_READ} & Le pagine possono essere lette.\\
1155 \const{PROT\_WRITE} & Le pagine possono essere scritte.\\
1156 \const{PROT\_NONE} & L'accesso alle pagine è vietato.\\
1159 \caption{Valori dell'argomento \param{prot} di \func{mmap}, relativi alla
1160 protezione applicate alle pagine del file mappate in memoria.}
1161 \label{tab:file_mmap_prot}
1164 Il valore dell'argomento \param{prot} indica la protezione\footnote{come
1165 accennato in sez.~\ref{sec:proc_memory} in Linux la memoria reale è divisa
1166 in pagine, ogni processo vede la sua memoria attraverso uno o più segmenti
1167 lineari di memoria virtuale; per ciascuno di questi segmenti il kernel
1168 mantiene nella \textit{page table} la mappatura sulle pagine di memoria
1169 reale, ed le modalità di accesso (lettura, esecuzione, scrittura); una loro
1170 violazione causa quella una \textit{segment violation}, e la relativa
1171 emissione del segnale \signal{SIGSEGV}.} da applicare al segmento di memoria
1172 e deve essere specificato come maschera binaria ottenuta dall'OR di uno o più
1173 dei valori riportati in tab.~\ref{tab:file_mmap_prot}; il valore specificato
1174 deve essere compatibile con la modalità di accesso con cui si è aperto il
1180 \begin{tabular}[c]{|l|p{11cm}|}
1182 \textbf{Valore} & \textbf{Significato} \\
1185 \const{MAP\_32BIT} & Esegue la mappatura sui primi 2Gb dello spazio
1186 degli indirizzi, viene supportato solo sulle
1187 piattaforme \texttt{x86-64} per compatibilità con
1188 le applicazioni a 32 bit. Viene ignorato se si è
1189 richiesto \const{MAP\_FIXED} (dal kernel 2.4.20).\\
1190 \const{MAP\_ANON} & Sinonimo di \const{MAP\_ANONYMOUS}, deprecato.\\
1191 \const{MAP\_ANONYMOUS} & La mappatura non è associata a nessun file. Gli
1192 argomenti \param{fd} e \param{offset} sono
1193 ignorati. L'uso di questo flag con
1194 \const{MAP\_SHARED} è stato implementato in Linux
1195 a partire dai kernel della serie 2.4.x.\\
1196 \const{MAP\_DENYWRITE} & In Linux viene ignorato per evitare
1198 (veniva usato per segnalare che tentativi di
1199 scrittura sul file dovevano fallire con
1200 \errcode{ETXTBSY}).\\
1201 \const{MAP\_EXECUTABLE}& Ignorato.\\
1202 \const{MAP\_FILE} & Valore di compatibilità, ignorato.\\
1203 \const{MAP\_FIXED} & Non permette di restituire un indirizzo diverso
1204 da \param{start}, se questo non può essere usato
1205 \func{mmap} fallisce. Se si imposta questo flag il
1206 valore di \param{start} deve essere allineato
1207 alle dimensioni di una pagina.\\
1208 \const{MAP\_GROWSDOWN} & Usato per gli \textit{stack}.
1209 Indica che la mappatura deve essere effettuata
1210 con gli indirizzi crescenti verso il basso.\\
1211 \const{MAP\_HUGETLB} & Esegue la mappatura usando le cosiddette
1212 ``\textit{huge pages}'' (dal kernel 2.6.32).\\
1213 \const{MAP\_LOCKED} & Se impostato impedisce lo \textit{swapping} delle
1214 pagine mappate (dal kernel 2.5.37).\\
1215 \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che
1216 non causa I/O (dal kernel 2.5.46).\\
1217 \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva
1218 delle pagine di \textit{swap} ad uso del meccanismo
1219 del \textit{copy on write}
1220 per mantenere le modifiche fatte alla regione
1221 mappata, in questo caso dopo una scrittura, se
1222 non c'è più memoria disponibile, si ha
1223 l'emissione di un \signal{SIGSEGV}.\\
1224 \const{MAP\_POPULATE} & Esegue il \textit{prefaulting} delle pagine di
1225 memoria necessarie alla mappatura (dal kernel
1227 \const{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono
1228 riportati sul file. Ne viene fatta una copia
1229 privata cui solo il processo chiamante ha
1230 accesso. Incompatibile con \const{MAP\_SHARED}.\\
1231 \const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono
1232 riportati sul file e saranno immediatamente
1233 visibili agli altri processi che mappano lo stesso
1235 con \const{MAP\_PRIVATE}.\\
1236 \const{MAP\_STACK} & Al momento è ignorato, è stato fornito (dal kernel
1237 2.6.27) a supporto della implementazione dei
1238 thread nelle \acr{glibc}, per allocare memoria in
1239 uno spazio utilizzabile come \textit{stack} per le
1240 architetture hardware che richiedono un
1241 trattamento speciale di quest'ultimo.\\
1242 \const{MAP\_UNINITIALIZED}& Specifico per i sistemi embedded ed
1243 utilizzabile dal kernel 2.6.33 solo se è stata
1244 abilitata in fase di compilazione dello stesso
1246 \texttt{CONFIG\_MMAP\_ALLOW\_UNINITIALIZED}. Se
1247 usato le pagine di memoria usate nella mappatura
1248 anonima non vengono cancellate; questo migliora
1249 le prestazioni sui sistemi con risorse minime, ma
1250 comporta la possibilità di rileggere i dati di
1251 altri processi che han chiuso una mappatura, per
1252 cui viene usato solo quando (come si suppone sia
1253 per i sistemi embedded) si ha il completo
1254 controllo dell'uso della memoria da parte degli
1256 % \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area
1257 % mappata con \func{mremap}, proposto ma pare non
1261 \caption{Valori possibili dell'argomento \param{flag} di \func{mmap}.}
1262 \label{tab:file_mmap_flag}
1265 % TODO trattare MAP_HUGETLB introdotto con il kernel 2.6.32, e modifiche
1266 % introdotte con il 3.8 per le dimensioni variabili delle huge pages
1268 L'argomento \param{flags} specifica infine qual è il tipo di oggetto mappato,
1269 le opzioni relative alle modalità con cui è effettuata la mappatura e alle
1270 modalità con cui le modifiche alla memoria mappata vengono condivise o
1271 mantenute private al processo che le ha effettuate. Deve essere specificato
1272 come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in
1273 tab.~\ref{tab:file_mmap_flag}. Fra questi comunque deve sempre essere
1274 specificato o \const{MAP\_PRIVATE} o \const{MAP\_SHARED} per indicare la
1275 modalità con cui viene effettuata la mappatura.
1277 Esistono infatti due modalità alternative di eseguire la mappatura di un file;
1278 la più comune è \const{MAP\_SHARED} in cui la memoria è condivisa e le
1279 modifiche effettuate su di essa sono visibili a tutti i processi che hanno
1280 mappato lo stesso file. In questo caso le modifiche vengono anche riportate su
1281 disco, anche se questo può non essere immediato a causa della bufferizzazione:
1282 si potrà essere sicuri dell'aggiornamento solo in seguito alla chiamata di
1283 \func{msync} o \func{munmap}, e solo allora le modifiche saranno visibili sul
1284 file con l'I/O convenzionale.
1286 Con \const{MAP\_PRIVATE} invece viene creata una copia privata del file,
1287 questo non viene mai modificato e solo il processo chiamante ha accesso alla
1288 mappatura. Le modifiche eseguite dal processo sulla mappatura vengono
1289 effettuate utilizzando il meccanismo del \textit{copy on write}, mentenute in
1290 memoria e salvate su \textit{swap} in caso di necessità. Non è specificato se
1291 i cambiamenti sul file originale vengano riportati sulla regione mappata.
1293 Gli altri valori di \func{flag} modificano le caratteristiche della
1294 mappatura. Fra questi il più rilevante è probabilmente \const{MAP\_ANONYMOUS}
1295 che consente di creare segmenti di memoria condivisa fra processi diversi
1296 senza appoggiarsi a nessun file (torneremo sul suo utilizzo in
1297 sez.~\ref{sec:ipc_mmap_anonymous}). In tal caso gli argomenti \param{fd}
1298 e \param{offset} vangono ignorati, anche se alcune implementazioni richiedono
1299 che invece \param{fd} sia $-1$, convenzione che è opportuno seguire se si ha a
1300 cuore la portabilità dei programmi.
1302 Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere
1303 piuttosto complessi, essi si possono comprendere solo tenendo presente che
1304 tutto quanto è comunque basato sul meccanismo della memoria virtuale. Questo
1305 comporta allora una serie di conseguenze. La più ovvia è che se si cerca di
1306 scrivere su una zona mappata in sola lettura si avrà l'emissione di un segnale
1307 di violazione di accesso (\signal{SIGSEGV}), dato che i permessi sul segmento
1308 di memoria relativo non consentono questo tipo di accesso.
1310 È invece assai diversa la questione relativa agli accessi al di fuori della
1311 regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe
1312 ritenere che anch'essi debbano generare un segnale di violazione di accesso;
1313 questo però non tiene conto del fatto che, essendo basata sul meccanismo della
1314 paginazione, la mappatura in memoria non può che essere eseguita su un
1315 segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in
1316 generale queste potranno non corrispondere alle dimensioni effettive del file
1317 o della sezione che si vuole mappare.
1319 \begin{figure}[!htb]
1321 \includegraphics[height=6cm]{img/mmap_boundary}
1322 \caption{Schema della mappatura in memoria di una sezione di file di
1323 dimensioni non corrispondenti al bordo di una pagina.}
1324 \label{fig:file_mmap_boundary}
1327 Il caso più comune è quello illustrato in fig.~\ref{fig:file_mmap_boundary},
1328 in cui la sezione di file non rientra nei confini di una pagina: in tal caso
1329 il file sarà mappato su un segmento di memoria che si estende fino al
1330 bordo della pagina successiva. In questo caso è possibile accedere a quella
1331 zona di memoria che eccede le dimensioni specificate da \param{length}, senza
1332 ottenere un \signal{SIGSEGV} poiché essa è presente nello spazio di indirizzi
1333 del processo, anche se non è mappata sul file. Il comportamento del sistema è
1334 quello di restituire un valore nullo per quanto viene letto, e di non
1335 riportare su file quanto viene scritto.
1337 Un caso più complesso è quello che si viene a creare quando le dimensioni del
1338 file mappato sono più corte delle dimensioni della mappatura, oppure quando il
1339 file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a
1340 quella della mappatura in memoria. In questa situazione, per la sezione di
1341 pagina parzialmente coperta dal contenuto del file, vale esattamente quanto
1342 visto in precedenza; invece per la parte che eccede, fino alle dimensioni date
1343 da \param{length}, l'accesso non sarà più possibile, ma il segnale emesso non
1344 sarà \signal{SIGSEGV}, ma \signal{SIGBUS}, come illustrato in
1345 fig.~\ref{fig:file_mmap_exceed}.
1347 Non tutti i file possono venire mappati in memoria, dato che, come illustrato
1348 in fig.~\ref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza
1349 biunivoca fra una sezione di un file ed una sezione di memoria. Questo
1350 comporta che ad esempio non è possibile mappare in memoria file descriptor
1351 relativi a \textit{pipe}, socket e \textit{fifo}, per i quali non ha senso
1352 parlare di \textsl{sezione}. Lo stesso vale anche per alcuni file di
1353 dispositivo, che non dispongono della relativa operazione \func{mmap} (si
1354 ricordi quanto esposto in sez.~\ref{sec:file_vfs_work}). Si tenga presente
1355 però che esistono anche casi di dispositivi (un esempio è l'interfaccia al
1356 ponte PCI-VME del chip Universe) che sono utilizzabili solo con questa
1361 \includegraphics[height=6cm]{img/mmap_exceed}
1362 \caption{Schema della mappatura in memoria di file di dimensioni inferiori
1363 alla lunghezza richiesta.}
1364 \label{fig:file_mmap_exceed}
1367 Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene
1368 copiato integralmente, i file mappati in memoria verranno ereditati in maniera
1369 trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel
1370 padre; così se si è usato \const{MAP\_SHARED} padre e figlio accederanno allo
1371 stesso file in maniera condivisa, mentre se si è usato \const{MAP\_PRIVATE}
1372 ciascuno di essi manterrà una sua versione privata indipendente. Non c'è
1373 invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima
1374 sostituisce tutto lo spazio degli indirizzi di un processo con quello di un
1377 Quando si effettua la mappatura di un file vengono pure modificati i tempi ad
1378 esso associati (di cui si è trattato in sez.~\ref{sec:file_file_times}). Il
1379 valore di \var{st\_atime} può venir cambiato in qualunque istante a partire
1380 dal momento in cui la mappatura è stata effettuata: il primo riferimento ad
1381 una pagina mappata su un file aggiorna questo tempo. I valori di
1382 \var{st\_ctime} e \var{st\_mtime} possono venir cambiati solo quando si è
1383 consentita la scrittura sul file (cioè per un file mappato con
1384 \const{PROT\_WRITE} e \const{MAP\_SHARED}) e sono aggiornati dopo la scrittura
1385 o in corrispondenza di una eventuale \func{msync}.
1387 Dato per i file mappati in memoria le operazioni di I/O sono gestite
1388 direttamente dalla memoria virtuale, occorre essere consapevoli delle
1389 interazioni che possono esserci con operazioni effettuate con l'interfaccia
1390 dei file ordinaria illustrata in sez.~\ref{sec:file_unix_interface}. Il
1391 problema è che una volta che si è mappato un file, le operazioni di lettura e
1392 scrittura saranno eseguite sulla memoria, e riportate su disco in maniera
1393 autonoma dal sistema della memoria virtuale.
1395 Pertanto se si modifica un file con l'interfaccia ordinaria queste modifiche
1396 potranno essere visibili o meno a seconda del momento in cui la memoria
1397 virtuale trasporterà dal disco in memoria quella sezione del file, perciò è
1398 del tutto imprevedibile il risultato della modifica di un file nei confronti
1399 del contenuto della memoria su cui è mappato.
1401 Per questo è sempre sconsigliabile eseguire scritture su un file attraverso
1402 l'interfaccia ordinaria quando lo si è mappato in memoria, è invece possibile
1403 usare l'interfaccia ordinaria per leggere un file mappato in memoria, purché
1404 si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria
1405 mette a disposizione la funzione \funcd{msync} per sincronizzare il contenuto
1406 della memoria mappata con il file su disco; il suo prototipo è:
1411 \fdecl{int msync(const void *start, size\_t length, int flags)}
1412 \fdesc{Sincronizza i contenuti di una sezione di un file mappato in memoria.}
1415 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1416 caso \var{errno} assumerà uno dei valori:
1418 \item[\errcode{EBUSY}] si è indicato \const{MS\_INVALIDATE} ma
1419 nell'intervallo di memoria specificato è presente un \textit{memory lock}.
1420 \item[\errcode{EFAULT}] l'intervallo indicato, o parte di esso, non
1421 risulta mappato (prima del kernel 2.4.19).
1422 \item[\errcode{EINVAL}] o \param{start} non è multiplo di
1423 \const{PAGE\_SIZE}, o si è specificato un valore non valido per
1425 \item[\errcode{ENOMEM}] l'intervallo indicato, o parte di esso, non
1426 risulta mappato (dal kernel 2.4.19).
1431 La funzione esegue la sincronizzazione di quanto scritto nella sezione di
1432 memoria indicata da \param{start} e \param{offset}, scrivendo le modifiche sul
1433 file (qualora questo non sia già stato fatto). Provvede anche ad aggiornare i
1434 relativi tempi di modifica. In questo modo si è sicuri che dopo l'esecuzione
1435 di \func{msync} le funzioni dell'interfaccia ordinaria troveranno un contenuto
1436 del file aggiornato.
1442 \begin{tabular}[c]{|l|p{11cm}|}
1444 \textbf{Valore} & \textbf{Significato} \\
1447 \const{MS\_SYNC} & richiede una sincronizzazione e ritorna soltanto
1448 quando questa è stata completata.\\
1449 \const{MS\_ASYNC} & richiede una sincronizzazione, ma ritorna subito
1450 non attendendo che questa sia finita.\\
1451 \const{MS\_INVALIDATE} & invalida le pagine per tutte le mappature
1452 in memoria così da rendere necessaria una
1453 rilettura immediata delle stesse.\\
1456 \caption{Valori possibili dell'argomento \param{flag} di \func{msync}.}
1457 \label{tab:file_mmap_msync}
1460 L'argomento \param{flag} è specificato come maschera binaria composta da un OR
1461 dei valori riportati in tab.~\ref{tab:file_mmap_msync}, di questi però
1462 \const{MS\_ASYNC} e \const{MS\_SYNC} sono incompatibili; con il primo valore
1463 infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al
1464 meccanismo della memoria virtuale, ritornando subito, mentre con il secondo
1465 attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo
1466 valore fa sì che vengano invalidate, per tutte le mappature dello stesso file,
1467 le pagine di cui si è richiesta la sincronizzazione, così che esse possano
1468 essere immediatamente aggiornate con i nuovi valori.
1470 Una volta che si sono completate le operazioni di I/O si può eliminare la
1471 mappatura della memoria usando la funzione \funcd{munmap}, il suo prototipo è:
1476 \fdecl{int munmap(void *start, size\_t length)}
1477 \fdesc{Rilascia la mappatura sulla sezione di memoria specificata.}
1480 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1481 caso \var{errno} assumerà uno dei valori:
1483 \item[\errcode{EINVAL}] l'intervallo specificato non ricade in una zona
1484 precedentemente mappata.
1489 La funzione cancella la mappatura per l'intervallo specificato con
1490 \param{start} e \param{length}; ogni successivo accesso a tale regione causerà
1491 un errore di accesso in memoria. L'argomento \param{start} deve essere
1492 allineato alle dimensioni di una pagina, e la mappatura di tutte le pagine
1493 contenute anche parzialmente nell'intervallo indicato, verrà rimossa.
1494 Indicare un intervallo che non contiene mappature non è un errore. Si tenga
1495 presente inoltre che alla conclusione di un processo ogni pagina mappata verrà
1496 automaticamente rilasciata, mentre la chiusura del file descriptor usato per
1497 il \textit{memory mapping} non ha alcun effetto su di esso.
1499 Lo standard POSIX prevede anche una funzione che permetta di cambiare le
1500 protezioni delle pagine di memoria; lo standard prevede che essa si applichi
1501 solo ai \textit{memory mapping} creati con \func{mmap}, ma nel caso di Linux
1502 la funzione può essere usata con qualunque pagina valida nella memoria
1503 virtuale. Questa funzione di sistema è \funcd{mprotect} ed il suo prototipo è:
1507 \fdecl{int mprotect(const void *addr, size\_t len, int prot)}
1508 \fdesc{Modifica le protezioni delle pagine di memoria.}
1511 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1512 caso \var{errno} assumerà uno dei valori:
1514 \item[\errcode{EINVAL}] il valore di \param{addr} non è valido o non è un
1515 multiplo di \const{PAGE\_SIZE}.
1516 \item[\errcode{EACCES}] l'operazione non è consentita, ad esempio si è
1517 cercato di marcare con \const{PROT\_WRITE} un segmento di memoria cui si
1518 ha solo accesso in lettura.
1519 \item[\errcode{ENOMEM}] non è stato possibile allocare le risorse
1520 necessarie all'interno del kernel o si è specificato un indirizzo di
1521 memoria non valido del processo o non corrispondente a pagine mappate
1522 (negli ultimi due casi prima del kernel 2.4.19 veniva prodotto,
1523 erroneamente, \errcode{EFAULT}).
1528 La funzione prende come argomenti un indirizzo di partenza in \param{addr},
1529 allineato alle dimensioni delle pagine di memoria, ed una dimensione
1530 \param{size}. La nuova protezione deve essere specificata in \param{prot} con
1531 una combinazione dei valori di tab.~\ref{tab:file_mmap_prot}. La nuova
1532 protezione verrà applicata a tutte le pagine contenute, anche parzialmente,
1533 dall'intervallo fra \param{addr} e \param{addr}+\param{size}-1.
1535 Infine Linux supporta alcune operazioni specifiche non disponibili su altri
1536 kernel unix-like per poter usare le quali occorre però dichiarare
1537 \macro{\_GNU\_SOURCE} prima dell'inclusione di \texttt{sys/mman.h}. La prima
1538 di queste è la possibilità di modificare un precedente \textit{memory
1539 mapping}, ad esempio per espanderlo o restringerlo. Questo è realizzato
1540 dalla funzione di sistema \funcd{mremap}, il cui prototipo è:
1544 \fdecl{void * mremap(void *old\_address, size\_t old\_size , size\_t
1545 new\_size, unsigned long flags)}
1546 \fdesc{Restringe o allarga una mappatura in memoria.}
1549 {La funzione ritorna l'indirizzo alla nuova area di memoria in caso di
1550 successo o il valore \const{MAP\_FAILED} (pari a \texttt{(void *) -1}), nel
1551 qual caso \var{errno} assumerà uno dei valori:
1553 \item[\errcode{EINVAL}] il valore di \param{old\_address} non è un
1555 \item[\errcode{EFAULT}] ci sono indirizzi non validi nell'intervallo
1556 specificato da \param{old\_address} e \param{old\_size}, o ci sono altre
1557 mappature di tipo non corrispondente a quella richiesta.
1558 \item[\errcode{ENOMEM}] non c'è memoria sufficiente oppure l'area di
1559 memoria non può essere espansa all'indirizzo virtuale corrente, e non si
1560 è specificato \const{MREMAP\_MAYMOVE} nei flag.
1561 \item[\errcode{EAGAIN}] il segmento di memoria scelto è bloccato e non può
1567 La funzione richiede come argomenti \param{old\_address} (che deve essere
1568 allineato alle dimensioni di una pagina di memoria) che specifica il
1569 precedente indirizzo del \textit{memory mapping} e \param{old\_size}, che ne
1570 indica la dimensione. Con \param{new\_size} si specifica invece la nuova
1571 dimensione che si vuole ottenere. Infine l'argomento \param{flags} è una
1572 maschera binaria per i flag che controllano il comportamento della funzione.
1573 Il solo valore utilizzato è \const{MREMAP\_MAYMOVE} che consente di eseguire
1574 l'espansione anche quando non è possibile utilizzare il precedente
1575 indirizzo. Per questo motivo, se si è usato questo flag, la funzione può
1576 restituire un indirizzo della nuova zona di memoria che non è detto coincida
1577 con \param{old\_address}.
1579 La funzione si appoggia al sistema della memoria virtuale per modificare
1580 l'associazione fra gli indirizzi virtuali del processo e le pagine di memoria,
1581 modificando i dati direttamente nella \textit{page table} del processo. Come
1582 per \func{mprotect} la funzione può essere usata in generale, anche per pagine
1583 di memoria non corrispondenti ad un \textit{memory mapping}, e consente così
1584 di implementare la funzione \func{realloc} in maniera molto efficiente.
1586 Una caratteristica comune a tutti i sistemi unix-like è che la mappatura in
1587 memoria di un file viene eseguita in maniera lineare, cioè parti successive di
1588 un file vengono mappate linearmente su indirizzi successivi in memoria.
1589 Esistono però delle applicazioni (in particolare la tecnica è usata dai
1590 database o dai programmi che realizzano macchine virtuali) in cui è utile
1591 poter mappare sezioni diverse di un file su diverse zone di memoria.
1593 Questo è ovviamente sempre possibile eseguendo ripetutamente la funzione
1594 \func{mmap} per ciascuna delle diverse aree del file che si vogliono mappare
1595 in sequenza non lineare (ed in effetti è quello che veniva fatto anche con
1596 Linux prima che fossero introdotte queste estensioni) ma questo approccio ha
1597 delle conseguenze molto pesanti in termini di prestazioni. Infatti per
1598 ciascuna mappatura in memoria deve essere definita nella \textit{page table}
1599 del processo una nuova area di memoria virtuale, quella che nel gergo del
1600 kernel viene chiamata VMA (\textit{virtual memory area}, che corrisponda alla
1601 mappatura, in modo che questa diventi visibile nello spazio degli indirizzi
1602 come illustrato in fig.~\ref{fig:file_mmap_layout}.
1604 Quando un processo esegue un gran numero di mappature diverse (si può arrivare
1605 anche a centinaia di migliaia) per realizzare a mano una mappatura non-lineare
1606 esso vedrà un accrescimento eccessivo della sua \textit{page table}, e lo
1607 stesso accadrà per tutti gli altri processi che utilizzano questa tecnica. In
1608 situazioni in cui le applicazioni hanno queste esigenze si avranno delle
1609 prestazioni ridotte, dato che il kernel dovrà impiegare molte risorse per
1610 mantenere i dati relativi al \textit{memory mapping}, sia in termini di
1611 memoria interna per i dati delle \textit{page table}, che di CPU per il loro
1614 Per questo motivo con il kernel 2.5.46 è stato introdotto, ad opera di Ingo
1615 Molnar, un meccanismo che consente la mappatura non-lineare. Anche questa è
1616 una caratteristica specifica di Linux, non presente in altri sistemi
1617 unix-like. Diventa così possibile utilizzare una sola mappatura iniziale, e
1618 quindi una sola \textit{virtual memory area} nella \textit{page table} del
1619 processo, e poi rimappare a piacere all'interno di questa i dati del file. Ciò
1620 è possibile grazie ad una nuova \textit{system call},
1621 \funcd{remap\_file\_pages}, il cui prototipo è:
1625 \fdecl{int remap\_file\_pages(void *start, size\_t size, int prot,
1626 ssize\_t pgoff, int flags)}
1627 \fdesc{Rimappa non linearmente un \textit{memory mapping}.}
1630 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1631 caso \var{errno} assumerà uno dei valori:
1633 \item[\errcode{EINVAL}] si è usato un valore non valido per uno degli
1634 argomenti o \param{start} non fa riferimento ad un \textit{memory
1635 mapping} valido creato con \const{MAP\_SHARED}.
1638 nel loro significato generico.}
1641 Per poter utilizzare questa funzione occorre anzitutto effettuare
1642 preliminarmente una chiamata a \func{mmap} con \const{MAP\_SHARED} per
1643 definire l'area di memoria che poi sarà rimappata non linearmente. Poi si
1644 chiamerà questa funzione per modificare le corrispondenze fra pagine di
1645 memoria e pagine del file; si tenga presente che \func{remap\_file\_pages}
1646 permette anche di mappare la stessa pagina di un file in più pagine della
1649 La funzione richiede che si identifichi la sezione del file che si vuole
1650 riposizionare all'interno del \textit{memory mapping} con gli argomenti
1651 \param{pgoff} e \param{size}; l'argomento \param{start} invece deve indicare
1652 un indirizzo all'interno dell'area definita dall'\func{mmap} iniziale, a
1653 partire dal quale la sezione di file indicata verrà rimappata. L'argomento
1654 \param{prot} deve essere sempre nullo, mentre \param{flags} prende gli stessi
1655 valori di \func{mmap} (quelli di tab.~\ref{tab:file_mmap_prot}) ma di tutti i
1656 flag solo \const{MAP\_NONBLOCK} non viene ignorato.
1658 \itindbeg{prefaulting}
1660 Insieme alla funzione \func{remap\_file\_pages} nel kernel 2.5.46 con sono
1661 stati introdotti anche due nuovi flag per \func{mmap}: \const{MAP\_POPULATE} e
1662 \const{MAP\_NONBLOCK}. Il primo dei due consente di abilitare il meccanismo
1663 del \textit{prefaulting}. Questo viene di nuovo in aiuto per migliorare le
1664 prestazioni in certe condizioni di utilizzo del \textit{memory mapping}.
1666 Il problema si pone tutte le volte che si vuole mappare in memoria un file di
1667 grosse dimensioni. Il comportamento normale del sistema della memoria virtuale
1668 è quello per cui la regione mappata viene aggiunta alla \textit{page table}
1669 del processo, ma i dati verranno effettivamente utilizzati (si avrà cioè un
1670 \textit{page fault} che li trasferisce dal disco alla memoria) soltanto in
1671 corrispondenza dell'accesso a ciascuna delle pagine interessate dal
1672 \textit{memory mapping}.
1674 Questo vuol dire che il passaggio dei dati dal disco alla memoria avverrà una
1675 pagina alla volta con un gran numero di \textit{page fault}, chiaramente se si
1676 sa in anticipo che il file verrà utilizzato immediatamente, è molto più
1677 efficiente eseguire un \textit{prefaulting} in cui tutte le pagine di memoria
1678 interessate alla mappatura vengono ``\textsl{popolate}'' in una sola volta,
1679 questo comportamento viene abilitato quando si usa con \func{mmap} il flag
1680 \const{MAP\_POPULATE}.
1682 Dato che l'uso di \const{MAP\_POPULATE} comporta dell'I/O su disco che può
1683 rallentare l'esecuzione di \func{mmap} è stato introdotto anche un secondo
1684 flag, \const{MAP\_NONBLOCK}, che esegue un \textit{prefaulting} più limitato
1685 in cui vengono popolate solo le pagine della mappatura che già si trovano
1686 nella cache del kernel.\footnote{questo può essere utile per il linker
1687 dinamico, in particolare quando viene effettuato il \textit{prelink} delle
1690 \itindend{prefaulting}
1692 Per i vantaggi illustrati all'inizio del paragrafo l'interfaccia del
1693 \textit{memory mapped I/O} viene usata da una grande varietà di programmi,
1694 spesso con esigenze molto diverse fra di loro riguardo le modalità con cui
1695 verranno eseguiti gli accessi ad un file; è ad esempio molto comune per i
1696 database effettuare accessi ai dati in maniera pressoché casuale, mentre un
1697 riproduttore audio o video eseguirà per lo più letture sequenziali.
1699 \itindend{memory~mapping}
1701 Per migliorare le prestazioni a seconda di queste modalità di accesso è
1702 disponibile una apposita funzione, \funcd{madvise},\footnote{tratteremo in
1703 sez.~\ref{sec:file_fadvise} le funzioni che consentono di ottimizzare
1704 l'accesso ai file con l'interfaccia classica.} che consente di fornire al
1705 kernel delle indicazioni su come un processo intende accedere ad un segmento
1706 di memoria, anche al di là delle mappature dei file, così che possano essere
1707 adottate le opportune strategie di ottimizzazione. Il suo prototipo è:
1711 \fdecl{int madvise(void *start, size\_t length, int advice)}
1712 \fdesc{Fornisce indicazioni sull'uso previsto di un segmento di memoria.}
1715 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
1716 caso \var{errno} assumerà uno dei valori:
1718 \item[\errcode{EBADF}] la mappatura esiste ma non corrisponde ad un file.
1719 \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
1720 una pagina, \param{length} ha un valore negativo, o \param{advice} non è
1721 un valore valido, o si è richiesto il rilascio (con
1722 \const{MADV\_DONTNEED}) di pagine bloccate o condivise o si è usato
1723 \const{MADV\_MERGEABLE} o \const{MADV\_UNMERGEABLE} ma il kernel non è
1724 stato compilato per il relativo supporto.
1725 \item[\errcode{EIO}] la paginazione richiesta eccederebbe i limiti (vedi
1726 sez.~\ref{sec:sys_resource_limit}) sulle pagine residenti in memoria del
1727 processo (solo in caso di \const{MADV\_WILLNEED}).
1728 \item[\errcode{ENOMEM}] gli indirizzi specificati non sono mappati, o, in
1729 caso \const{MADV\_WILLNEED}, non c'è sufficiente memoria per soddisfare
1732 ed inoltre \errval{EAGAIN} e \errval{ENOSYS} nel loro significato generico.}
1735 La sezione di memoria sulla quale si intendono fornire le indicazioni deve
1736 essere indicata con l'indirizzo iniziale \param{start} e l'estensione
1737 \param{length}, il valore di \param{start} deve essere allineato,
1738 mentre \param{length} deve essere un numero positivo; la versione di Linux
1739 consente anche un valore nullo per \param{length}, inoltre se una parte
1740 dell'intervallo non è mappato in memoria l'indicazione viene comunque
1741 applicata alle restanti parti, anche se la funzione ritorna un errore di
1744 L'indicazione viene espressa dall'argomento \param{advice} che deve essere
1745 specificato con uno dei valori riportati in
1746 tab.~\ref{tab:madvise_advice_values}; si tenga presente che i valori indicati
1747 nella seconda parte della tabella sono specifici di Linux e non sono previsti
1748 dallo standard POSIX.1b. La funzione non ha, tranne il caso di
1749 \const{MADV\_DONTFORK}, nessun effetto sul comportamento di un programma, ma
1750 può influenzarne le prestazioni fornendo al kernel indicazioni sulle esigenze
1751 dello stesso, così che sia possibile scegliere le opportune strategie per la
1752 gestione del \textit{read-ahead} (vedi sez.~\ref{sec:file_fadvise}) e del
1758 \begin{tabular}[c]{|l|p{10 cm}|}
1760 \textbf{Valore} & \textbf{Significato} \\
1763 \const{MADV\_DONTNEED}& non ci si aspetta nessun accesso nell'immediato
1764 futuro, pertanto le pagine possono essere
1765 liberate dal kernel non appena necessario; l'area
1766 di memoria resterà accessibile, ma un accesso
1767 richiederà che i dati vengano ricaricati dal file
1768 a cui la mappatura fa riferimento.\\
1769 \const{MADV\_NORMAL} & nessuna indicazione specifica, questo è il valore
1770 di default usato quando non si è chiamato
1772 \const{MADV\_RANDOM} & ci si aspetta un accesso casuale all'area
1773 indicata, pertanto l'applicazione di una lettura
1774 anticipata con il meccanismo del
1775 \textit{read-ahead} (vedi
1776 sez.~\ref{sec:file_fadvise}) è di
1777 scarsa utilità e verrà disabilitata.\\
1778 \const{MADV\_SEQUENTIAL}& ci si aspetta un accesso sequenziale al file,
1779 quindi da una parte sarà opportuno eseguire una
1780 lettura anticipata, e dall'altra si potranno
1781 scartare immediatamente le pagine una volta che
1782 queste siano state lette.\\
1783 \const{MADV\_WILLNEED}& ci si aspetta un accesso nell'immediato futuro,
1784 pertanto l'applicazione del \textit{read-ahead}
1785 deve essere incentivata.\\
1787 \const{MADV\_DONTDUMP}& esclude da un \textit{core dump} (vedi
1788 sez.~\ref{sec:sig_standard}) le pagine
1789 specificate, viene usato per evitare di scrivere
1790 su disco dati relativi a zone di memoria che si sa
1791 non essere utili in un \textit{core dump}.\\
1792 \const{MADV\_DODUMP} & rimuove l'effetto della precedente
1793 \const{MADV\_DONTDUMP} (dal kernel 3.4).\\
1794 \const{MADV\_DONTFORK}& impedisce che l'intervallo specificato venga
1795 ereditato dal processo figlio dopo una
1796 \func{fork}; questo consente di evitare che il
1797 meccanismo del \textit{copy on write} effettui la
1798 rilocazione delle pagine quando il padre scrive
1799 sull'area di memoria dopo la \func{fork}, cosa che
1800 può causare problemi per l'hardware che esegue
1801 operazioni in DMA su quelle pagine (dal kernel
1803 \const{MADV\_DOFORK} & rimuove l'effetto della precedente
1804 \const{MADV\_DONTFORK} (dal kernel 2.6.16).\\
1805 \const{MADV\_HUGEPAGE}& abilita il meccanismo delle \textit{Transparent
1806 Huge Page} (vedi sez.~\ref{sec:huge_pages})
1807 sulla regione indicata; se questa è allineata
1808 alle relative dimensioni il kernel alloca
1809 direttamente delle \textit{huge page}; è
1810 utilizzabile solo con mappature anomime private
1811 (dal kernel 2.6.38).\\
1812 \const{MADV\_NOHUGEPAGE}& impedisce che la regione indicata venga
1813 collassata in eventuali \textit{huge page} (dal
1815 \const{MADV\_HWPOISON} &opzione ad uso di debug per verificare codice
1816 che debba gestire errori nella gestione della
1817 memoria; richiede una apposita opzione di
1818 compilazione del kernel, privilegi amministrativi
1819 (la capacità \const{CAP\_SYS\_ADMIN}) e provoca
1820 l'emissione di un segnale di \const{SIGBUS} dal
1821 programma chiamante e rimozione della mappatura
1822 (dal kernel 2.6.32).\\
1823 \const{MADV\_SOFT\_OFFLINE}&opzione utilizzata per il debug del
1824 codice di verifica degli errori di gestione
1825 memoria, richiede una apposita opzione di
1826 compilazione (dal kernel 2.6.33).\\
1827 \const{MADV\_MERGEABLE}& marca la pagina come accorpabile, indicazione
1828 principalmente ad uso dei sistemi di
1829 virtualizzazione\footnotemark (dal kernel 2.6.32).\\
1830 \const{MADV\_REMOVE} & libera un intervallo di pagine di memoria ed il
1831 relativo supporto sottostante; è supportato
1832 soltanto sui filesystem in RAM \textit{tmpfs} e
1833 \textit{shmfs} se usato su altri tipi di
1834 filesystem causa un errore di \errcode{ENOSYS}
1835 (dal kernel 2.6.16).\\
1836 \const{MADV\_UNMERGEABLE}& rimuove l'effetto della precedente
1837 \const{MADV\_MERGEABLE} (dal kernel 2.6.32). \\
1840 \caption{Valori dell'argomento \param{advice} di \func{madvise}.}
1841 \label{tab:madvise_advice_values}
1844 \footnotetext{a partire dal kernel 2.6.32 è stato introdotto un meccanismo che
1845 identifica pagine di memoria identiche e le accorpa in una unica pagina
1846 (soggetta al \textit{copy-on-write} per successive modifiche); per evitare
1847 di controllare tutte le pagine solo quelle marcate con questo flag vengono
1848 prese in considerazione per l'accorpamento; in questo modo si possono
1849 migliorare le prestazioni nella gestione delle macchine virtuali diminuendo
1850 la loro occupazione di memoria, ma il meccanismo può essere usato anche in
1851 altre applicazioni in cui sian presenti numerosi processi che usano gli
1852 stessi dati; per maggiori dettagli si veda
1853 \href{http://kernelnewbies.org/Linux_2_6_32\#head-d3f32e41df508090810388a57efce73f52660ccb}{\texttt{http://kernelnewbies.org/Linux\_2\_6\_32}}
1854 e la documentazione nei sorgenti del kernel
1855 (\texttt{Documentation/vm/ksm.txt}).}
1858 A differenza da quanto specificato nello standard POSIX.1b, per il quale l'uso
1859 di \func{madvise} è a scopo puramente indicativo, Linux considera queste
1860 richieste come imperative, per cui ritorna un errore qualora non possa
1861 soddisfarle; questo comportamento differisce da quanto specificato nello
1864 Nello standard POSIX.1-2001 è prevista una ulteriore funzione
1865 \funcd{posix\_madvise} che su Linux viene reimplementata utilizzando
1866 \func{madvise}; il suo prototipo è:
1870 \fdecl{int posix\_madvise(void *start, size\_t lenght, int advice)}
1871 \fdesc{Fornisce indicazioni sull'uso previsto di un segmento di memoria.}
1874 {La funzione ritorna $0$ in caso di successo ed un valore positivo per un
1875 errore, nel qual caso \var{errno} assumerà uno dei valori:
1877 \item[\errcode{EINVAL}] \param{start} non è allineato alla dimensione di
1878 una pagina, \param{length} ha un valore negativo, o \param{advice} non è
1880 \item[\errcode{ENOMEM}] gli indirizzi specificati non sono nello spazio di
1881 indirizzi del processo.
1886 Gli argomenti \param{start} e \param{lenght} hanno lo stesso identico
1887 significato degli analoghi di \func{madvise}, a cui si rimanda per la loro
1888 descrizione ma a differenza di quanto indicato dallo standard per questa
1889 funzione, su Linux un valore nullo di \param{len} è consentito.
1894 \begin{tabular}[c]{|l|l|}
1896 \textbf{Valore} & \textbf{Significato} \\
1899 \const{POSIX\_MADV\_DONTNEED}& analogo a \const{MADV\_DONTNEED}.\\
1900 \const{POSIX\_MADV\_NORMAL} & identico a \const{MADV\_NORMAL}.\\
1901 \const{POSIX\_MADV\_RANDOM} & identico a \const{MADV\_RANDOM}.\\
1902 \const{POSIX\_MADV\_SEQUENTIAL}& identico a \const{MADV\_SEQUENTIAL}.\\
1903 \const{POSIX\_MADV\_WILLNEED}& identico a \const{MADV\_WILLNEED}.\\
1906 \caption{Valori dell'argomento \param{advice} di \func{posix\_madvise}.}
1907 \label{tab:posix_madvise_advice_values}
1911 L'argomento \param{advice} invece può assumere solo i valori indicati in
1912 tab.~\ref{tab:posix_madvise_advice_values}, che riflettono gli analoghi di
1913 \func{madvise}, con lo stesso effetto per tutti tranne
1914 \const{POSIX\_MADV\_DONTNEED}. Infatti a partire dalle \acr{glibc} 2.6
1915 \const{POSIX\_MADV\_DONTNEED} viene ignorato, in quanto l'uso del
1916 corrispondente \const{MADV\_DONTNEED} di \func{madvise} ha, per la semantica
1917 imperativa, l'effetto immediato di far liberare le pagine da parte del kernel,
1918 che viene considerato distruttivo.
1922 \subsection{I/O vettorizzato: \func{readv} e \func{writev}}
1923 \label{sec:file_multiple_io}
1925 Una seconda modalità di I/O diversa da quella ordinaria è il cosiddetto
1926 \textsl{I/O vettorizzato}, che nasce per rispondere al caso abbastanza comune
1927 in cui ci si trova nell'esigenza di dover eseguire una serie multipla di
1928 operazioni di I/O, come una serie di letture o scritture di vari buffer. Un
1929 esempio tipico è quando i dati sono strutturati nei campi di una struttura ed
1930 essi devono essere caricati o salvati su un file. Benché l'operazione sia
1931 facilmente eseguibile attraverso una serie multipla di chiamate a \func{read}
1932 e \func{write}, ci sono casi in cui si vuole poter contare sulla atomicità
1933 delle operazioni di lettura e scrittura rispetto all'esecuzione del programma.
1935 Per questo motivo fino da BSD 4.2 vennero introdotte delle nuove
1936 \textit{system call} che permettessero di effettuare con una sola chiamata una
1937 serie di letture da, o scritture su, una serie di buffer, quello che poi venne
1938 chiamato \textsl{I/O vettorizzato}. Queste funzioni di sistema sono
1939 \funcd{readv} e \funcd{writev},\footnote{in Linux le due funzioni sono riprese
1940 da BSD4.4, esse sono previste anche dallo standard POSIX.1-2001.} ed i
1941 relativi prototipi sono:
1946 \fdecl{int readv(int fd, const struct iovec *vector, int count)}
1947 \fdecl{int writev(int fd, const struct iovec *vector, int count)}
1948 \fdesc{Eseguono rispettivamente una lettura o una scrittura vettorizzata.}
1951 {Le funzioni ritornano il numero di byte letti o scritti in caso di successo e
1952 $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
1954 \item[\errcode{EINVAL}] si è specificato un valore non valido per uno degli
1955 argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}).
1957 più tutti i valori, con lo stesso significato, che possono risultare
1958 dalle condizioni di errore di \func{read} e \func{write}.
1963 Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è
1964 riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono
1965 essere letti o scritti ed in che quantità. Il primo campo della struttura,
1966 \var{iov\_base}, contiene l'indirizzo del buffer ed il secondo,
1967 \var{iov\_len}, la dimensione dello stesso.
1969 \begin{figure}[!htb]
1970 \footnotesize \centering
1971 \begin{minipage}[c]{\textwidth}
1972 \includestruct{listati/iovec.h}
1975 \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O
1977 \label{fig:file_iovec}
1980 La lista dei buffer da utilizzare viene indicata attraverso l'argomento
1981 \param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza
1982 è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux
1983 usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta
1984 logica, che però è stata dismessa per restare aderenti allo standard
1985 POSIX.1-2001.} Ciascuna struttura dovrà essere inizializzata opportunamente
1986 per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento
1987 dei dati. Essi verranno letti (o scritti) nell'ordine in cui li si sono
1988 specificati nel vettore \param{vector}.
1990 La standardizzazione delle due funzioni all'interno della revisione
1991 POSIX.1-2001 prevede anche che sia possibile avere un limite al numero di
1992 elementi del vettore \param{vector}. Qualora questo sussista, esso deve essere
1993 indicato dal valore dalla costante \const{IOV\_MAX}, definita come le altre
1994 costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \headfile{limits.h}; lo
1995 stesso valore deve essere ottenibile in esecuzione tramite la funzione
1996 \func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi
1997 sez.~\ref{sec:sys_limits}).
1999 Nel caso di Linux il limite di sistema è di 1024, però se si usano le
2000 \acr{glibc} queste forniscono un \textit{wrapper} per le \textit{system call}
2001 che si accorge se una operazione supererà il precedente limite, in tal caso i
2002 dati verranno letti o scritti con le usuali \func{read} e \func{write} usando
2003 un buffer di dimensioni sufficienti appositamente allocato e sufficiente a
2004 contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo
2005 ma si perderà l'atomicità del trasferimento da e verso la destinazione finale.
2007 Si tenga presente infine che queste funzioni operano sui file con
2008 l'interfaccia dei file descriptor, e non è consigliabile mescolarle con
2009 l'interfaccia classica dei \textit{file stream} di
2010 sez.~\ref{sec:files_std_interface}; a causa delle bufferizzazioni interne di
2011 quest'ultima infatti si potrebbero avere risultati indefiniti e non
2012 corrispondenti a quanto aspettato.
2014 Come per le normali operazioni di lettura e scrittura, anche per l'\textsl{I/O
2015 vettorizzato} si pone il problema di poter effettuare le operazioni in
2016 maniera atomica a partire da un certa posizione sul file. Per questo motivo a
2017 partire dal kernel 2.6.30 sono state introdotte anche per l'\textsl{I/O
2018 vettorizzato} le analoghe delle funzioni \func{pread} e \func{pwrite} (vedi
2019 sez.~\ref{sec:file_read} e \ref{sec:file_write}); le due funzioni sono
2020 \funcd{preadv} e \funcd{pwritev} ed i rispettivi prototipi sono:\footnote{le
2021 due funzioni sono analoghe alle omonime presenti in BSD; le \textit{system
2022 call} usate da Linux (introdotte a partire dalla versione 2.6.30)
2023 utilizzano degli argomenti diversi per problemi collegati al formato a 64
2024 bit dell'argomento \param{offset}, che varia a seconda delle architetture,
2025 ma queste differenze vengono gestite dalle funzioni di librerie di libreria
2026 che mantengono l'interfaccia delle analoghe tratte da BSD.}
2031 \fdecl{int preadv(int fd, const struct iovec *vector, int count, off\_t
2033 \fdecl{int pwritev(int fd, const struct iovec *vector, int count, off\_t
2035 \fdesc{Eseguono una lettura o una scrittura vettorizzata a partire da una data
2036 posizione sul file.}
2039 { Le funzioni hanno gli stessi valori di ritorno delle corrispondenti
2040 \func{readv} e \func{writev} ed anche gli eventuali errori sono gli stessi,
2041 con in più quelli che si possono ottenere dalle possibili condizioni di
2042 errore di \func{lseek}.
2046 Le due funzioni eseguono rispettivamente una lettura o una scrittura
2047 vettorizzata a partire dalla posizione \param{offset} sul file indicato
2048 da \param{fd}, la posizione corrente sul file, come vista da eventuali altri
2049 processi che vi facciano riferimento, non viene alterata. A parte la presenza
2050 dell'ulteriore argomento il comportamento delle funzioni è identico alle
2051 precedenti \func{readv} e \func{writev}.
2053 Con l'uso di queste funzioni si possono evitare eventuali
2054 \itindex{race~condition} \textit{race condition} quando si deve eseguire la
2055 una operazione di lettura e scrittura vettorizzata a partire da una certa
2056 posizione su un file, mentre al contempo si possono avere in concorrenza
2057 processi che utilizzano lo stesso file descriptor (si ricordi quanto visto in
2058 sez.~\ref{sec:file_adv_func}) con delle chiamate a \func{lseek}.
2062 \subsection{L'I/O diretto fra file descriptor: \func{sendfile} e
2064 \label{sec:file_sendfile_splice}
2066 Uno dei problemi che si presentano nella gestione dell'I/O è quello in cui si
2067 devono trasferire grandi quantità di dati da un file descriptor ed un altro;
2068 questo usualmente comporta la lettura dei dati dal primo file descriptor in un
2069 buffer in memoria, da cui essi vengono poi scritti sul secondo.
2071 Benché il kernel ottimizzi la gestione di questo processo quando si ha a che
2072 fare con file normali, in generale quando i dati da trasferire sono molti si
2073 pone il problema di effettuare trasferimenti di grandi quantità di dati da
2074 \textit{kernel space} a \textit{user space} e all'indietro, quando in realtà
2075 potrebbe essere più efficiente mantenere tutto in \textit{kernel
2076 space}. Tratteremo in questa sezione alcune funzioni specialistiche che
2077 permettono di ottimizzare le prestazioni in questo tipo di situazioni.
2079 La prima funzione che è stata ideata per ottimizzare il trasferimento dei dati
2080 fra due file descriptor è \func{sendfile}.\footnote{la funzione è stata
2081 introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc}
2082 2.1.} La funzione è presente in diverse versioni di Unix (la si ritrova ad
2083 esempio in FreeBSD, HPUX ed altri Unix) ma non è presente né in POSIX.1-2001
2084 né in altri standard (pertanto si eviti di utilizzarla se si devono scrivere
2085 programmi portabili) per cui per essa vengono utilizzati prototipi e
2086 semantiche differenti. Nel caso di Linux il prototipo di \funcd{sendfile} è:
2090 \fhead{sys/sendfile.h}
2091 \fdecl{ssize\_t sendfile(int out\_fd, int in\_fd, off\_t *offset, size\_t
2093 \fdesc{Copia dei dati da un file descriptor ad un altro.}
2096 {La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
2097 per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2099 \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su
2100 \param{out\_fd} e la scrittura si bloccherebbe.
2101 \item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati
2102 (vedi sez.~\ref{sec:file_locking}), o \func{mmap} non è disponibile per
2104 \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}.
2105 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da
2108 ed inoltre \errcode{EBADF} e \errcode{EFAULT} nel loro significato
2112 La funzione copia direttamente \param{count} byte dal file descriptor
2113 \param{in\_fd} al file descriptor \param{out\_fd}. In caso di successo la
2114 funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a
2115 \param{out\_fd} e come per le ordinarie \func{read} e \func{write} questo
2116 valore può essere inferiore a quanto richiesto con \param{count}.
2118 Se il puntatore \param{offset} è nullo la funzione legge i dati a partire
2119 dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la
2120 posizione indicata dal valore puntato da \param{offset}; in questo caso detto
2121 valore sarà aggiornato, come \textit{value result argument}, per indicare la
2122 posizione del byte successivo all'ultimo che è stato letto, mentre la
2123 posizione corrente sul file non sarà modificata. Se invece \param{offset} è
2124 nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte
2125 letti da \param{in\_fd}.
2127 Fino ai kernel della serie 2.4 la funzione era utilizzabile su un qualunque
2128 file descriptor, e permetteva di sostituire la invocazione successiva di una
2129 \func{read} e una \func{write} (e l'allocazione del relativo buffer) con una
2130 sola chiamata a \funcd{sendfile}. In questo modo si poteva diminuire il numero
2131 di chiamate al sistema e risparmiare in trasferimenti di dati da
2132 \textit{kernel space} a \textit{user space} e viceversa. La massima utilità
2133 della funzione si ottiene comunque per il trasferimento di dati da un file su
2134 disco ad un socket di rete,\footnote{questo è il caso classico del lavoro
2135 eseguito da un server web, ed infatti Apache ha una opzione per il supporto
2136 esplicito di questa funzione.} dato che in questo caso diventa possibile
2137 effettuare il trasferimento diretto via DMA dal controller del disco alla
2138 scheda di rete, senza neanche allocare un buffer nel kernel (il meccanismo è
2139 detto \textit{zerocopy} in quanto i dati non vengono mai copiati dal kernel,
2140 che si limita a programmare solo le operazioni di lettura e scrittura via DMA)
2141 ottenendo la massima efficienza possibile senza pesare neanche sul processore.
2143 In seguito però ci si accorse che, fatta eccezione per il trasferimento
2144 diretto da file a socket, non sempre \func{sendfile} comportava miglioramenti
2145 significativi delle prestazioni rispetto all'uso in sequenza di \func{read} e
2146 \func{write}. Nel caso generico infatti il kernel deve comunque allocare un
2147 buffer ed effettuare la copia dei dati, e in tal caso spesso il guadagno
2148 ottenibile nel ridurre il numero di chiamate al sistema non compensa le
2149 ottimizzazioni che possono essere fatte da una applicazione in \textit{user
2150 space} che ha una conoscenza diretta su come questi sono strutturati, per
2151 cui in certi casi si potevano avere anche dei peggioramenti. Questo ha
2152 portato, per i kernel della serie 2.6,\footnote{per alcune motivazioni di
2153 questa scelta si può fare riferimento a quanto illustrato da Linus Torvalds
2154 in \url{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}.}
2155 alla decisione di consentire l'uso della funzione soltanto quando il file da
2156 cui si legge supporta le operazioni di \textit{memory mapping} (vale a dire
2157 non è un socket) e quello su cui si scrive è un socket; in tutti gli altri
2158 casi l'uso di \func{sendfile} da luogo ad un errore di \errcode{EINVAL}.
2160 Nonostante ci possano essere casi in cui \func{sendfile} non migliora le
2161 prestazioni, resta il dubbio se la scelta di disabilitarla sempre per il
2162 trasferimento fra file di dati sia davvero corretta. Se ci sono peggioramenti
2163 di prestazioni infatti si può sempre fare ricorso al metodo ordinario, ma
2164 lasciare a disposizione la funzione consentirebbe se non altro di semplificare
2165 la gestione della copia dei dati fra file, evitando di dover gestire
2166 l'allocazione di un buffer temporaneo per il loro trasferimento. Comunque a
2167 partire dal kernel 2.6.33 la restrizione su \param{out\_fd} è stata rimossa e
2168 questo può essere un file qualunque, rimane però quella di non poter usare un
2169 socket per \param{in\_fd}.
2171 A partire dal kernel 2.6.17 come alternativa a \func{sendfile} è disponibile
2172 la nuova \textit{system call} \func{splice}. Lo scopo di questa funzione è
2173 quello di fornire un meccanismo generico per il trasferimento di dati da o
2174 verso un file, utilizzando un buffer gestito internamente dal
2175 kernel. Descritta in questi termini \func{splice} sembra semplicemente un
2176 ``\textsl{dimezzamento}'' di \func{sendfile}, nel senso che un trasferimento
2177 di dati fra due file con \func{sendfile} non sarebbe altro che la lettura
2178 degli stessi su un buffer seguita dalla relativa scrittura, cosa che in questo
2179 caso si dovrebbe eseguire con due chiamate a \func{splice}.
2181 In realtà le due \textit{system call} sono profondamente diverse nel loro
2182 meccanismo di funzionamento;\footnote{questo fino al kernel 2.6.23, dove
2183 \func{sendfile} è stata reimplementata in termini di \func{splice}, pur
2184 mantenendo disponibile la stessa interfaccia verso l'\textit{user space}.}
2185 \func{sendfile} infatti, come accennato, non necessita di avere a disposizione
2186 un buffer interno, perché esegue un trasferimento diretto di dati; questo la
2187 rende in generale più efficiente, ma anche limitata nelle sue applicazioni,
2188 dato che questo tipo di trasferimento è possibile solo in casi specifici che
2189 nel caso di Linux questi sono anche solo quelli in cui essa può essere
2190 effettivamente utilizzata.
2192 Il concetto che sta dietro a \func{splice} invece è diverso,\footnote{in
2193 realtà la proposta originale di Larry Mc Voy non differisce poi tanto negli
2194 scopi da \func{sendfile}, quello che rende \func{splice} davvero diversa è
2195 stata la reinterpretazione che ne è stata fatta nell'implementazione su
2196 Linux realizzata da Jens Anxboe, concetti che sono esposti sinteticamente
2197 dallo stesso Linus Torvalds in \url{http://kerneltrap.org/node/6505}.} si
2198 tratta semplicemente di una funzione che consente di fare in maniera del tutto
2199 generica delle operazioni di trasferimento di dati fra un file e un buffer
2200 gestito interamente in \textit{kernel space}. In questo caso il cuore della
2201 funzione (e delle affini \func{vmsplice} e \func{tee}, che tratteremo più
2202 avanti) è appunto l'uso di un buffer in \textit{kernel space}, e questo è
2203 anche quello che ne ha semplificato l'adozione, perché l'infrastruttura per la
2204 gestione di un tale buffer è presente fin dagli albori di Unix per la
2205 realizzazione delle \textit{pipe} (vedi sez.~\ref{sec:ipc_unix}). Dal punto di
2206 vista concettuale allora \func{splice} non è altro che una diversa interfaccia
2207 (rispetto alle \textit{pipe}) con cui utilizzare in \textit{user space}
2208 l'oggetto ``\textsl{buffer in kernel space}''.
2210 Così se per una \textit{pipe} o una \textit{fifo} il buffer viene utilizzato
2211 come area di memoria (vedi fig.~\ref{fig:ipc_pipe_singular}) dove appoggiare i
2212 dati che vengono trasferiti da un capo all'altro della stessa per creare un
2213 meccanismo di comunicazione fra processi, nel caso di \func{splice} il buffer
2214 viene usato o come fonte dei dati che saranno scritti su un file, o come
2215 destinazione dei dati che vengono letti da un file. La funzione fornisce
2216 quindi una interfaccia generica che consente di trasferire dati da un buffer
2217 ad un file o viceversa; il prototipo di \funcd{splice}, accessibile solo dopo
2218 aver definito la macro \macro{\_GNU\_SOURCE},\footnote{si ricordi che questa
2219 funzione non è contemplata da nessuno standard, è presente solo su Linux, e
2220 pertanto deve essere evitata se si vogliono scrivere programmi portabili.}
2225 \fdecl{long splice(int fd\_in, off\_t *off\_in, int fd\_out, off\_t
2226 *off\_out, size\_t len, \\
2227 \phantom{long splice(}unsigned int flags)}
2228 \fdesc{Trasferisce dati da un file verso una \textit{pipe} o viceversa.}
2231 {La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
2232 per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2234 \item[\errcode{EBADF}] uno o entrambi fra \param{fd\_in} e \param{fd\_out}
2235 non sono file descriptor validi o, rispettivamente, non sono stati
2236 aperti in lettura o scrittura.
2237 \item[\errcode{EINVAL}] il filesystem su cui si opera non supporta
2238 \func{splice}, oppure nessuno dei file descriptor è una \textit{pipe},
2240 è dato un valore a \param{off\_in} o \param{off\_out} ma il
2241 corrispondente file è un dispositivo che non supporta la funzione
2243 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
2245 \item[\errcode{ESPIPE}] o \param{off\_in} o \param{off\_out} non sono
2246 \val{NULL} ma il corrispondente file descriptor è una \textit{pipe}.
2252 La funzione esegue un trasferimento di \param{len} byte dal file descriptor
2253 \param{fd\_in} al file descriptor \param{fd\_out}, uno dei quali deve essere
2254 una \textit{pipe}; l'altro file descriptor può essere qualunque, questo
2255 significa che può essere, oltre che un file di dati, anche un altra
2256 \textit{pipe}, o un socket. Come accennato una \textit{pipe} non è altro che
2257 un buffer in \textit{kernel space}, per cui a seconda che essa sia usata
2258 per \param{fd\_in} o \param{fd\_out} si avrà rispettivamente la copia dei dati
2259 dal buffer al file o viceversa.
2261 In caso di successo la funzione ritorna il numero di byte trasferiti, che può
2262 essere, come per le normali funzioni di lettura e scrittura su file, inferiore
2263 a quelli richiesti; un valore negativo indicherà un errore mentre un valore
2264 nullo indicherà che non ci sono dati da trasferire (ad esempio si è giunti
2265 alla fine del file in lettura). Si tenga presente che, a seconda del verso del
2266 trasferimento dei dati, la funzione si comporta nei confronti del file
2267 descriptor che fa riferimento al file ordinario, come \func{read} o
2268 \func{write}, e pertanto potrà anche bloccarsi (a meno che non si sia aperto
2269 il suddetto file in modalità non bloccante).
2271 I due argomenti \param{off\_in} e \param{off\_out} consentono di specificare,
2272 come per l'analogo \param{offset} di \func{sendfile}, la posizione all'interno
2273 del file da cui partire per il trasferimento dei dati. Come per
2274 \func{sendfile} un valore nullo indica di usare la posizione corrente sul
2275 file, ed essa sarà aggiornata automaticamente secondo il numero di byte
2276 trasferiti. Un valore non nullo invece deve essere un puntatore ad una
2277 variabile intera che indica la posizione da usare; questa verrà aggiornata, al
2278 ritorno della funzione, al byte successivo all'ultimo byte trasferito.
2279 Ovviamente soltanto uno di questi due argomenti, e più precisamente quello che
2280 fa riferimento al file descriptor non associato alla \textit{pipe}, può essere
2281 specificato come valore non nullo.
2283 Infine l'argomento \param{flags} consente di controllare alcune
2284 caratteristiche del funzionamento della funzione; il contenuto è una maschera
2285 binaria e deve essere specificato come OR aritmetico dei valori riportati in
2286 tab.~\ref{tab:splice_flag}. Alcuni di questi valori vengono utilizzati anche
2287 dalle funzioni \func{vmsplice} e \func{tee} per cui la tabella riporta le
2288 descrizioni complete di tutti i valori possibili anche quando, come per
2289 \const{SPLICE\_F\_GIFT}, questi non hanno effetto su \func{splice}.
2294 \begin{tabular}[c]{|l|p{10cm}|}
2296 \textbf{Valore} & \textbf{Significato} \\
2299 \const{SPLICE\_F\_MOVE} & Suggerisce al kernel di spostare le pagine
2300 di memoria contenenti i dati invece di
2301 copiarle: per una maggiore efficienza
2302 \func{splice} usa quando possibile i
2303 meccanismi della memoria virtuale per
2304 eseguire i trasferimenti di dati. In maniera
2305 analoga a \func{mmap}), qualora le pagine non
2306 possano essere spostate dalla \textit{pipe} o
2307 il buffer non corrisponda a pagine intere
2308 esse saranno comunque copiate. Viene usato
2309 soltanto da \func{splice}.\\
2310 \const{SPLICE\_F\_NONBLOCK}& Richiede di operare in modalità non
2311 bloccante; questo flag influisce solo sulle
2312 operazioni che riguardano l'I/O da e verso la
2313 \textit{pipe}. Nel caso di \func{splice}
2314 questo significa che la funzione potrà
2315 comunque bloccarsi nell'accesso agli altri
2316 file descriptor (a meno che anch'essi non
2317 siano stati aperti in modalità non
2319 \const{SPLICE\_F\_MORE} & Indica al kernel che ci sarà l'invio di
2320 ulteriori dati in una \func{splice}
2321 successiva, questo è un suggerimento utile
2322 che viene usato quando \param{fd\_out} è un
2323 socket. Questa opzione consente di utilizzare
2324 delle opzioni di gestione dei socket che
2325 permettono di ottimizzare le trasmissioni via
2326 rete (si veda la descrizione di
2327 \const{TCP\_CORK} in
2328 sez.~\ref{sec:sock_tcp_udp_options} e quella
2329 di \const{MSG\_MORE} in
2330 sez.~\ref{sec:net_sendmsg}). Attualmente
2331 viene usato solo da \func{splice}, potrà essere
2332 implementato in futuro anche per
2333 \func{vmsplice} e \func{tee}.\\
2334 \const{SPLICE\_F\_GIFT} & Le pagine di memoria utente sono
2335 ``\textsl{donate}'' al kernel; questo
2336 significa che la cache delle pagine e i dati
2337 su disco potranno differire, e che
2338 l'applicazione non potrà modificare
2339 quest'area di memoria.
2340 Se impostato una seguente \func{splice} che
2341 usa \const{SPLICE\_F\_MOVE} potrà spostare le
2342 pagine con successo, altrimenti esse dovranno
2343 essere copiate; per usare questa opzione i
2344 dati dovranno essere opportunamente allineati
2345 in posizione ed in dimensione alle pagine di
2346 memoria. Viene usato soltanto da
2350 \caption{Le costanti che identificano i bit della maschera binaria
2351 dell'argomento \param{flags} di \func{splice}, \func{vmsplice} e
2353 \label{tab:splice_flag}
2357 Per capire meglio il funzionamento di \func{splice} vediamo un esempio con un
2358 semplice programma che usa questa funzione per effettuare la copia di un file
2359 su un altro senza utilizzare buffer in \textit{user space}. Lo scopo del
2360 programma è quello di eseguire la copia dei dati con \func{splice}, questo
2361 significa che si dovrà usare la funzione due volte, prima per leggere i dati
2362 dal file di ingresso e poi per scriverli su quello di uscita, appoggiandosi ad
2363 una \textit{pipe}: lo schema del flusso dei dati è illustrato in
2364 fig.~\ref{fig:splicecp_data_flux}.
2368 \includegraphics[height=3.5cm]{img/splice_copy}
2369 \caption{Struttura del flusso di dati usato dal programma \texttt{splicecp}.}
2370 \label{fig:splicecp_data_flux}
2373 Il programma si chiama \texttt{splicecp.c} ed il codice completo è disponibile
2374 coi sorgenti allegati alla guida, il corpo principale del programma, che non
2375 contiene la sezione di gestione delle opzioni, le funzioni di ausilio, le
2376 aperture dei file di ingresso e di uscita passati come argomenti e quella
2377 della \textit{pipe} intermedia, è riportato in fig.~\ref{fig:splice_example}.
2379 \begin{figure}[!htb]
2380 \footnotesize \centering
2381 \begin{minipage}[c]{\codesamplewidth}
2382 \includecodesample{listati/splicecp.c}
2385 \caption{Esempio di codice che usa \func{splice} per effettuare la copia di
2387 \label{fig:splice_example}
2390 Il ciclo principale (\texttt{\small 13-38}) inizia con la lettura dal file
2391 sorgente tramite la prima \func{splice} (\texttt{\small 14-15}), in questo
2392 caso si è usato come primo argomento il file descriptor del file sorgente e
2393 come terzo quello del capo in scrittura della \textit{pipe}. Il funzionamento
2394 delle \textit{pipe} e l'uso della coppia di file descriptor ad esse associati
2395 è trattato in dettaglio in sez.~\ref{sec:ipc_unix}; non ne parleremo qui dato
2396 che nell'ottica dell'uso di \func{splice} questa operazione corrisponde
2397 semplicemente al trasferimento dei dati dal file al buffer in \textit{kernel
2400 La lettura viene eseguita in blocchi pari alla dimensione specificata
2401 dall'opzione \texttt{-s} (il default è 4096); essendo in questo caso
2402 \func{splice} equivalente ad una \func{read} sul file, se ne controlla il
2403 valore di uscita in \var{nread} che indica quanti byte sono stati letti, se
2404 detto valore è nullo (\texttt{\small 16}) questo significa che si è giunti
2405 alla fine del file sorgente e pertanto l'operazione di copia è conclusa e si
2406 può uscire dal ciclo arrivando alla conclusione del programma (\texttt{\small
2407 59}). In caso di valore negativo (\texttt{\small 17-24}) c'è stato un
2408 errore ed allora si ripete la lettura (\texttt{\small 16}) se questo è dovuto
2409 ad una interruzione, o altrimenti si esce con un messaggio di errore
2410 (\texttt{\small 21-23}).
2412 Una volta completata con successo la lettura si avvia il ciclo di scrittura
2413 (\texttt{\small 25-37}); questo inizia (\texttt{\small 26-27}) con la
2414 seconda \func{splice} che cerca di scrivere gli \var{nread} byte letti, si
2415 noti come in questo caso il primo argomento faccia di nuovo riferimento alla
2416 \textit{pipe} (in questo caso si usa il capo in lettura, per i dettagli si
2417 veda al solito sez.~\ref{sec:ipc_unix}) mentre il terzo sia il file descriptor
2418 del file di destinazione.
2420 Di nuovo si controlla il numero di byte effettivamente scritti restituito in
2421 \var{nwrite} e in caso di errore al solito si ripete la scrittura se questo è
2422 dovuto a una interruzione o si esce con un messaggio negli altri casi
2423 (\texttt{\small 28-35}). Infine si chiude il ciclo di scrittura sottraendo
2424 (\texttt{\small 37}) il numero di byte scritti a quelli di cui è richiesta la
2425 scrittura,\footnote{in questa parte del ciclo \var{nread}, il cui valore
2426 iniziale è dato dai byte letti dalla precedente chiamata a \func{splice},
2427 viene ad assumere il significato di byte da scrivere.} così che il ciclo di
2428 scrittura venga ripetuto fintanto che il valore risultante sia maggiore di
2429 zero, indice che la chiamata a \func{splice} non ha esaurito tutti i dati
2430 presenti sul buffer.
2432 Si noti come il programma sia concettualmente identico a quello che si sarebbe
2433 scritto usando \func{read} al posto della prima \func{splice} e \func{write}
2434 al posto della seconda, utilizzando un buffer in \textit{user space} per
2435 eseguire la copia dei dati, solo che in questo caso non è stato necessario
2436 allocare nessun buffer e non si è trasferito nessun dato in \textit{user
2437 space}. Si noti anche come si sia usata la combinazione
2438 \texttt{SPLICE\_F\_MOVE | SPLICE\_F\_MORE } per l'argomento \param{flags} di
2439 \func{splice}, infatti anche se un valore nullo avrebbe dato gli stessi
2440 risultati, l'uso di questi flag, che si ricordi servono solo a dare
2441 suggerimenti al kernel, permette in genere di migliorare le prestazioni.
2443 Come accennato con l'introduzione di \func{splice} sono state realizzate anche
2444 altre due \textit{system call}, \func{vmsplice} e \func{tee}, che utilizzano
2445 la stessa infrastruttura e si basano sullo stesso concetto di manipolazione e
2446 trasferimento di dati attraverso un buffer in \textit{kernel space}; benché
2447 queste non attengono strettamente ad operazioni di trasferimento dati fra file
2448 descriptor, le tratteremo qui, essendo strettamente correlate fra loro.
2450 La prima funzione, \funcd{vmsplice}, è la più simile a \func{splice} e come
2451 indica il suo nome consente di trasferire i dati dalla memoria virtuale di un
2452 processo (ad esempio per un file mappato in memoria) verso una \textit{pipe};
2458 \fdecl{long vmsplice(int fd, const struct iovec *iov, unsigned long nr\_segs,\\
2459 \phantom{long vmsplice(}unsigned int flags)}
2460 \fdesc{Trasferisce dati dalla memoria di un processo verso una \textit{pipe}.}
2463 {La funzione ritorna il numero di byte trasferiti in caso di successo e $-1$
2464 per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2466 \item[\errcode{EBADF}] o \param{fd} non è un file descriptor valido o non
2467 fa riferimento ad una \textit{pipe}.
2468 \item[\errcode{EINVAL}] si è usato un valore nullo per \param{nr\_segs}
2469 oppure si è usato \const{SPLICE\_F\_GIFT} ma la memoria non è allineata.
2470 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
2476 La \textit{pipe} indicata da \param{fd} dovrà essere specificata tramite il
2477 file descriptor corrispondente al suo capo aperto in scrittura (di nuovo si
2478 faccia riferimento a sez.~\ref{sec:ipc_unix}), mentre per indicare quali
2479 segmenti della memoria del processo devono essere trasferiti verso di essa si
2480 dovrà utilizzare un vettore di strutture \struct{iovec} (vedi
2481 fig.~\ref{fig:file_iovec}), esattamente con gli stessi criteri con cui le si
2482 usano per l'I/O vettorizzato, indicando gli indirizzi e le dimensioni di
2483 ciascun segmento di memoria su cui si vuole operare; le dimensioni del
2484 suddetto vettore devono essere passate nell'argomento \param{nr\_segs} che
2485 indica il numero di segmenti di memoria da trasferire. Sia per il vettore che
2486 per il valore massimo di \param{nr\_segs} valgono le stesse limitazioni
2487 illustrate in sez.~\ref{sec:file_multiple_io}.
2489 In caso di successo la funzione ritorna il numero di byte trasferiti sulla
2490 \textit{pipe}. In generale, se i dati una volta creati non devono essere
2491 riutilizzati (se cioè l'applicazione che chiama \func{vmsplice} non
2492 modificherà più la memoria trasferita), è opportuno utilizzare
2493 per \param{flag} il valore \const{SPLICE\_F\_GIFT}; questo fa sì che il kernel
2494 possa rimuovere le relative pagine dalla cache della memoria virtuale, così
2495 che queste possono essere utilizzate immediatamente senza necessità di
2496 eseguire una copia dei dati che contengono.
2498 La seconda funzione aggiunta insieme a \func{splice} è \func{tee}, che deve il
2499 suo nome all'omonimo comando in \textit{user space}, perché in analogia con
2500 questo permette di duplicare i dati in ingresso su una \textit{pipe} su
2501 un'altra \textit{pipe}. In sostanza, sempre nell'ottica della manipolazione
2502 dei dati su dei buffer in \textit{kernel space}, la funzione consente di
2503 eseguire una copia del contenuto del buffer stesso. Il prototipo di
2504 \funcd{tee} è il seguente:
2508 \fdecl{long tee(int fd\_in, int fd\_out, size\_t len, unsigned int
2510 \fdesc{Duplica i dati da una \textit{pipe} ad un'altra.}
2513 {La funzione ritorna restituisce il numero di byte copiati in caso di successo
2514 e $-1$ per un errore, nel qual caso \var{errno} assumerà uno dei valori:
2516 \item[\errcode{EINVAL}] o uno fra \param{fd\_in} e \param{fd\_out} non fa
2517 riferimento ad una \textit{pipe} o entrambi fanno riferimento alla
2518 stessa \textit{pipe}.
2519 \item[\errcode{ENOMEM}] non c'è memoria sufficiente per l'operazione
2525 La funzione copia \param{len} byte del contenuto di una \textit{pipe} su di
2526 un'altra; \param{fd\_in} deve essere il capo in lettura della \textit{pipe}
2527 sorgente e \param{fd\_out} il capo in scrittura della \textit{pipe}
2528 destinazione; a differenza di quanto avviene con \func{read} i dati letti con
2529 \func{tee} da \param{fd\_in} non vengono \textsl{consumati} e restano
2530 disponibili sulla \textit{pipe} per una successiva lettura (di nuovo per il
2531 comportamento delle \textit{pipe} si veda sez.~\ref{sec:ipc_unix}). Al
2532 momento\footnote{quello della stesura di questo paragrafo, avvenuta il Gennaio
2533 2010, in futuro potrebbe essere implementato anche \const{SPLICE\_F\_MORE}.}
2534 il solo valore utilizzabile per \param{flag}, fra quelli elencati in
2535 tab.~\ref{tab:splice_flag}, è \const{SPLICE\_F\_NONBLOCK} che rende la
2536 funzione non bloccante.
2538 La funzione restituisce il numero di byte copiati da una \textit{pipe}
2539 all'altra (o $-1$ in caso di errore), un valore nullo indica che non ci sono
2540 byte disponibili da copiare e che il capo in scrittura della \textit{pipe} è
2541 stato chiuso; si tenga presente però che questo non avviene se si è impostato
2542 il flag \const{SPLICE\_F\_NONBLOCK}, in tal caso infatti si avrebbe un errore
2543 di \errcode{EAGAIN}. Un esempio di realizzazione del comando \texttt{tee}
2544 usando questa funzione, ripreso da quello fornito nella pagina di manuale e
2545 dall'esempio allegato al patch originale, è riportato in
2546 fig.~\ref{fig:tee_example}. Il programma consente di copiare il contenuto
2547 dello \textit{standard input} sullo \textit{standard output} e su un file
2548 specificato come argomento, il codice completo si trova nel file
2549 \texttt{tee.c} dei sorgenti allegati alla guida.
2551 \begin{figure}[!htb]
2552 \footnotesize \centering
2553 \begin{minipage}[c]{\codesamplewidth}
2554 \includecodesample{listati/tee.c}
2557 \caption{Esempio di codice che usa \func{tee} per copiare i dati dello
2558 standard input sullo standard output e su un file.}
2559 \label{fig:tee_example}
2562 La prima parte del programma, che si è omessa per brevità, si cura
2563 semplicemente di controllare che sia stato fornito almeno un argomento (il
2564 nome del file su cui scrivere), di aprirlo e che sia lo standard input che lo
2565 standard output corrispondano ad una \textit{pipe}.
2567 Il ciclo principale (\texttt{\small 11-32}) inizia con la chiamata a
2568 \func{tee} che duplica il contenuto dello standard input sullo standard output
2569 (\texttt{\small 13}), questa parte è del tutto analoga ad una lettura ed
2570 infatti come nell'esempio di fig.~\ref{fig:splice_example} si controlla il
2571 valore di ritorno della funzione in \var{len}; se questo è nullo significa che
2572 non ci sono più dati da leggere e si chiude il ciclo (\texttt{\small 14}), se
2573 è negativo c'è stato un errore, ed allora si ripete la chiamata se questo è
2574 dovuto ad una interruzione (\texttt{\small 15-48}) o si stampa un messaggio
2575 di errore e si esce negli altri casi (\texttt{\small 18-21}).
2577 Una volta completata la copia dei dati sullo \textit{standard output} si
2578 possono estrarre dallo \textit{standard input} e scrivere sul file, di nuovo
2579 su usa un ciclo di scrittura (\texttt{\small 24-31}) in cui si ripete una
2580 chiamata a \func{splice} (\texttt{\small 25}) fintanto che non si sono scritti
2581 tutti i \var{len} byte copiati in precedenza con \func{tee} (il funzionamento
2582 è identico all'analogo ciclo di scrittura del precedente esempio di
2583 fig.~\ref{fig:splice_example}).
2585 Infine una nota finale riguardo \func{splice}, \func{vmsplice} e \func{tee}:
2586 occorre sottolineare che benché finora si sia parlato di trasferimenti o copie
2587 di dati in realtà nella implementazione di queste \textit{system call} non è
2588 affatto detto che i dati vengono effettivamente spostati o copiati, il kernel
2589 infatti realizza le \textit{pipe} come un insieme di puntatori\footnote{per
2590 essere precisi si tratta di un semplice buffer circolare, un buon articolo
2591 sul tema si trova su \url{http://lwn.net/Articles/118750/}.} alle pagine di
2592 memoria interna che contengono i dati, per questo una volta che i dati sono
2593 presenti nella memoria del kernel tutto quello che viene fatto è creare i
2594 suddetti puntatori ed aumentare il numero di referenze; questo significa che
2595 anche con \func{tee} non viene mai copiato nessun byte, vengono semplicemente
2596 copiati i puntatori.
2598 % TODO?? dal 2.6.25 splice ha ottenuto il supporto per la ricezione su rete
2601 \subsection{Gestione avanzata dell'accesso ai dati dei file}
2602 \label{sec:file_fadvise}
2604 Nell'uso generico dell'interfaccia per l'accesso al contenuto dei file le
2605 operazioni di lettura e scrittura non necessitano di nessun intervento di
2606 supervisione da parte dei programmi, si eseguirà una \func{read} o una
2607 \func{write}, i dati verranno passati al kernel che provvederà ad effettuare
2608 tutte le operazioni (e a gestire il \textit{caching} dei dati) per portarle a
2609 termine in quello che ritiene essere il modo più efficiente.
2611 Il problema è che il concetto di migliore efficienza impiegato dal kernel è
2612 relativo all'uso generico, mentre esistono molti casi in cui ci sono esigenze
2613 specifiche dei singoli programmi, che avendo una conoscenza diretta di come
2614 verranno usati i file, possono necessitare di effettuare delle ottimizzazioni
2615 specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in
2616 questa sezione una serie funzioni che consentono ai programmi di ottimizzare
2617 il loro accesso ai dati dei file e controllare la gestione del relativo
2620 \itindbeg{read-ahead}
2622 Una prima funzione che può essere utilizzata per modificare la gestione
2623 ordinaria dell'I/O su un file è \funcd{readahead} (questa è una funzione
2624 specifica di Linux, introdotta con il kernel 2.4.13, e non deve essere usata
2625 se si vogliono scrivere programmi portabili), che consente di richiedere una
2626 lettura anticipata del contenuto dello stesso in cache, così che le seguenti
2627 operazioni di lettura non debbano subire il ritardo dovuto all'accesso al
2628 disco; il suo prototipo è:
2632 \fdecl{ssize\_t readahead(int fd, off64\_t *offset, size\_t count)}
2633 \fdesc{Esegue una lettura preventiva del contenuto di un file in cache.}
2636 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2637 caso \var{errno} assumerà uno dei valori:
2639 \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
2640 valido o non è aperto in lettura.
2641 \item[\errcode{EINVAL}] l'argomento \param{fd} si riferisce ad un tipo di
2642 file che non supporta l'operazione (come una \textit{pipe} o un socket).
2647 La funzione richiede che venga letto in anticipo il contenuto del file
2648 \param{fd} a partire dalla posizione \param{offset} e per un ammontare di
2649 \param{count} byte, in modo da portarlo in cache. La funzione usa la memoria
2650 virtuale ed il meccanismo della paginazione per cui la lettura viene eseguita
2651 in blocchi corrispondenti alle dimensioni delle pagine di memoria, ed i valori
2652 di \param{offset} e \param{count} vengono arrotondati di conseguenza.
2654 La funzione estende quello che è un comportamento normale del kernel che,
2655 quando si legge un file, aspettandosi che l'accesso prosegua, esegue sempre
2656 una lettura preventiva di una certa quantità di dati; questo meccanismo di
2657 lettura anticipata viene chiamato \textit{read-ahead}, da cui deriva il nome
2658 della funzione. La funzione \func{readahead}, per ottimizzare gli accessi a
2659 disco, effettua la lettura in cache della sezione richiesta e si blocca
2660 fintanto che questa non viene completata. La posizione corrente sul file non
2661 viene modificata ed indipendentemente da quanto indicato con \param{count} la
2662 lettura dei dati si interrompe una volta raggiunta la fine del file.
2664 Si può utilizzare questa funzione per velocizzare le operazioni di lettura
2665 all'interno di un programma tutte le volte che si conosce in anticipo quanti
2666 dati saranno necessari nelle elaborazioni successive. Si potrà così
2667 concentrare in un unico momento (ad esempio in fase di inizializzazione) la
2668 lettura dei dati da disco, così da ottenere una migliore velocità di risposta
2669 nelle operazioni successive.
2671 \itindend{read-ahead}
2673 Il concetto di \func{readahead} viene generalizzato nello standard
2674 POSIX.1-2001 dalla funzione \func{posix\_fadvise} (anche se
2675 l'argomento \param{len} è stato modificato da \type{size\_t} a \type{off\_t}
2676 nella revisione POSIX.1-2003 TC1) che consente di ``\textsl{avvisare}'' il
2677 kernel sulle modalità con cui si intende accedere nel futuro ad una certa
2678 porzione di un file, così che esso possa provvedere le opportune
2679 ottimizzazioni; il prototipo di \funcd{posix\_fadvise}\footnote{la funzione è
2680 stata introdotta su Linux solo a partire dal kernel 2.5.60, ed è disponibile
2681 soltanto se è stata definita la macro \macro{\_XOPEN\_SOURCE} ad valore di
2682 almeno \texttt{600} o la macro \macro{\_POSIX\_C\_SOURCE} ad valore di
2683 almeno \texttt{200112L}.} è:
2688 \fdecl{int posix\_fadvise(int fd, off\_t offset, off\_t len, int advice)}
2689 \fdesc{Dichiara al kernel le future modalità di accesso ad un file.}
2692 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2693 caso \var{errno} assumerà uno dei valori:
2695 \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
2697 \item[\errcode{EINVAL}] il valore di \param{advice} non è valido o
2698 \param{fd} si riferisce ad un tipo di file che non supporta l'operazione
2699 (come una \textit{pipe} o un socket).
2700 \item[\errcode{ESPIPE}] previsto dallo standard se \param{fd} è una
2701 \textit{pipe} o un socket (ma su Linux viene restituito
2707 La funzione dichiara al kernel le modalità con cui intende accedere alla
2708 regione del file indicato da \param{fd} che inizia alla posizione
2709 \param{offset} e si estende per \param{len} byte. Se per \param{len} si usa un
2710 valore nullo la regione coperta sarà da \param{offset} alla fine del file, ma
2711 questo è vero solo per le versioni più recenti, fino al kernel 2.6.6 il valore
2712 nullo veniva interpretato letteralmente. Le modalità sono indicate
2713 dall'argomento \param{advice} che è una maschera binaria dei valori illustrati
2714 in tab.~\ref{tab:posix_fadvise_flag}, che riprendono il significato degli
2715 analoghi già visti in sez.~\ref{sec:file_memory_map} per
2716 \func{madvise}.\footnote{dato che si tratta dello stesso tipo di funzionalità,
2717 in questo caso applicata direttamente al sistema ai contenuti di un file
2718 invece che alla sua mappatura in memoria.} Si tenga presente comunque che la
2719 funzione dà soltanto un avvertimento, non esiste nessun vincolo per il kernel,
2720 che utilizza semplicemente l'informazione.
2725 \begin{tabular}[c]{|l|p{10cm}|}
2727 \textbf{Valore} & \textbf{Significato} \\
2730 \const{POSIX\_FADV\_NORMAL} & Non ci sono avvisi specifici da fare
2731 riguardo le modalità di accesso, il
2732 comportamento sarà identico a quello che si
2733 avrebbe senza nessun avviso.\\
2734 \const{POSIX\_FADV\_SEQUENTIAL}& L'applicazione si aspetta di accedere di
2735 accedere ai dati specificati in maniera
2736 sequenziale, a partire dalle posizioni più
2738 \const{POSIX\_FADV\_RANDOM} & I dati saranno letti in maniera
2739 completamente causale.\\
2740 \const{POSIX\_FADV\_NOREUSE} & I dati saranno acceduti una sola volta.\\
2741 \const{POSIX\_FADV\_WILLNEED}& I dati saranno acceduti a breve.\\
2742 \const{POSIX\_FADV\_DONTNEED}& I dati non saranno acceduti a breve.\\
2745 \caption{Valori delle costanti usabili per l'argomento \param{advice} di
2746 \func{posix\_fadvise}, che indicano la modalità con cui si intende accedere
2748 \label{tab:posix_fadvise_flag}
2751 Come \func{madvise} anche \func{posix\_fadvise} si appoggia al sistema della
2752 memoria virtuale ed al meccanismo standard del \textit{read-ahead} utilizzato
2753 dal kernel; in particolare utilizzando il valore
2754 \const{POSIX\_FADV\_SEQUENTIAL} si raddoppia la dimensione dell'ammontare di
2755 dati letti preventivamente rispetto al default, aspettandosi appunto una
2756 lettura sequenziale che li utilizzerà, mentre con \const{POSIX\_FADV\_RANDOM}
2757 si disabilita del tutto il suddetto meccanismo, dato che con un accesso del
2758 tutto casuale è inutile mettersi a leggere i dati immediatamente successivi
2759 gli attuali; infine l'uso di \const{POSIX\_FADV\_NORMAL} consente di
2760 riportarsi al comportamento di default.
2762 Le due modalità \const{POSIX\_FADV\_NOREUSE} e \const{POSIX\_FADV\_WILLNEED}
2763 fino al kernel 2.6.18 erano equivalenti, a partire da questo kernel la prima
2764 viene non ha più alcun effetto, mentre la seconda dà inizio ad una lettura in
2765 cache della regione del file indicata. La quantità di dati che verranno letti
2766 è ovviamente limitata in base al carico che si viene a creare sul sistema
2767 della memoria virtuale, ma in genere una lettura di qualche megabyte viene
2768 sempre soddisfatta (ed un valore superiore è solo raramente di qualche
2769 utilità). In particolare l'uso di \const{POSIX\_FADV\_WILLNEED} si può
2770 considerare l'equivalente POSIX di \func{readahead}.
2772 Infine con \const{POSIX\_FADV\_DONTNEED} si dice al kernel di liberare le
2773 pagine di cache occupate dai dati presenti nella regione di file indicata.
2774 Questa è una indicazione utile che permette di alleggerire il carico sulla
2775 cache, ed un programma può utilizzare periodicamente questa funzione per
2776 liberare pagine di memoria da dati che non sono più utilizzati per far posto a
2777 nuovi dati utili; la pagina di manuale riporta l'esempio dello streaming di
2778 file di grosse dimensioni, dove le pagine occupate dai dati già inviati
2779 possono essere tranquillamente scartate.
2781 Sia \func{posix\_fadvise} che \func{readahead} attengono alla ottimizzazione
2782 dell'accesso in lettura; lo standard POSIX.1-2001 prevede anche una funzione
2783 specifica per le operazioni di scrittura, \funcd{posix\_fallocate} (la
2784 funzione è stata introdotta a partire dalle glibc 2.1.94), che consente di
2785 preallocare dello spazio disco per assicurarsi che una seguente scrittura non
2786 fallisca, il suo prototipo, anch'esso disponibile solo se si definisce la
2787 macro \macro{\_XOPEN\_SOURCE} ad almeno 600, è:
2791 \fdecl{int posix\_fallocate(int fd, off\_t offset, off\_t len)}
2792 \fdesc{Richiede la allocazione di spazio disco per un file.}
2795 {La funzione ritorna $0$ in caso di successo e direttamente un codice di
2796 errore altrimenti, in tal caso \var{errno} non viene impostato, e si otterrà
2797 direttamente uno dei valori:
2799 \item[\errcode{EBADF}] l'argomento \param{fd} non è un file descriptor
2800 valido o non è aperto in scrittura.
2801 \item[\errcode{EINVAL}] o \param{offset} o \param{len} sono minori di
2803 \item[\errcode{EFBIG}] il valore di (\param{offset} + \param{len}) eccede
2804 la dimensione massima consentita per un file.
2805 \item[\errcode{ENODEV}] l'argomento \param{fd} non fa riferimento ad un
2807 \item[\errcode{ENOSPC}] non c'è sufficiente spazio disco per eseguire
2809 \item[\errcode{ESPIPE}] l'argomento \param{fd} è una \textit{pipe}.
2814 La funzione assicura che venga allocato sufficiente spazio disco perché sia
2815 possibile scrivere sul file indicato dall'argomento \param{fd} nella regione
2816 che inizia dalla posizione \param{offset} e si estende per \param{len} byte;
2817 se questa regione si estende oltre la fine del file le dimensioni di
2818 quest'ultimo saranno incrementate di conseguenza. Dopo aver eseguito con
2819 successo la funzione è garantito che una successiva scrittura nella regione
2820 indicata non fallirà per mancanza di spazio disco. La funzione non ha nessun
2821 effetto né sul contenuto, né sulla posizione corrente del file.
2823 Ci si può chiedere a cosa possa servire una funzione come
2824 \func{posix\_fallocate} dato che è sempre possibile ottenere l'effetto voluto
2825 eseguendo esplicitamente sul file la scrittura di una serie di zeri (usando
2826 \funcd{pwrite} per evitare spostamenti della posizione corrente sul file) per
2827 l'estensione di spazio necessaria qualora il file debba essere esteso o abbia
2828 dei buchi.\footnote{si ricordi che occorre scrivere per avere l'allocazione e
2829 che l'uso di \func{truncate} per estendere un file creerebbe soltanto uno
2830 \textit{sparse file} (vedi sez.~\ref{sec:file_lseek}) senza una effettiva
2831 allocazione dello spazio disco.} In realtà questa è la modalità con cui la
2832 funzione veniva realizzata nella prima versione fornita dalle \acr{glibc}, per
2833 cui la funzione costituiva in sostanza soltanto una standardizzazione delle
2834 modalità di esecuzione di questo tipo di allocazioni.
2836 Questo metodo, anche se funzionante, comporta però l'effettiva esecuzione una
2837 scrittura su tutto lo spazio disco necessario, da fare al momento della
2838 richiesta di allocazione, pagandone il conseguente prezzo in termini di
2839 prestazioni; il tutto quando in realtà servirebbe solo poter riservare lo
2840 spazio per poi andarci a scrivere, una sola volta, quando il contenuto finale
2841 diventa effettivamente disponibile. Per poter fare tutto questo è però
2842 necessario il supporto da parte del kernel, e questo è divenuto disponibile
2843 solo a partire dal kernel 2.6.23 in cui è stata introdotta la nuova
2844 \textit{system call} \func{fallocate},\footnote{non è detto che la funzione
2845 sia disponibile per tutti i filesystem, ad esempio per XFS il supporto è
2846 stato introdotto solo a partire dal kernel 2.6.25.} che consente di
2847 realizzare direttamente all'interno del kernel l'allocazione dello spazio
2848 disco così da poter realizzare una versione di \func{posix\_fallocate} con
2849 prestazioni molto più elevate; nelle \acr{glibc} la nuova \textit{system call}
2850 viene sfruttata per la realizzazione di \func{posix\_fallocate} a partire
2851 dalla versione 2.10.
2853 Trattandosi di una funzione di servizio, ed ovviamente disponibile
2854 esclusivamente su Linux, inizialmente \funcd{fallocate} non era stata definita
2855 come funzione di libreria,\footnote{pertanto poteva essere invocata soltanto
2856 in maniera indiretta con l'ausilio di \func{syscall}, vedi
2857 sez.~\ref{sec:proc_syscall}, come \code{long fallocate(int fd, int mode,
2858 loff\_t offset, loff\_t len)}.} ma a partire dalle \acr{glibc} 2.10 è
2859 stato fornito un supporto esplicito; il suo prototipo è:
2863 \fdecl{int fallocate(int fd, int mode, off\_t offset, off\_t len)}
2864 \fdesc{Prealloca dello spazio disco per un file.}
2867 {La funzione ritorna $0$ in caso di successo e $-1$ per un errore, nel qual
2868 caso \var{errno} assumerà uno dei valori:
2870 \item[\errcode{EBADF}] \param{fd} non fa riferimento ad un file descriptor
2871 valido aperto in scrittura.
2872 \item[\errcode{EFBIG}] la somma di \param{offset} e \param{len} eccede le
2873 dimensioni massime di un file.
2874 \item[\errcode{EINVAL}] \param{offset} è minore di zero o \param{len} è
2875 minore o uguale a zero.
2876 \item[\errcode{ENODEV}] \param{fd} non fa riferimento ad un file ordinario
2878 \item[\errcode{EPERM}] il file è immutabile o \textit{append-only} (vedi
2879 sez.~\ref{sec:file_perm_overview}).
2880 \item[\errcode{ENOSYS}] il filesystem contenente il file associato
2881 a \param{fd} non supporta \func{fallocate}.
2882 \item[\errcode{EOPNOTSUPP}] il filesystem contenente il file associato
2883 a \param{fd} non supporta l'operazione \param{mode}.
2885 ed inoltre \errval{EINTR}, \errval{EIO} e \errval{ENOSPC} nel loro significato
2889 La funzione prende gli stessi argomenti di \func{posix\_fallocate} con lo
2890 stesso significato, a cui si aggiunge l'argomento \param{mode} che indica le
2891 modalità di allocazione; se questo è nullo il comportamento è identico a
2892 quello di \func{posix\_fallocate} e si può considerare \func{fallocate} come
2893 l'implementazione ottimale della stessa a livello di kernel.
2895 Inizialmente l'unico altro valore possibile per \param{mode} era
2896 \const{FALLOC\_FL\_KEEP\_SIZE} che richiede che la dimensione del file (quella
2897 ottenuta nel campo \var{st\_size} di una struttura \struct{stat} dopo una
2898 chiamata a \texttt{fstat}) non venga modificata anche quando la somma
2899 di \param{offset} e \param{len} eccede la dimensione corrente, che serve
2900 quando si deve comunque preallocare dello spazio per scritture in append. In
2901 seguito sono stati introdotti altri valori, riassunti in
2902 tab.\ref{tab:fallocate_mode}, per compiere altre operazioni relative alla
2903 allocazione dello spazio disco dei file.
2908 \begin{tabular}[c]{|l|p{10cm}|}
2910 \textbf{Valore} & \textbf{Significato} \\
2913 \const{FALLOC\_FL\_INSERT} & .\\
2914 \const{FALLOC\_FL\_COLLAPSE\_RANGE}& .\\
2915 \const{FALLOC\_FL\_KEEP\_SIZE} & Mantiene invariata la dimensione del
2916 file, pur allocando lo spazio disco anche
2917 oltre la dimensione corrente del file.\\
2918 \const{FALLOC\_FL\_PUNCH\_HOLE}& Crea un \textsl{buco} nel file (vedi
2919 sez.~\ref{sec:file_lseek}) rendendolo una
2920 \textit{sparse file} (dal kernel
2922 \const{FALLOC\_FL\_ZERO\_RANGE}& .\\
2925 \caption{Valori delle costanti usabili per l'argomento \param{mode} di
2927 \label{tab:fallocate_mode}
2930 In particolare con \const{FALLOC\_FL\_PUNCH\_HOLE} è possibile scartare il
2931 contenuto della sezione di file indicata da \param{offser} e \param{len},
2932 creando un \textsl{buco} (si ricordi quanto detto in
2933 sez.~\ref{sec:file_lseek}); i blocchi del file interamente contenuti
2934 nell'intervallo verranno disallocati, la parte di intervallo contenuta
2935 parzialmente in altri blocchi verrà riempita con zeri e la lettura dal file
2936 restituirà degli zeri per tutto l'intervallo indicato. In sostanza si rende il
2937 file uno \textit{sparse file} a posteriori.
2939 % vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/
2940 % http://kernelnewbies.org/Linux_2_6_23
2942 % TODO aggiungere FALLOC_FL_ZERO_RANGE e FALLOC_FL_COLLAPSE_RANGE, inseriti
2943 % nel kernel 3.15 (sul secondo vedi http://lwn.net/Articles/589260/), vedi
2944 % anche http://lwn.net/Articles/629965/
2946 % TODO aggiungere FALLOC_FL_INSERT vedi http://lwn.net/Articles/629965/
2949 % TODO non so dove trattarli, ma dal 2.6.39 ci sono i file handle, vedi
2950 % http://lwn.net/Articles/432757/
2953 % LocalWords: dell'I locking multiplexing cap sez system call socket BSD GID
2954 % LocalWords: descriptor client deadlock NONBLOCK EAGAIN polling select kernel
2955 % LocalWords: pselect like sys unistd int fd readfds writefds exceptfds struct
2956 % LocalWords: timeval errno EBADF EINTR EINVAL ENOMEM sleep tab signal void of
2957 % LocalWords: CLR ISSET SETSIZE POSIX read NULL nell'header l'header glibc fig
2958 % LocalWords: libc header psignal sigmask SOURCE XOPEN timespec sigset race DN
2959 % LocalWords: condition sigprocmask tut self trick oldmask poll XPG pollfd l'I
2960 % LocalWords: ufds unsigned nfds RLIMIT NOFILE EFAULT ndfs events revents hung
2961 % LocalWords: POLLIN POLLRDNORM POLLRDBAND POLLPRI POLLOUT POLLWRNORM POLLERR
2962 % LocalWords: POLLWRBAND POLLHUP POLLNVAL POLLMSG SysV stream ASYNC SETOWN FAQ
2963 % LocalWords: GETOWN fcntl SETFL SIGIO SETSIG Stevens driven siginfo sigaction
2964 % LocalWords: all'I nell'I Frequently Unanswered Question SIGHUP lease holder
2965 % LocalWords: breaker truncate write SETLEASE arg RDLCK WRLCK UNLCK GETLEASE
2966 % LocalWords: uid capabilities capability EWOULDBLOCK notify dall'OR ACCESS st
2967 % LocalWords: pread readv MODIFY pwrite writev ftruncate creat mknod mkdir buf
2968 % LocalWords: symlink rename DELETE unlink rmdir ATTRIB chown chmod utime lio
2969 % LocalWords: MULTISHOT thread linkando librt layer aiocb asyncronous control
2970 % LocalWords: block ASYNCHRONOUS lseek fildes nbytes reqprio PRIORITIZED sigev
2971 % LocalWords: PRIORITY SCHEDULING opcode listio sigevent signo value function
2972 % LocalWords: aiocbp ENOSYS append error const EINPROGRESS fsync return ssize
2973 % LocalWords: DSYNC fdatasync SYNC cancel ECANCELED ALLDONE CANCELED suspend
2974 % LocalWords: NOTCANCELED list nent timout sig NOP WAIT NOWAIT size count iov
2975 % LocalWords: iovec vector EOPNOTSUPP EISDIR len memory mapping mapped swap NB
2976 % LocalWords: mmap length prot flags off MAP FAILED ANONYMOUS EACCES SHARED SH
2977 % LocalWords: only ETXTBSY DENYWRITE ENODEV filesystem EPERM EXEC noexec table
2978 % LocalWords: ENFILE lenght segment violation SIGSEGV FIXED msync munmap copy
2979 % LocalWords: DoS Denial Service EXECUTABLE NORESERVE LOCKED swapping stack fs
2980 % LocalWords: GROWSDOWN ANON POPULATE prefaulting SIGBUS fifo VME fork old SFD
2981 % LocalWords: exec atime ctime mtime mprotect addr mremap address new Failed
2982 % LocalWords: long MAYMOVE realloc VMA virtual Ingo Molnar remap pages pgoff
2983 % LocalWords: dall' fault cache linker prelink advisory discrectionary lock fl
2984 % LocalWords: flock shared exclusive operation dup inode linked NFS cmd ENOLCK
2985 % LocalWords: EDEADLK whence SEEK CUR type pid GETLK SETLK SETLKW HP EACCESS
2986 % LocalWords: switch bsd lockf mandatory SVr sgid group root mount mand TRUNC
2987 % LocalWords: SVID UX Documentation sendfile dnotify inotify NdA ppoll fds add
2988 % LocalWords: init EMFILE FIONREAD ioctl watch char pathname uint mask ENOSPC
2989 % LocalWords: CLOSE NOWRITE MOVE MOVED FROM TO rm wd event page ctl acquired
2990 % LocalWords: attribute Universe epoll Solaris kqueue level triggered Jonathan
2991 % LocalWords: Lemon BSDCON edge Libenzi kevent backporting epfd EEXIST ENOENT
2992 % LocalWords: MOD wait EPOLLIN EPOLLOUT EPOLLRDHUP SOCK EPOLLPRI EPOLLERR one
2993 % LocalWords: EPOLLHUP EPOLLET EPOLLONESHOT shot maxevents ctlv ALL DONT HPUX
2994 % LocalWords: FOLLOW ONESHOT ONLYDIR FreeBSD EIO caching sysctl instances name
2995 % LocalWords: watches IGNORED ISDIR OVERFLOW overflow UNMOUNT queued cookie ls
2996 % LocalWords: NUL sizeof casting printevent nread limits sysconf SC wrapper Di
2997 % LocalWords: splice result argument DMA controller zerocopy Linus Larry Voy
2998 % LocalWords: Jens Anxboe vmsplice seek ESPIPE GIFT TCP CORK MSG splicecp nr
2999 % LocalWords: nwrite segs patch readahead posix fadvise TC advice FADV NORMAL
3000 % LocalWords: SEQUENTIAL NOREUSE WILLNEED DONTNEED streaming fallocate EFBIG
3001 % LocalWords: POLLRDHUP half close pwait Gb madvise MADV ahead REMOVE tmpfs it
3002 % LocalWords: DONTFORK DOFORK shmfs preadv pwritev syscall linux loff head XFS
3003 % LocalWords: MERGEABLE EOVERFLOW prealloca hole FALLOC KEEP stat fstat union
3004 % LocalWords: conditions sigwait CLOEXEC signalfd sizemask SIGKILL SIGSTOP ssi
3005 % LocalWords: sigwaitinfo FifoReporter Windows ptr sigqueue named timerfd TFD
3006 % LocalWords: clockid CLOCK MONOTONIC REALTIME itimerspec interval Resource
3007 % LocalWords: ABSTIME gettime temporarily unavailable SIGINT SIGQUIT SIGTERM
3008 % LocalWords: sigfd fifofd break siginf names starting echo Message from Got
3009 % LocalWords: message kill received means exit TLOCK ULOCK EPOLLWAKEUP
3012 %%% Local Variables:
3014 %%% TeX-master: "gapil"