X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=6c2bfccc4cb177bc1309572285b2c380b871e32b;hp=9a717f2e9b76b4370dd2d4ec1c24b1674f628221;hb=eb9d45f3cc5cfc16b8c478d232080873a202af1c;hpb=3dbc1b59f029f1ae890d56f209e8ddacaf468a73 diff --git a/fileadv.tex b/fileadv.tex index 9a717f2..6c2bfcc 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1,4 +1,4 @@ -gb%% fileadv.tex +%% fileadv.tex %% %% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free @@ -410,13 +410,13 @@ nel campo \var{revents} per notificare delle condizioni di errore. \hline \const{POLLIN} & È possibile la lettura.\\ \const{POLLRDNORM}& Sono disponibili in lettura dati normali.\\ - \const{POLLRDBAND}& Sono disponibili in lettura dati prioritari. \\ + \const{POLLRDBAND}& Sono disponibili in lettura dati prioritari.\\ \const{POLLPRI} & È possibile la lettura di \itindex{out-of-band} dati urgenti.\\ \hline \const{POLLOUT} & È possibile la scrittura immediata.\\ - \const{POLLWRNORM}& È possibile la scrittura di dati normali. \\ - \const{POLLWRBAND}& È possibile la scrittura di dati prioritari. \\ + \const{POLLWRNORM}& È possibile la scrittura di dati normali.\\ + \const{POLLWRBAND}& È possibile la scrittura di dati prioritari.\\ \hline \const{POLLERR} & C'è una condizione di errore.\\ \const{POLLHUP} & Si è verificato un hung-up.\\ @@ -668,15 +668,15 @@ delle operazioni cui fanno riferimento. \textbf{Valore} & \textbf{Significato} \\ \hline \hline - \const{EPOLL\_CTL\_ADD}& aggiunge un nuovo file descriptor da osservare + \const{EPOLL\_CTL\_ADD}& Aggiunge un nuovo file descriptor da osservare \param{fd} alla lista dei file descriptor controllati tramite \param{epfd}, in \param{event} devono essere specificate le modalità di osservazione.\\ - \const{EPOLL\_CTL\_MOD}& modifica le modalità di osservazione del file + \const{EPOLL\_CTL\_MOD}& Modifica le modalità di osservazione del file descriptor \param{fd} secondo il contenuto di \param{event}.\\ - \const{EPOLL\_CTL\_DEL}& rimuove il file descriptor \param{fd} dalla lista + \const{EPOLL\_CTL\_DEL}& Rimuove il file descriptor \param{fd} dalla lista dei file controllati tramite \param{epfd}.\\ \hline \end{tabular} @@ -694,13 +694,15 @@ file descriptor di \textit{epoll}, ma non lo stesso \param{epfd}. L'ultimo argomento, \param{event}, deve essere un puntatore ad una struttura di tipo \struct{epoll\_event}, ed ha significato solo con le operazioni -\const{EPOLL\_CTL\_MOD} e \const{EPOLL\_CTL\_ADD} per le quali serve ad +\const{EPOLL\_CTL\_MOD} e \const{EPOLL\_CTL\_ADD}, per le quali serve ad indicare quale tipo di evento relativo ad \param{fd} si vuole che sia tenuto -sotto controllo. L'argomento viene ignorato con +sotto controllo. L'argomento viene ignorato con l'operazione \const{EPOLL\_CTL\_DEL}.\footnote{fino al kernel 2.6.9 era comunque richiesto che questo fosse un puntatore valido, anche se poi veniva ignorato, a partire dal 2.6.9 si può specificare anche anche un valore \texttt{NULL}.} + + \begin{figure}[!htb] \footnotesize \centering \begin{minipage}[c]{15cm} @@ -717,10 +719,11 @@ La struttura \struct{epoll\_event} quest'ultima serve sia in ingresso (quando usata con \func{epoll\_ctl}) ad impostare quali eventi osservare, che in uscita (nei risultati ottenuti con \func{epoll\_wait}) per ricevere le notifiche degli eventi avvenuti. La sua -definizione è riportata in fig.~\ref{fig:epoll_event}; il primo campo, -\var{events}, è una maschera binaria in cui ciascun bit corrisponde o ad un -tipo di evento, o una modalità di notifica. Detto campo deve essere -specificato come OR aritmetico delle costanti riportate in +definizione è riportata in fig.~\ref{fig:epoll_event}. + +Il primo campo, \var{events}, è una maschera binaria in cui ciascun bit +corrisponde o ad un tipo di evento, o una modalità di notifica; detto campo +deve essere specificato come OR aritmetico delle costanti riportate in tab.~\ref{tab:epoll_events}. Il secondo campo, \var{data}, serve ad indicare a quale file descriptor si intende fare riferimento, ed in astratto può contenere un valore qualsiasi che permetta di identificarlo, di norma comunque @@ -758,41 +761,61 @@ si usa come valore lo stesso \param{fd}. descriptor associato.\footnotemark\\ \hline \end{tabular} - \caption{Valori del campo \param{events} di \struct{epoll\_event}.} + \caption{Costanti che identificano i bit del campo \param{events} di + \struct{epoll\_event}.} \label{tab:epoll_events} \end{table} \footnotetext{questa modalità è disponibile solo a partire dal kernel 2.6.2.} -Le modalità di utilizzo di \textit{epoll} prevedano che si definisca un -insieme di file descriptor da tenere sotto controllo su un \textit{epoll - descriptor} \param{epfd} con una serie di chiamate a -\const{EPOLL\_CTL\_ADD}. Il default prevede la notifica in modalità -\textit{level triggered}, a meno che sul file descriptor non si sia impostata -la modalità \textit{edge triggered} con \const{EPOLLET}. Si tenga presente -che è possibile tenere sotto osservazione uno stesso file descriptor su due -\textit{epoll descriptor} diversi, ed entrambi riceveranno le notifiche, ma la -pratica è sconsigliata. - -Una particolare modalità di notifica è quella impostata con -\const{EPOLLONESHOT}: quando si è in modalità \textit{edge triggered} l'arrivo -in rapida successione di dati in blocchi separati causa la generazione di una -serie di eventi multipli; in questo caso si può utilizzare la modalità -\textit{one-shot} in cui la notifica viene effettuata solo la prima volta, -dopo di che il file descriptor osservato, pur restando nella lista di -\param{epfd}, viene disattivato, e per essere riutilizzato dovrà essere -riabilitato con una successiva chiamata con \const{EPOLL\_CTL\_MOD}. - - -Infine qualora un file descriptor posto sotto osservazione dovesse essere -chiuso, esso sarà automaticamente eliminato dall'insieme dei file descriptor -osservati. - - - - -La funzione che consente di attendere è \funcd{epoll\_wait}, il cui prototipo -è: +Le modalità di utilizzo di \textit{epoll} prevedano che si definisca qual'è +l'insieme dei file descriptor da tenere sotto controllo tramite un certo +\textit{epoll descriptor} \param{epfd} attraverso una serie di chiamate a +\const{EPOLL\_CTL\_ADD}.\footnote{un difetto dell'interfaccia è che queste + chiamate devono essere ripetute per ciascun file descriptor, incorrendo in + una perdita di prestazioni qualora il numero di file descriptor sia molto + grande; per questo è stato proposto di introdurre come estensione una + funzione \func{epoll\_ctlv} che consenta di effettuare con una sola chiamata + le impostazioni per un blocco di file descriptor.} L'uso di +\const{EPOLL\_CTL\_MOD} consente in seguito di modificare le modalità di +osservazione di un file descriptor che sia già stato aggiunto alla lista di +osservazione. + +Le impostazioni di default prevedono che la notifica degli eventi richiesti +sia effettuata in modalità \textit{level triggered}, a meno che sul file +descriptor non si sia impostata la modalità \textit{edge triggered}, +registrandolo con \const{EPOLLET} attivo nel campo \var{events}. Si tenga +presente che è possibile tenere sotto osservazione uno stesso file descriptor +su due \textit{epoll descriptor} diversi, ed entrambi riceveranno le +notifiche, anche se questa pratica è sconsigliata. + +Qualora non si abbia più interesse nell'osservazione di un file descriptor lo +si può rimuovere dalla lista associata a \param{epfd} con +\const{EPOLL\_CTL\_DEL}; si tenga conto inoltre che i file descriptor sotto +osservazione che vengono chiusi sono eliminati dalla lista automaticamente e +non è necessario usare \const{EPOLL\_CTL\_DEL}. + +Infine una particolare modalità di notifica è quella impostata con +\const{EPOLLONESHOT}: a causa dell'implementazione di \textit{epoll} infatti +quando si è in modalità \textit{edge triggered} l'arrivo in rapida successione +di dati in blocchi separati\footnote{questo è tipico con i socket di rete, in + quanto i dati arrivano a pacchetti.} può causare una generazione di eventi +(ad esempio segnalazioni di dati in lettura disponibili) anche se la +condizione è già stata rilevata.\footnote{si avrebbe cioè una rottura della + logica \textit{edge triggered}.} + +Anche se la situazione è facile da gestire, la si può evitare utilizzando +\const{EPOLLONESHOT} per impostare la modalità \textit{one-shot}, in cui la +notifica di un evento viene effettuata una sola volta, dopo di che il file +descriptor osservato, pur restando nella lista di osservazione, viene +automaticamente disattivato,\footnote{la cosa avviene contestualmente al + ritorno di \func{epoll\_wait} a causa dell'evento in questione.} e per +essere riutilizzato dovrà essere riabilitato esplicitamente con una successiva +chiamata con \const{EPOLL\_CTL\_MOD}. + +Una volta impostato l'insieme di file descriptor che si vogliono osservare con +i relativi eventi, la funzione che consente di attendere l'occorrenza di uno +di tali eventi è \funcd{epoll\_wait}, il cui prototipo è: \begin{prototype}{sys/epoll.h} {int epoll\_wait(int epfd, struct epoll\_event * events, int maxevents, int timeout)} @@ -808,16 +831,68 @@ La funzione che consente di attendere \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima della scadenza di \param{timeout}. \item[\errcode{EINVAL}] il file descriptor \param{epfd} non è stato ottenuto - con \func{epoll\_create}, o \param{fd} è lo stesso \param{epfd} o - l'operazione richiesta con \param{op} non è supportata. + con \func{epoll\_create}, o \param{maxevents} non è maggiore di zero. \end{errlist} } \end{prototype} +La funzione si blocca in attesa di un evento per i file descriptor registrati +nella lista di osservazione di \param{epfd} fino ad un tempo massimo +specificato in millisecondi tramite l'argomento \param{timeout}. Gli eventi +registrati vengono riportati in un vettore di strutture \struct{epoll\_event} +(che deve essere stato allocato in precedenza) all'indirizzo indicato +dall'argomento \param{events}, fino ad un numero massimo di eventi impostato +con l'argomento \param{maxevents}. + +La funzione ritorna il numero di eventi rilevati, o un valore nullo qualora +sia scaduto il tempo massimo impostato con \param{timeout}. Per quest'ultimo, +oltre ad un numero di millisecondi, si può utilizzare il valore nullo, che +indica di non attendere e ritornare immediatamente,\footnote{anche in questo + caso il valore di ritorno sarà nullo.} o il valore $-1$, che indica +un'attesa indefinita. L'argomento \param{maxevents} dovrà invece essere sempre +un intero positivo. + +Come accennato la funzione restituisce i suoi risultati nel vettore di +strutture \struct{epoll\_event} puntato da \param{events}; in tal caso nel +campo \param{events} di ciascuna di esse saranno attivi i flag relativi agli +eventi accaduti, mentre nel campo \var{data} sarà restituito il valore che era +stato impostato per il file descriptor per cui si è verificato l'evento quando +questo era stato registrato con le operazioni \const{EPOLL\_CTL\_MOD} o +\const{EPOLL\_CTL\_ADD}, in questo modo il campo \var{data} consente di +identificare il file descriptor.\footnote{ed è per questo che, come accennato, + è consuetudine usare per \var{data} il valore del file descriptor stesso.} + +Si ricordi che le occasioni per cui \func{epoll\_wait} ritorna dipendono da +come si è impostata la modalità di osservazione (se \textit{level triggered} o +\textit{edge triggered}) del singolo file descriptor. L'interfaccia assicura +che se arrivano più eventi fra due chiamate successive ad \func{epoll\_wait} +questi vengano combinati. Inoltre qualora su un file descriptor fossero +presenti eventi non ancora notificati, e si effettuasse una modifica +dell'osservazione con \const{EPOLL\_CTL\_MOD} questi verrebbero riletti alla +luce delle modifiche. + +Si tenga presente infine che con l'uso della modalità \textit{edge triggered} +il ritorno di \func{epoll\_wait} indica un file descriptor è pronto e resterà +tale fintanto che non si sono completamente esaurite le operazioni su di esso. +Questa condizione viene generalmente rilevata dall'occorrere di un errore di +\errcode{EAGAIN} al ritorno di una \func{read} o una \func{write},\footnote{è + opportuno ricordare ancora una volta che l'uso dell'I/O multiplexing + richiede di operare sui file in modalità non bloccante.} ma questa non è la +sola modalità possibile, ad esempio la condizione può essere riconosciuta +anche con il fatto che sono stati restituiti meno dati di quelli richiesti. + +Come le precedenti \func{select} e \func{poll}, le funzioni dell'interfaccia +di \textit{epoll} vengono utilizzate prevalentemente con i server di rete, +quando si devono tenere sotto osservazione un gran numero di socket; per +questo motivo rimandiamo di nuovo la trattazione di un esempio concreto a +quando avremo esaminato in dettaglio le caratteristiche dei socket, in +particolare si potrà trovare un programma che utilizza questa interfaccia in +sez.~\ref{sec:TCP_sock_multiplexing}. + \itindend{epoll} -% TODO epoll -% + + \section{L'accesso \textsl{asincrono} ai file} \label{sec:file_asyncronous_access} @@ -830,44 +905,52 @@ contesto le modalit \textsl{asincrona}, quelle cioè in cui un processo non deve bloccarsi in attesa della disponibilità dell'accesso al file, ma può proseguire nell'esecuzione utilizzando invece un meccanismo di notifica asincrono (di -norma un segnale), per essere avvisato della possibilità di eseguire le +norma un segnale, ma esistono anche altre interfacce, come \itindex{inotify} +\textit{inotify}), per essere avvisato della possibilità di eseguire le operazioni di I/O volute. -\subsection{Operazioni asincrone sui file} +\subsection{Il \textit{Signal driven I/O}} \label{sec:file_asyncronous_operation} -Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso l'uso -del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e dei - comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è specifico - di Linux e BSD.} aprire un file in modalità asincrona, così come è possibile -attivare in un secondo tempo questa modalità impostando questo flag attraverso -l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi -sez.~\ref{sec:file_fcntl}). - -In realtà in questo caso non si tratta di eseguire delle operazioni di lettura -o scrittura del file in modo asincrono (tratteremo questo, che più -propriamente è detto \textsl{I/O asincrono} in -sez.~\ref{sec:file_asyncronous_io}), quanto di un meccanismo asincrono di -notifica delle variazione dello stato del file descriptor aperto in questo -modo. - -Quello che succede in questo caso è che il sistema genera un segnale -(normalmente \const{SIGIO}, ma è possibile usarne altri con il comando -\const{F\_SETSIG} di \func{fcntl}) tutte le volte che diventa possibile -leggere o scrivere dal file descriptor che si è posto in questa modalità. Si -può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl}, +Abbiamo accennato in sez.~\ref{sec:file_open} che è possibile, attraverso +l'uso del flag \const{O\_ASYNC},\footnote{l'uso del flag di \const{O\_ASYNC} e + dei comandi \const{F\_SETOWN} e \const{F\_GETOWN} per \func{fcntl} è + specifico di Linux e BSD.} aprire un file in modalità asincrona, così come è +possibile attivare in un secondo tempo questa modalità impostando questo flag +attraverso l'uso di \func{fcntl} con il comando \const{F\_SETFL} (vedi +sez.~\ref{sec:file_fcntl}). + +In realtà parlare di apertura in modalità asincrona non significa che le +operazioni di lettura o scrittura del file vengono eseguite in modo asincrono +(tratteremo questo, che è ciò che più propriamente viene chiamato \textsl{I/O + asincrono}, in sez.~\ref{sec:file_asyncronous_io}), quanto dell'attivazione +un meccanismo di notifica asincrona delle variazione dello stato del file +descriptor aperto in questo modo. Quello che succede in questo caso è che il +sistema genera un segnale (normalmente \const{SIGIO}, ma è possibile usarne +altri con il comando \const{F\_SETSIG} di \func{fcntl}) tutte le volte che +diventa possibile leggere o scrivere dal file descriptor che si è posto in +questa modalità.\footnote{questa modalità non è utilizzabile con i file + ordinari ma solo con socket, file di terminale o pseudo terminale, e, a + partire dal kernel 2.6, anche per fifo e pipe.} + +Si può inoltre selezionare, con il comando \const{F\_SETOWN} di \func{fcntl}, quale processo (o gruppo di processi) riceverà il segnale. Se pertanto si effettuano le operazioni di I/O in risposta alla ricezione del segnale non ci sarà più la necessità di restare bloccati in attesa della disponibilità di -accesso ai file; per questo motivo Stevens chiama questa modalità -\textit{signal driven I/O}. - -Questa è un'altra modalità di gestione I/O, alternativa all'uso di -\itindex{epoll} \textit{epoll}, che consente di evitare l'uso delle funzioni -\func{poll} o \func{select} che, come illustrato in sez.~\ref{sec:file_epoll}, -quando vengono usate con un numero molto grande di file descriptor, non hanno -buone prestazioni. +accesso ai file. + +Per questo motivo Stevens, ed anche le pagine di manuale di +Linux, chiamano questa modalità ``\textit{Signal driven I/O}''. Questa è +ancora un'altra modalità di gestione dell'I/O, alternativa all'uso di +\itindex{epoll} \textit{epoll},\footnote{anche se le prestazioni ottenute con + questa tecnica sono inferiori, il vantaggio è che questa modalità è + utilizzabile anche con kernel che non supportano \textit{epoll}, come quelli + della serie 2.4, ottenendo comunque prestazioni superiori a quelle che si + hanno con \func{poll} e \func{select}.} che consente di evitare l'uso delle +funzioni \func{poll} o \func{select} che, come illustrato in +sez.~\ref{sec:file_epoll}, quando vengono usate con un numero molto grande di +file descriptor, non hanno buone prestazioni. Tuttavia con l'implementazione classica dei segnali questa modalità di I/O presenta notevoli problemi, dato che non è possibile determinare, quando i @@ -905,11 +988,16 @@ un file su cui l'accesso funzioni come \func{poll} e \func{select}, almeno fintanto che non si satura la coda. -Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo -più assicurare il comportamento corretto per un segnale real-time, invierà al -suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali -in eccesso, e si dovrà allora determinare con un ciclo quali sono i file -diventati attivi. +Se infatti si eccedono le dimensioni di quest'ultima, il kernel, non potendo +più assicurare il comportamento corretto per un segnale real-time, invierà al +suo posto un solo \const{SIGIO}, su cui si saranno accumulati tutti i segnali +in eccesso, e si dovrà allora determinare con un ciclo quali sono i file +diventati attivi. L'unico modo per essere sicuri che questo non avvenga è di +impostare la lunghezza della coda dei segnali real-time ad una dimensione +identica al valore massimo del numero di file descriptor +utilizzabili.\footnote{vale a dire impostare il contenuto di + \procfile{/proc/sys/kernel/rtsig-max} allo stesso valore del contenuto di + \procfile{/proc/sys/fs/file-max}.} % TODO fare esempio che usa O_ASYNC @@ -923,27 +1011,29 @@ risposta\footnote{o meglio la non risposta, tanto che questa nelle Unix FAQ \cite{UnixFAQ} viene anche chiamata una \textit{Frequently Unanswered Question}.} è che nell'architettura classica di Unix questo non è possibile. Al contrario di altri sistemi operativi infatti un kernel unix-like -non prevede alcun meccanismo per cui un processo possa essere +classico non prevedeva alcun meccanismo per cui un processo possa essere \textsl{notificato} di eventuali modifiche avvenute su un file. Questo è il motivo per cui i demoni devono essere \textsl{avvisati} in qualche modo\footnote{in genere questo vien fatto inviandogli un segnale di - \const{SIGHUP} che, per convenzione adottata dalla gran parte di detti + \const{SIGHUP} che, per una convenzione adottata dalla gran parte di detti programmi, causa la rilettura della configurazione.} se il loro file di configurazione è stato modificato, perché possano rileggerlo e riconoscere le modifiche. Questa scelta è stata fatta perché provvedere un simile meccanismo a livello -generale comporterebbe un notevole aumento di complessità dell'architettura -della gestione dei file, per fornire una funzionalità necessaria soltanto in -casi particolari. Dato che all'origine di Unix i soli programmi che potevano -avere una tale esigenza erano i demoni, attenendosi a uno dei criteri base -della progettazione, che era di far fare al kernel solo le operazioni -strettamente necessarie e lasciare tutto il resto a processi in user space, -non era stata prevista nessuna funzionalità di notifica. +generico per qualunque file comporterebbe un notevole aumento di complessità +dell'architettura della gestione dei file, il tutto per fornire una +funzionalità che serve soltanto in alcuni casi particolari. Dato che +all'origine di Unix i soli programmi che potevano avere una tale esigenza +erano i demoni, attenendosi a uno dei criteri base della progettazione, che +era di far fare al kernel solo le operazioni strettamente necessarie e +lasciare tutto il resto a processi in user space, non era stata prevista +nessuna funzionalità di notifica. Visto però il crescente interesse nei confronti di una funzionalità di questo -tipo (molto richiesta specialmente nello sviluppo dei programmi ad interfaccia -grafica) sono state successivamente introdotte delle estensioni che +tipo, che è molto richiesta specialmente nello sviluppo dei programmi ad +interfaccia grafica, quando si deve presentare all'utente lo stato del +filesystem, sono state successivamente introdotte delle estensioni che permettessero la creazione di meccanismi di notifica più efficienti dell'unica soluzione disponibile con l'interfaccia tradizionale, che è quella del \itindex{polling} \textit{polling}. @@ -1055,7 +1145,7 @@ operazione di lettura, declassando il \textit{lease} a lettura con Se il \textit{lease holder} non provvede a rilasciare il \textit{lease} entro il numero di secondi specificato dal parametro di sistema mantenuto in -\file{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o +\procfile{/proc/sys/fs/lease-break-time} sarà il kernel stesso a rimuoverlo (o declassarlo) automaticamente.\footnote{questa è una misura di sicurezza per evitare che un processo blocchi indefinitamente l'accesso ad un file acquisendo un \textit{lease}.} Una volta che un \textit{lease} è stato @@ -1072,13 +1162,19 @@ risolvere il problema di rilevare automaticamente quando un file o una directory vengono modificati, che è quanto necessario ad esempio ai programma di gestione dei file dei vari desktop grafici. -Per risolvere questo problema è stata allora creata un'altra interfaccia, -chiamata \textit{dnotify}, che consente di richiedere una notifica quando una -directory, o di uno qualunque dei file in essa contenuti, viene modificato. -Come per i \textit{file lease} la notifica avviene di default attraverso il -segnale \const{SIGIO}, ma se ne può utilizzare un altro. Inoltre si potrà -ottenere nel gestore del segnale il file descriptor che è stato modificato -tramite il contenuto della struttura \struct{siginfo\_t}. +Per risolvere questo problema a partire dal kernel 2.4 è stata allora creata +un'altra interfaccia,\footnote{si ricordi che anche questa è una interfaccia + specifica di Linux che deve essere evitata se si vogliono scrivere programmi + portabili, e che le funzionalità illustrate sono disponibili soltanto se è + stata definita la macro \macro{\_GNU\_SOURCE}.} chiamata \textit{dnotify}, +che consente di richiedere una notifica quando una directory, o uno qualunque +dei file in essa contenuti, viene modificato. Come per i \textit{file lease} +la notifica avviene di default attraverso il segnale \const{SIGIO}, ma se ne +può utilizzare un altro.\footnote{e di nuovo, per le ragioni già esposte in + precedenza, è opportuno che si utilizzino dei segnali real-time.} Inoltre, +come in precedenza, si potrà ottenere nel gestore del segnale il file +descriptor che è stato modificato tramite il contenuto della struttura +\struct{siginfo\_t}. \index{file!lease|)} @@ -1108,7 +1204,7 @@ tramite il contenuto della struttura \struct{siginfo\_t}. \const{DN\_ATTRIB} & È stato modificato un attributo di un file con l'esecuzione di una fra \func{chown}, \func{chmod}, \func{utime}.\\ - \const{DN\_MULTISHOT}& richiede una notifica permanente di tutti gli + \const{DN\_MULTISHOT}& Richiede una notifica permanente di tutti gli eventi.\\ \hline \end{tabular} @@ -1140,30 +1236,34 @@ specificare un valore nullo. Il maggiore problema di \textit{dnotify} è quello della scalabilità: si deve usare un file descriptor per ciascuna directory che si vuole tenere sotto -controllo, il che porta facilmente ad un eccesso di file aperti. Inoltre -quando la directory è su un dispositivo rimovibile, mantenere un file -descriptor aperto comporta l'impossibilità di smontare il dispositivo e -rimuoverlo, complicando la gestione. - -Un secondo problema è che l'interfaccia consente solo di tenere sotto -controllo il contenuto di una directory; la modifica di un file viene -segnalata, ma poi devo verificare quale è. Infine l'uso dei segnali come -interfaccia di notifica comporta tutti i problemi di gestione visti in -sez.~\ref{sec:sig_management} e sez.~\ref{sec:sig_control}, e per questo in -generale quella di \textit{dnotify} viene considerata una interfaccia di -usabilità problematica. +controllo, il che porta facilmente ad avere un eccesso di file aperti. Inoltre +quando la directory che si controlla è all'interno di un dispositivo +rimovibile, mantenere il relativo file descriptor aperto comporta +l'impossibilità di smontare il dispositivo e di rimuoverlo, il che in genere +complica notevolmente la gestione dell'uso di questi dispositivi. + +Un altro problema è che l'interfaccia di \textit{dnotify} consente solo di +tenere sotto controllo il contenuto di una directory; la modifica di un file +viene segnalata, ma poi è necessario verificare di quale file si tratta +(operazione che può essere molto onerosa quando una directory contiene un gran +numero di file). Infine l'uso dei segnali come interfaccia di notifica +comporta tutti i problemi di gestione visti in sez.~\ref{sec:sig_management} e +sez.~\ref{sec:sig_control}. Per tutta questa serie di motivi in generale +quella di \textit{dnotify} viene considerata una interfaccia di usabilità +problematica. \index{file!dnotify|)} -Per questa serie di motivi, a partire dal kernel 2.6.13, è stata introdotta -una nuova interfaccia per l'osservazione delle modifiche a file o directory, -chiamata \textit{inotify}.\footnote{le corrispondenti funzioni di interfaccia - sono state introdotte nelle glibc 2.4.} Questa è una interfaccia specifica -di Linux (pertanto non deve essere usata se si devono scrivere programmi -portabili), ed è basata sull'uso di una coda di notifica degli eventi -associata ad un singolo file descriptor, risolvendo così il principale -problema di \itindex{dnotify} \textit{dnotify}. La coda viene creata -attraverso la funzione \funcd{inotify\_init}, il cui prototipo è: +Per risolvere i problemi appena illustrati è stata introdotta una nuova +interfaccia per l'osservazione delle modifiche a file o directory, chiamata +\textit{inotify}.\footnote{l'interfaccia è disponibile a partire dal kernel + 2.6.13, le relative funzioni sono state introdotte nelle glibc 2.4.} Anche +questa è una interfaccia specifica di Linux (pertanto non deve essere usata se +si devono scrivere programmi portabili), ed è basata sull'uso di una coda di +notifica degli eventi associata ad un singolo file descriptor, il che permette +di risolvere il principale problema di \itindex{dnotify} \textit{dnotify}. La +coda viene creata attraverso la funzione \funcd{inotify\_init}, il cui +prototipo è: \begin{prototype}{sys/inotify.h} {int inotify\_init(void)} @@ -1182,35 +1282,39 @@ attraverso la funzione \funcd{inotify\_init}, il cui prototipo } \end{prototype} -La funzione non prende alcun argomento, e restituisce un file descriptor -associato alla coda, attraverso il quale verranno effettuate le operazioni di -notifica. Si tratta di un file descriptor speciale, che non è associato a -nessun file, ma che viene utilizzato per notificare gli eventi che si sono -posti in osservazione all'applicazione che usa l'interfaccia di -\textit{inotify}. Dato che questo file descriptor non è associato a nessun -file o directory, questo consente di evitare l'inconveniente di non poter -smontare un filesystem i cui file sono tenuti sotto osservazione.\footnote{ed - una delle caratteristiche dell'interfaccia di \textit{inotify} è proprio - quella di notificare il fatto che il filesystem su cui si trova il file o la - directory osservata è stato smontato.} +La funzione non prende alcun argomento; inizializza una istanza di +\textit{inotify} e restituisce un file descriptor attraverso il quale verranno +effettuate le operazioni di notifica;\footnote{per evitare abusi delle risorse + di sistema è previsto che un utente possa utilizzare un numero limitato di + istanze di \textit{inotify}; il valore di default del limite è di 128, ma + questo valore può essere cambiato con \func{sysctl} o usando il file + \procfile{/proc/sys/fs/inotify/max\_user\_instances}.} si tratta di un file +descriptor speciale che non è associato a nessun file su disco, e che viene +utilizzato solo per notificare gli eventi che sono stati posti in +osservazione. Dato che questo file descriptor non è associato a nessun file o +directory reale, l'inconveniente di non poter smontare un filesystem i cui +file sono tenuti sotto osservazione viene completamente +eliminato.\footnote{anzi, una delle capacità dell'interfaccia di + \textit{inotify} è proprio quella di notificare il fatto che il filesystem + su cui si trova il file o la directory osservata è stato smontato.} Inoltre trattandosi di un file descriptor a tutti gli effetti, esso potrà -essere utilizzato come argomento per le funzioni \func{select} e \func{poll}, -e siccome gli eventi vengono notificati come dati disponibili in lettura sul -file descriptor, dette funzioni ritorneranno tutte le volte che si avrà un -evento di notifica. Così, invece di dover utilizzare i segnali, si potrà -gestire l'osservazione delle modifiche con l'\textit{I/O multiplexing}, -utilizzando secondo le modalità illustrate in -sez.~\ref{sec:file_multiplexing}. +essere utilizzato come argomento per le funzioni \func{select} e \func{poll} e +con l'interfaccia di \textit{epoll}; siccome gli eventi vengono notificati +come dati disponibili in lettura sul file descriptor, dette funzioni +ritorneranno tutte le volte che si avrà un evento di notifica. Così, invece di +dover utilizzare i segnali,\footnote{considerati una pessima scelta dal punto + di vista dell'interfaccia utente.} si potrà gestire l'osservazione delle +modifiche con una qualunque delle modalità di \textit{I/O multiplexing} +illustrate in sez.~\ref{sec:file_multiplexing}. Infine l'interfaccia di \textit{inotify} consente di mettere sotto -osservazione sia singoli file, che intere directory; in quest'ultimo caso -l'interfaccia restituirà informazioni sia riguardo alla directory che ai file -che essa contiene. Una volta creata la coda di notifica si devono definire -gli eventi da tenere sotto osservazione; questo viene fatto tramite una -\textsl{lista di osservazione} (o \textit{watch list}) associata alla coda. -Per gestire la lista di osservazione l'interfaccia fornisce due funzioni, la -prima di queste è \funcd{inotify\_add\_watch}, il cui prototipo è: +osservazione, oltre che una directory, anche singoli file. Una volta creata +la coda di notifica si devono definire gli eventi da tenere sotto +osservazione; questo viene fatto attraverso una \textsl{lista di osservazione} +(o \textit{watch list}) che è associata alla coda. Per gestire la lista di +osservazione l'interfaccia fornisce due funzioni, la prima di queste è +\funcd{inotify\_add\_watch}, il cui prototipo è: \begin{prototype}{sys/inotify.h} {int inotify\_add\_watch(int fd, const char *pathname, uint32\_t mask)} @@ -1221,75 +1325,161 @@ prima di queste \begin{errlist} \item[\errcode{EACCESS}] non si ha accesso in lettura al file indicato. \item[\errcode{EINVAL}] \param{mask} non contiene eventi legali o \param{fd} - non è un filesystem di \textit{inotify}. + non è un file descriptor di \textit{inotify}. \item[\errcode{ENOSPC}] si è raggiunto il numero massimo di voci di osservazione o il kernel non ha potuto allocare una risorsa necessaria. \end{errlist} ed inoltre \errval{EFAULT}, \errval{ENOMEM} e \errval{EBADF}.} \end{prototype} -La funzione consente di creare un \textsl{evento di osservazione} (un -cosiddetto ``\textit{watch}'') nella lista di una coda di notifica, indicata -specificando il file descriptor ad essa associato nell'argomento \param{fd}. -Il file o la directory da porre sotto osservazione viene invece indicato per -nome, che viene passato nell'argomento \param{pathname}. Infine il terzo -argomento, \param{mask}, indica che tipo di eventi devono essere tenuti sotto -osservazione. Questo deve essere specificato come maschera binaria combinando -i valori delle costanti riportate in tab.~\ref{tab:inotify_event_watch}. In -essa si sono marcati con un ``$\bullet$'' gli eventi che, quando specificati -per una directory, vengono osservati anche su tutti i file che essa contiene. +La funzione consente di creare un ``\textsl{osservatore}'' (il cosiddetto +``\textit{watch}'') nella lista di osservazione di una coda di notifica, che +deve essere indicata specificando il file descriptor ad essa associato +nell'argomento \param{fd}.\footnote{questo ovviamente dovrà essere un file + descriptor creato con \func{inotify\_init}.} Il file o la directory da +porre sotto osservazione vengono invece indicati per nome, da passare +nell'argomento \param{pathname}. Infine il terzo argomento, \param{mask}, +indica che tipo di eventi devono essere tenuti sotto osservazione e le +modalità della stessa. L'operazione può essere ripetuta per tutti i file e le +directory che si vogliono tenere sotto osservazione,\footnote{anche in questo + caso c'è un limite massimo che di default è pari a 8192, ed anche questo + valore può essere cambiato con \func{sysctl} o usando il file + \procfile{/proc/sys/fs/inotify/max\_user\_watches}.} e si utilizzerà sempre +un solo file descriptor. + +Il tipo di evento che si vuole osservare deve essere specificato +nell'argomento \param{mask} come maschera binaria, combinando i valori delle +costanti riportate in tab.~\ref{tab:inotify_event_watch} che identificano i +singoli bit della maschera ed il relativo significato. In essa si sono marcati +con un ``$\bullet$'' gli eventi che, quando specificati per una directory, +vengono osservati anche su tutti i file che essa contiene. Nella seconda +parte della tabella si sono poi indicate alcune combinazioni predefinite dei +flag della prima parte. \begin{table}[htb] \centering \footnotesize \begin{tabular}[c]{|l|c|p{10cm}|} \hline - \textbf{Valore} & & \textbf{Significato} \\ + \textbf{Flag} & & \textbf{Significato} \\ \hline \hline - \const{IN\_ACCESS} &$\bullet$& c'è stato accesso al file in + \const{IN\_ACCESS} &$\bullet$& C'è stato accesso al file in lettura.\\ - \const{IN\_ATTRIB} &$\bullet$& ci sono stati cambiamenti sui dati - dell'inode.\\ - \const{IN\_CLOSE\_WRITE} &$\bullet$& è stato chiuso un file aperto in + \const{IN\_ATTRIB} &$\bullet$& Ci sono stati cambiamenti sui dati + dell'inode (o sugli attributi + estesi, vedi + sez.~\ref{sec:file_xattr}).\\ + \const{IN\_CLOSE\_WRITE} &$\bullet$& È stato chiuso un file aperto in scrittura.\\ - \const{IN\_CLOSE\_NOWRITE}&$\bullet$& è stato chiuso un file aperto in - sola lettura.\\ - \const{IN\_CREATE} &$\bullet$& è stato creato un file o una + \const{IN\_CLOSE\_NOWRITE}&$\bullet$& È stato chiuso un file aperto in + sola lettura.\\ + \const{IN\_CREATE} &$\bullet$& È stato creato un file o una directory in una directory sotto osservazione.\\ - \const{IN\_DELETE} &$\bullet$& è stato cancellato un file o una + \const{IN\_DELETE} &$\bullet$& È stato cancellato un file o una directory in una directory sotto osservazione.\\ - \const{IN\_DELETE\_SELF} & & è stato cancellato il file (o la + \const{IN\_DELETE\_SELF} & & È stato cancellato il file (o la directory) sotto osservazione.\\ - \const{IN\_MODIFY} &$\bullet$& è stato modificato il file.\\ - \const{IN\_MOVE\_SELF} & & è stato rinominato il file (o la + \const{IN\_MODIFY} &$\bullet$& È stato modificato il file.\\ + \const{IN\_MOVE\_SELF} & & È stato rinominato il file (o la directory) sotto osservazione.\\ - \const{IN\_MOVED\_FROM} &$\bullet$& un file è stato spostato fuori dalla + \const{IN\_MOVED\_FROM} &$\bullet$& Un file è stato spostato fuori dalla directory sotto osservazione.\\ - \const{IN\_MOVED\_TO} &$\bullet$& un file è stato spostato nella + \const{IN\_MOVED\_TO} &$\bullet$& Un file è stato spostato nella directory sotto osservazione.\\ - \const{IN\_OPEN} &$\bullet$& un file è stato aperto.\\ + \const{IN\_OPEN} &$\bullet$& Un file è stato aperto.\\ + \hline + \const{IN\_CLOSE} & -- & Combinazione di + \const{IN\_CLOSE\_WRITE} e + \const{IN\_CLOSE\_NOWRITE}.\\ + \const{IN\_MOVE} & -- & Combinazione di + \const{IN\_MOVED\_FROM} e + \const{IN\_MOVED\_TO}.\\ + \const{IN\_ALL\_EVENTS} & -- & Combinazione di tutti i flag + possibili.\\ \hline \end{tabular} \caption{Le costanti che identificano i valori per la maschera binaria - dell'argomento \param{mask} di \func{inotify\_add\_watch}.} + dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano il + tipo di evento da tenere sotto osservazione.} \label{tab:inotify_event_watch} \end{table} -Se non esiste nessun \textit{watch} per il file (o la directory) specificata +Oltre ai flag di tab.~\ref{tab:inotify_event_watch}, che indicano il tipo di +evento da osservare e che vengono utilizzati anche in uscita per indicare il +tipo di evento avvenuto, \func{inotify\_add\_watch} supporta ulteriori +flag,\footnote{i flag \const{IN\_DONT\_FOLLOW}, \const{IN\_MASK\_ADD} e + \const{IN\_ONLYDIR} sono stati introdotti a partire dalle glibc 2.5, se si + usa la versione 2.4 è necessario definirli a mano.} riportati in +tab.~\ref{tab:inotify_add_watch_flag}, che indicano le modalità di +osservazione (da passare sempre nell'argomento \param{mask}) e che al +contrario dei precedenti non vengono mai impostati nei risultati in uscita. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{10cm}|} + \hline + \textbf{Flag} & \textbf{Significato} \\ + \hline + \hline + \const{IN\_DONT\_FOLLOW}& Non dereferenzia \param{pathname} se questo è un + link simbolico.\\ + \const{IN\_MASK\_ADD} & Aggiunge a quelli già impostati i flag indicati + nell'argomento \param{mask}, invece di + sovrascriverli.\\ + \const{IN\_ONESHOT} & Esegue l'osservazione su \param{pathname} per una + sola volta, rimuovendolo poi dalla \textit{watch + list}.\\ + \const{IN\_ONLYDIR} & Se \param{pathname} è una directory riporta + soltanto gli eventi ad essa relativi e non + quelli per i file che contiene.\\ + \hline + \end{tabular} + \caption{Le costanti che identificano i valori per la maschera binaria + dell'argomento \param{mask} di \func{inotify\_add\_watch} che indicano le + modalità di osservazione.} + \label{tab:inotify_add_watch_flag} +\end{table} + +Se non esiste nessun \textit{watch} per il file o la directory specificata questo verrà creato per gli eventi specificati dall'argomento \param{mask}, -altrimenti la funzione sovrascriverà le impostazioni precedenti. In caso di -successo la funzione ritorna un intero positivo, detto \textit{watch - descriptor} che identifica univocamente l'evento di osservazione. Questo -valore è importante perché è soltanto con esso che si può rimuovere un evento -di osservazione, usando la seconda funzione dell'interfaccia di gestione, -\funcd{inotify\_rm\_watch}, il cui prototipo è: +altrimenti la funzione sovrascriverà le impostazioni precedenti, a meno che +non si sia usato il flag \const{IN\_MASK\_ADD}, nel qual caso gli eventi +specificati saranno aggiunti a quelli già presenti. + +Come accennato quando si tiene sotto osservazione una directory vengono +restituite le informazioni sia riguardo alla directory stessa che ai file che +essa contiene; questo comportamento può essere disabilitato utilizzando il +flag \const{IN\_ONLYDIR}, che richiede di riportare soltanto gli eventi +relativi alla directory stessa. Si tenga presente inoltre che quando si +osserva una directory vengono riportati solo gli eventi sui file che essa +contiene direttamente, non quelli relativi a file contenuti in eventuali +sottodirectory; se si vogliono osservare anche questi sarà necessario creare +ulteriori \textit{watch} per ciascuna sottodirectory. + +Infine usando il flag \const{IN\_ONESHOT} è possibile richiedere una notifica +singola;\footnote{questa funzionalità però è disponibile soltato a partire dal + kernel 2.6.16.} una volta verificatosi uno qualunque fra gli eventi +richiesti con \func{inotify\_add\_watch} l'\textsl{osservatore} verrà +automaticamente rimosso dalla lista di osservazione e nessun ulteriore evento +sarà più notificato. + +In caso di successo \func{inotify\_add\_watch} ritorna un intero positivo, +detto \textit{watch descriptor}, che identifica univocamente un +\textsl{osservatore} su una coda di notifica; esso viene usato per farvi +riferimento sia riguardo i risultati restituiti da \textit{inotify}, che per +la eventuale rimozione dello stesso. + +La seconda funzione per la gestione delle code di notifica, che permette di +rimuovere un \textsl{osservatore}, è \funcd{inotify\_rm\_watch}, ed il suo +prototipo è: \begin{prototype}{sys/inotify.h} {int inotify\_rm\_watch(int fd, uint32\_t wd)} - Rimuove un evento di osservazione. + Rimuove un \textsl{osservatore} da una coda di notifica. \bodydesc{La funzione restituisce 0 in caso di successo, o $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: @@ -1302,10 +1492,27 @@ di osservazione, usando la seconda funzione dell'interfaccia di gestione, } \end{prototype} -Oltre che per la rimozione, il \textit{watch descriptor} viene usato anche per -identificare l'evento a cui si fa riferimento nella lista dei risultati -restituiti da \textit{inotify} - +La funzione rimuove dalla coda di notifica identificata dall'argomento +\param{fd} l'osservatore identificato dal \textit{watch descriptor} +\param{wd};\footnote{ovviamente deve essere usato per questo argomento un + valore ritornato da \func{inotify\_add\_watch}, altrimenti si avrà un errore + di \errval{EINVAL}.} in caso di successo della rimozione, contemporaneamente +alla cancellazione dell'osservatore, sulla coda di notifica verrà generato un +evento di tipo \const{IN\_IGNORED} (vedi +tab.~\ref{tab:inotify_read_event_flag}). Si tenga presente che se un file +viene cancellato o un filesystem viene smontato i relativi osservatori vengono +rimossi automaticamente e non è necessario utilizzare +\func{inotify\_rm\_watch}. + + +Come accennato l'interfaccia di \textit{inotify} prevede che gli eventi siano +notificati come dati presenti in lettura sul file descriptor associato alla +coda di notifica. Una applicazione pertanto dovrà leggere i dati da detto file +con una \func{read}, che ritornerà sul buffer i dati presenti nella forma di +una o più strutture di tipo \struct{inotify\_event} (la cui definizione è +riportata in fig.~\ref{fig:inotify_event}). Qualora non siano presenti dati la +\func{read} si bloccherà (a meno di non aver impostato il file descriptor in +modalità non bloccante) fino all'arrivo di almeno un evento. \begin{figure}[!htb] \footnotesize \centering @@ -1313,20 +1520,91 @@ restituiti da \textit{inotify} \includestruct{listati/inotify_event.h} \end{minipage} \normalsize - \caption{La struttura \structd{inotify\_event}.} + \caption{La struttura \structd{inotify\_event} usata dall'interfaccia di + \textit{inotify} per riportare gli eventi.} \label{fig:inotify_event} \end{figure} +Una ulteriore caratteristica dell'interfaccia di \textit{inotify} è che essa +permette di ottenere con \func{ioctl}, come per i file descriptor associati ai +socket (si veda sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in +lettura sul file descriptor, utilizzando su di esso l'operazione +\const{FIONREAD}.\footnote{questa è una delle operazioni speciali per i file + (vedi sez.~\ref{sec:file_ioctl}), che è disponibile solo per i socket e per + i file descriptor creati con \func{inotify\_init}.} Si può così utilizzare +questa operazione, oltre che per predisporre una operazione di lettura con un +buffer di dimensioni adeguate, anche per ottenere rapidamente il numero di +file che sono cambiati. + +Una volta effettuata la lettura con \func{read} a ciascun evento sarà +associata una struttura \struct{inotify\_event} contenente i rispettivi dati. +Per identificare a quale file o directory l'evento corrisponde viene +restituito nel campo \var{wd} il \textit{watch descriptor} con cui il relativo +osservatore è stato registrato. Il campo \var{mask} contiene invece una +maschera di bit che identifica il tipo di evento verificatosi; in essa +compariranno sia i bit elencati nella prima parte di +tab.~\ref{tab:inotify_event_watch}, che gli eventuali valori +aggiuntivi\footnote{questi compaiono solo nel campo \var{maks} di + \struct{inotify\_event}, e non utilizzabili in fase di registrazione + dell'osservatore.} di tab.~\ref{tab:inotify_read_event_flag}. + +\begin{table}[htb] + \centering + \footnotesize + \begin{tabular}[c]{|l|p{10cm}|} + \hline + \textbf{Flag} & \textbf{Significato} \\ + \hline + \hline + \const{IN\_IGNORED} & L'osservatore è stato rimosso, sia in maniera + esplicita con l'uso di \func{inotify\_rm\_watch}, + che in maniera implicita per la rimozione + dell'oggetto osservato o per lo smontaggio del + filesystem su cui questo si trova.\\ + \const{IN\_ISDIR} & L'evento avvenuto fa riferimento ad una directory + (consente così di distinguere, quando si pone + sotto osservazione una directory, fra gli eventi + relativi ad essa e quelli relativi ai file che + essa contiene).\\ + \const{IN\_Q\_OVERFLOW}& Si sono eccedute le dimensioni della coda degli + eventi (\textit{overflow} della coda); in questo + caso il valore di \var{wd} è $-1$.\footnotemark\\ + \const{IN\_UNMOUNT} & Il filesystem contenente l'oggetto posto sotto + osservazione è stato smontato.\\ + \hline + \end{tabular} + \caption{Le costanti che identificano i flag aggiuntivi usati nella maschera + binaria del campo \var{mask} di \struct{inotify\_event}.} + \label{tab:inotify_read_event_flag} +\end{table} + +\footnotetext{la coda di notifica ha una dimensione massima specificata dal + parametro di sistema \procfile{/proc/sys/fs/inotify/max\_queued\_events} che + indica il numero massimo di eventi che possono essere mantenuti sulla + stessa; quando detto valore viene ecceduto gli ulteriori eventi vengono + scartati, ma viene comunque generato un evento di tipo + \const{IN\_Q\_OVERFLOW}.} + +Il campo \var{cookie} contiene invece un intero univoco che permette di +identificare eventi correlati (per i quali avrà lo stesso valore), al momento +viene utilizzato soltanto per rilevare lo spostamento di un file, consentendo +così all'applicazione di collegare la corrispondente coppia di eventi +\const{IN\_MOVED\_TO} e \const{IN\_MOVED\_FROM}. -Inoltre l'interfaccia di \textit{inotify} permette di conoscere, come avviene -per i file descriptor associati ai socket (si veda al proposito quanto -trattato in sez.~\ref{sec:sock_ioctl_IP}) il numero di byte disponibili in -lettura sul nostro file descriptor, utilizzando su di esso l'operazione -\const{FIONREAD} con \func{ioctl}.\footnote{questa è una delle operazioni - speciali (che abbiamo visto in sez.~\ref{sec:file_ioctl}) che nel caso è - disponibile solo per i socket e per i file descriptor creati con - \func{inotify\_init}.} Questo consente anche di ottenere rapidamente il -numero di file che sono cambiati. +Infine due campi \var{name} e \var{len} sono utilizzati soltanto quando +l'evento è relativo ad un file presente in una directory posta sotto +osservazione, in tal caso essi contengono rispettivamente il nome del file +(come pathname relativo alla directory osservata) e la relativa dimensione in +byte. Il campo \var{name} viene sempre restituito come stringa terminata da +NUL, con uno o più zeri di terminazione, a seconda di eventuali necessità di +allineamento del risultato, ed il valore di \var{len} corrisponde al totale +della dimensione di \var{name}, zeri aggiuntivi compresi. Questo significa che +le dimensioni di ciascun evento di \textit{inotify} saranno pari al valore +\code{sizeof(\struct{inotify\_event}) + len}. + +Vediamo allora un esempio dell'uso dell'interfaccia di \textit{inotify} con un +semplice programma che permette di mettere sotto osservazione un file o una +directory. @@ -1337,7 +1615,8 @@ numero di file che sono cambiati. % TODO inserire anche eventfd (vedi http://lwn.net/Articles/233462/) - +% e le restanti signalfd e timerfd introdotte con il 2.6.22 +% o trovargli un posto migliore \subsection{L'interfaccia POSIX per l'I/O asincrono} @@ -1575,7 +1854,7 @@ operazioni di sincronizzazione dei dati saranno completate. In alcuni casi può essere necessario interrompere le operazioni (in genere quando viene richiesta un'uscita immediata dal programma), per questo lo -standard POSIX.1b prevede una funzioni apposita, \funcd{aio\_cancel}, che +standard POSIX.1b prevede una funzione apposita, \funcd{aio\_cancel}, che permette di cancellare una operazione richiesta in precedenza; il suo prototipo è: \begin{prototype}{aio.h} @@ -1934,7 +2213,7 @@ tab.~\ref{tab:file_mmap_flag}. da \param{start}, se questo non può essere usato \func{mmap} fallisce. Se si imposta questo flag il valore di \param{start} deve essere allineato - alle dimensioni di una pagina. \\ + alle dimensioni di una pagina.\\ \const{MAP\_SHARED} & I cambiamenti sulla memoria mappata vengono riportati sul file e saranno immediatamente visibili agli altri processi che mappano lo stesso @@ -1942,7 +2221,7 @@ tab.~\ref{tab:file_mmap_flag}. aggiornato fino alla chiamata di \func{msync} o \func{munmap}), e solo allora le modifiche saranno visibili per l'I/O convenzionale. Incompatibile - con \const{MAP\_PRIVATE}. \\ + con \const{MAP\_PRIVATE}.\\ \const{MAP\_PRIVATE} & I cambiamenti sulla memoria mappata non vengono riportati sul file. Ne viene fatta una copia privata cui solo il processo chiamante ha @@ -1952,13 +2231,13 @@ tab.~\ref{tab:file_mmap_flag}. salvate su swap in caso di necessità. Non è specificato se i cambiamenti sul file originale vengano riportati sulla regione - mappata. Incompatibile con \const{MAP\_SHARED}. \\ + mappata. Incompatibile con \const{MAP\_SHARED}.\\ \const{MAP\_DENYWRITE} & In Linux viene ignorato per evitare \textit{DoS} \itindex{Denial~of~Service~(DoS)} (veniva usato per segnalare che tentativi di scrittura sul file dovevano fallire con \errcode{ETXTBSY}).\\ - \const{MAP\_EXECUTABLE}& Ignorato. \\ + \const{MAP\_EXECUTABLE}& Ignorato.\\ \const{MAP\_NORESERVE} & Si usa con \const{MAP\_PRIVATE}. Non riserva delle pagine di swap ad uso del meccanismo del \textit{copy on write} \itindex{copy~on~write} @@ -1966,7 +2245,7 @@ tab.~\ref{tab:file_mmap_flag}. modifiche fatte alla regione mappata, in questo caso dopo una scrittura, se non c'è più memoria disponibile, si ha l'emissione di - un \const{SIGSEGV}. \\ + un \const{SIGSEGV}.\\ \const{MAP\_LOCKED} & Se impostato impedisce lo swapping delle pagine mappate.\\ \const{MAP\_GROWSDOWN} & Usato per gli \itindex{stack} stack. Indica @@ -1984,9 +2263,9 @@ tab.~\ref{tab:file_mmap_flag}. richiesto \const{MAP\_FIXED}.\\ \const{MAP\_POPULATE} & Esegue il \itindex{prefaulting} \textit{prefaulting} delle pagine di memoria - necessarie alla mappatura. \\ + necessarie alla mappatura.\\ \const{MAP\_NONBLOCK} & Esegue un \textit{prefaulting} più limitato che - non causa I/O.\footnotemark \\ + non causa I/O.\footnotemark\\ % \const{MAP\_DONTEXPAND}& Non consente una successiva espansione dell'area % mappata con \func{mremap}, proposto ma pare non % implementato.\\ @@ -2340,7 +2619,7 @@ nuova system call, \funcd{remap\_file\_pages}, il cui prototipo Permette di rimappare non linearmente un precedente \textit{memory mapping}. - \bodydesc{La funzione restituisce 0 in caso di successo e -1 in caso di + \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno dei valori: \begin{errlist} \item[\errcode{EINVAL}] Si è usato un valore non valido per uno degli @@ -2406,18 +2685,92 @@ mappatura che gi \subsection{L'I/O diretto fra file descriptor} \label{sec:file_sendfile_splice} -Uno dei problemi -NdA è da finire, sul perché non è abilitata fra file vedi: +Uno dei problemi che si presenta nella gestione dell'I/O è quello in cui si +devono trasferire grandi quantità di dati da un file descriptor ed un altro; +questo usualmente comporta la lettura dei dati dal primo file descriptor in un +buffer in memoria, da cui essi vengono poi scritti sul secondo. + +Benché il kernel ottimizzi la gestione di questo processo quando si ha a che +fare con file normali, in generale quando i dati da trasferire sono molti si +pone il problema di effettuare trasferimenti di grandi quantità di dati da +kernel space a user space e all'indietro, quando in realtà sarebbe molto più +efficiente tenere tutto in kernel space. Tratteremo in questa sezione alcune +funzioni specialistiche che permettono di ottimizzare le prestazioni in questo +tipo di situazioni. + +La prima funzione che si pone l'obiettivo di ottimizzare il trasferimento dei +dati fra due file descriptor è \funcd{sendfile}; la funzione è presente in +diverse versioni di Unix,\footnote{la si ritrova ad esempio in FreeBSD, HPUX + ed altri Unix.} ma non è presente né in POSIX.1-2001 né in altri standard, +per cui vengono utilizzati diversi prototipi e semantiche +differenti;\footnote{pertanto si eviti di utilizzarla se si devono scrivere + programmi portabili.} nel caso di Linux il suo prototipo è: +\begin{functions} + \headdecl{sys/sendfile.h} + + \funcdecl{ssize\_t sendfile(int out\_fd, int in\_fd, off\_t *offset, size\_t + count)} + + Copia dei dati da un file descriptor ad un altro. + + \bodydesc{La funzione restituisce 0 in caso di successo e $-1$ in caso di + errore, nel qual caso \var{errno} assumerà uno dei valori: + \begin{errlist} + \item[\errcode{EAGAIN}] si è impostata la modalità non bloccante su + \param{out\_fd} e la scrittura si bloccherebbe. + \item[\errcode{EINVAL}] i file descriptor non sono validi, o sono bloccati + o una operazione di \func{mmap} non è disponibile per \param{in\_fd}. + \item[\errcode{EIO}] si è avuto un errore di lettura da \param{in\_fd}. + \item[\errcode{ENOMEM}] non c'è memoria sufficiente per la lettura da + \param{in\_fd}. + \end{errlist} + ed inoltre \errcode{EBADF} e \errcode{EFAULT}. + } +\end{functions} + + +%NdA è da finire, sul perché non è abilitata fra file vedi: +%\href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html} +%{\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}} -\href{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html} -{\texttt{http://www.cs.helsinki.fi/linux/linux-kernel/2001-03/0200.html}} % TODO documentare la funzione sendfile % TODO documentare le funzioni tee e splice % http://kerneltrap.org/node/6505 e http://lwn.net/Articles/178199/ e % http://lwn.net/Articles/179492/ % e http://en.wikipedia.org/wiki/Splice_(system_call) +% e http://kerneltrap.org/node/6505 + + + + +\subsection{Gestione avanzata dell'accesso ai dati dei file} +\label{sec:file_fadvise} + +Nell'uso generico dell'interfaccia per l'accesso al contenuto dei file le +operazioni di lettura e scrittura non necessitano di nessun intervento di +supervisione da parte dei programmi, si eseguirà una \func{read} o una +\func{write}, i dati verranno passati al kernel che provvederà ad effettuare +tutte le operazioni (e a gestire il \textit{caching} dei dati) per portarle a +termine in quello che ritiene essere il modo più efficiente. + +Il problema è che il concetto di migliore efficienza impiegato dal kernel è +relativo all'uso generico, mentre esistono molti casi in cui ci sono esigenze +specifiche dei singoli programmi, che avendo una conoscenza diretta di come +verranno usati i file, possono necessitare di effettuare delle ottimizzazioni +specifiche, relative alle proprie modalità di I/O sugli stessi. Tratteremo in +questa sezione una serie funzioni che consentono ai programmi di ottimizzare +il loro accesso ai dati dei file. + + +% TODO documentare \func{madvise} +% TODO documentare \func{mincore} +% TODO documentare \func{posix\_fadvise} +% vedi http://insights.oetiker.ch/linux/fadvise.html +% questo tread? http://www.ussg.iu.edu/hypermail/linux/kernel/0703.1/0032.html +% TODO documentare \func{fallocate}, introdotta con il 2.6.23 +% vedi http://lwn.net/Articles/226710/ e http://lwn.net/Articles/240571/ %\subsection{L'utilizzo delle porte di I/O} @@ -3163,7 +3516,7 @@ tab.~\ref{tab:file_lockf_type}. \const{LOCK\_SH}& Richiede uno \textit{shared lock}. Più processi possono mantenere un lock condiviso sullo stesso file.\\ \const{LOCK\_EX}& Richiede un \textit{exclusive lock}. Un solo processo - alla volta può mantenere un lock esclusivo su un file. \\ + alla volta può mantenere un lock esclusivo su un file.\\ \const{LOCK\_UN}& Sblocca il file.\\ \const{LOCK\_NB}& Non blocca la funzione quando il lock non è disponibile, si specifica sempre insieme ad una delle altre operazioni @@ -3318,7 +3671,9 @@ possibilit % LocalWords: dell'inode CLOSE NOWRITE MOVE MOVED FROM TO rm wd event page ctl % LocalWords: attribute Universe epoll Solaris kqueue level triggered Jonathan % LocalWords: Lemon BSDCON edge Libenzi kevent backporting epfd EEXIST ENOENT -% LocalWords: MOD +% LocalWords: MOD wait EPOLLIN EPOLLOUT EPOLLRDHUP SOCK EPOLLPRI EPOLLERR one +% LocalWords: EPOLLHUP EPOLLET EPOLLONESHOT shot maxevents ctlv ALL DONT HPUX +% LocalWords: FOLLOW ONESHOT ONLYDIR FreeBSD EIO caching %%% Local Variables: