From: Simone Piccardi Date: Sun, 5 Aug 2007 17:14:17 +0000 (+0000) Subject: Completata documentazione di {{{sendfile}}}. X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=commitdiff_plain;h=7c48ecb5bdc8242cc38b191faec1088d5b9ba46f Completata documentazione di {{{sendfile}}}. --- diff --git a/fileadv.tex b/fileadv.tex index 67887c8..67db7dd 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -1301,12 +1301,14 @@ eliminato.\footnote{anzi, una delle capacit 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 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}. +come dati disponibili in lettura, 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 degli eventi con +una qualunque delle modalità di \textit{I/O multiplexing} illustrate in +sez.~\ref{sec:file_multiplexing}. Qualora si voglia cessare l'osservazione, +sarà sufficiente chiudere il file descriptor e tutte le risorse allocate +saranno automaticamente rilasciate. Infine l'interfaccia di \textit{inotify} consente di mettere sotto osservazione, oltre che una directory, anche singoli file. Una volta creata @@ -1380,7 +1382,7 @@ flag della prima parte. \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 @@ -1391,13 +1393,13 @@ flag della prima parte. directory sotto osservazione.\\ \const{IN\_OPEN} &$\bullet$& Un file è stato aperto.\\ \hline - \const{IN\_CLOSE} & -- & Combinazione di + \const{IN\_CLOSE} & & Combinazione di \const{IN\_CLOSE\_WRITE} e \const{IN\_CLOSE\_NOWRITE}.\\ - \const{IN\_MOVE} & -- & Combinazione di + \const{IN\_MOVE} & & Combinazione di \const{IN\_MOVED\_FROM} e \const{IN\_MOVED\_TO}.\\ - \const{IN\_ALL\_EVENTS} & -- & Combinazione di tutti i flag + \const{IN\_ALL\_EVENTS} & & Combinazione di tutti i flag possibili.\\ \hline \end{tabular} @@ -1717,9 +1719,9 @@ nelle dimensioni del buffer specificato.\footnote{si avr riferimento sempre al codice di fig.~\ref{fig:inotify_monitor_example}, che \var{read} sarà in genere minore delle dimensioni di \var{buffer} ed uguale soltanto qualora gli eventi corrispondano esattamente alle dimensioni di - quest'ultimo.} Se gli eventi sono di più ne saranno restituiti solo quelli -che entrano interamente nel buffer e gli altri saranno restituiti alla -successiva chiamata di \func{read}. + quest'ultimo.} Se gli eventi sono di più saranno restituiti solo quelli che +entrano interamente nel buffer e gli altri saranno restituiti alla successiva +chiamata di \func{read}. Infine un'ultima caratteristica dell'interfaccia di \textit{inotify} è che gli eventi restituiti nella lettura formano una sequenza ordinata, è cioè @@ -1729,9 +1731,6 @@ verificano pi dei campi \var{wd}, \var{mask}, \var{cookie}, e \var{name}) questi vengono raggruppati in un solo evento. -% TODO inserire anche inotify, vedi http://www.linuxjournal.com/article/8478 -% TODO e man inotify - \index{file!inotify|)} @@ -2104,199 +2103,8 @@ Oltre alle precedenti modalit asincrono}, esistono altre funzioni che implementano delle modalità di accesso ai file più evolute rispetto alle normali funzioni di lettura e scrittura che abbiamo esaminato in sez.~\ref{sec:file_base_func}. In questa -sezione allora prenderemo in esame le interfacce per l'\textsl{I/O - vettorizzato} e per l'\textsl{I/O mappato in memoria} e la funzione -\func{sendfile}. - - -\subsection{I/O vettorizzato} -\label{sec:file_multiple_io} - -Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una -serie multipla di operazioni di I/O, come una serie di letture o scritture di -vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di -una struttura ed essi devono essere caricati o salvati su un file. Benché -l'operazione sia facilmente eseguibile attraverso una serie multipla di -chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle -operazioni. - -Per questo motivo su BSD 4.2 sono state introdotte due nuove system call, -\funcd{readv} e \funcd{writev},\footnote{in Linux le due funzioni sono riprese - da BSD4.4, esse sono previste anche dallo standard POSIX.1-2001.} che -permettono di effettuare con una sola chiamata una lettura o una scrittura su -una serie di buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I -relativi prototipi sono: -\begin{functions} - \headdecl{sys/uio.h} - - \funcdecl{int readv(int fd, const struct iovec *vector, int count)} - \funcdecl{int writev(int fd, const struct iovec *vector, int count)} - - Eseguono rispettivamente una lettura o una scrittura vettorizzata. - - \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti 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 è specificato un valore non valido per uno degli - argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}). - \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di - di avere eseguito una qualunque lettura o scrittura. - \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e - non ci sono dati in lettura. - \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena. - \end{errlist} - ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT} - (se non sono stati allocati correttamente i buffer specificati nei campi - \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e - scrittura eseguite su \param{fd}.} -\end{functions} - -Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è -riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono -essere letti o scritti ed in che quantità. Il primo campo della struttura, -\var{iov\_base}, contiene l'indirizzo del buffer ed il secondo, -\var{iov\_len}, la dimensione dello stesso. - -\begin{figure}[!htb] - \footnotesize \centering - \begin{minipage}[c]{15cm} - \includestruct{listati/iovec.h} - \end{minipage} - \normalsize - \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O - vettorizzato.} - \label{fig:file_iovec} -\end{figure} - -La lista dei buffer da utilizzare viene indicata attraverso l'argomento -\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza -è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux - usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta - logica, che però è stata dismessa per restare aderenti allo standard - POSIX.1-2001.} Ciascuna struttura dovrà essere inizializzata opportunamente -per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento -dei dati. Essi verranno letti (o scritti) nell'ordine in cui li si sono -specificati nel vettore \param{vector}. - -La standardizzazione delle due funzioni all'interno della revisione -POSIX.1-2001 prevede anche che sia possibile avere un limite al numero di -elementi del vettore \param{vector}. Qualora questo sussista, esso deve essere -indicato dal valore dalla costante \const{IOV\_MAX}, definita come le altre -costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \file{limits.h}; lo -stesso valore deve essere ottenibile in esecuzione tramite la funzione -\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi -sez.~\ref{sec:sys_sysconf}). - -Nel caso di Linux il limite di sistema è di 1024, però se si usano le -\acr{glibc} queste forniscono un \textit{wrapper} per le system call che si -accorge se una operazione supererà il precedente limite, in tal caso i dati -verranno letti o scritti con le usuali \func{read} e \func{write} usando un -buffer di dimensioni sufficienti appositamente allocato e sufficiente a -contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo -ma si perderà l'atomicità del trasferimento da e verso la destinazione finale. - - -% TODO verificare cosa succederà a preadv e pwritev o alla nuova niovec -% vedi http://lwn.net/Articles/164887/ - - -\subsection{L'I/O diretto fra file descriptor} -\label{sec:file_sendfile_splice} - - -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}} - - -% 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} -%\label{sec:file_io_port} -% -% TODO l'I/O sulle porte di I/O -% consultare le manpage di ioperm, iopl e outb +sezione allora prenderemo in esame le interfacce per l'\textsl{I/O mappato in + memoria}, per l'\textsl{I/O vettorizzato} e altre funzioni di I/O avanzato. \subsection{File mappati in memoria} @@ -2924,6 +2732,246 @@ mappatura che gi +\subsection{I/O vettorizzato} +\label{sec:file_multiple_io} + +Un caso abbastanza comune è quello in cui ci si trova a dover eseguire una +serie multipla di operazioni di I/O, come una serie di letture o scritture di +vari buffer. Un esempio tipico è quando i dati sono strutturati nei campi di +una struttura ed essi devono essere caricati o salvati su un file. Benché +l'operazione sia facilmente eseguibile attraverso una serie multipla di +chiamate, ci sono casi in cui si vuole poter contare sulla atomicità delle +operazioni. + +Per questo motivo su BSD 4.2 sono state introdotte due nuove system call, +\funcd{readv} e \funcd{writev},\footnote{in Linux le due funzioni sono riprese + da BSD4.4, esse sono previste anche dallo standard POSIX.1-2001.} che +permettono di effettuare con una sola chiamata una lettura o una scrittura su +una serie di buffer (quello che viene chiamato \textsl{I/O vettorizzato}. I +relativi prototipi sono: +\begin{functions} + \headdecl{sys/uio.h} + + \funcdecl{int readv(int fd, const struct iovec *vector, int count)} + \funcdecl{int writev(int fd, const struct iovec *vector, int count)} + + Eseguono rispettivamente una lettura o una scrittura vettorizzata. + + \bodydesc{Le funzioni restituiscono il numero di byte letti o scritti 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 è specificato un valore non valido per uno degli + argomenti (ad esempio \param{count} è maggiore di \const{IOV\_MAX}). + \item[\errcode{EINTR}] la funzione è stata interrotta da un segnale prima di + di avere eseguito una qualunque lettura o scrittura. + \item[\errcode{EAGAIN}] \param{fd} è stato aperto in modalità non bloccante e + non ci sono dati in lettura. + \item[\errcode{EOPNOTSUPP}] la coda delle richieste è momentaneamente piena. + \end{errlist} + ed anche \errval{EISDIR}, \errval{EBADF}, \errval{ENOMEM}, \errval{EFAULT} + (se non sono stati allocati correttamente i buffer specificati nei campi + \var{iov\_base}), più gli eventuali errori delle funzioni di lettura e + scrittura eseguite su \param{fd}.} +\end{functions} + +Entrambe le funzioni usano una struttura \struct{iovec}, la cui definizione è +riportata in fig.~\ref{fig:file_iovec}, che definisce dove i dati devono +essere letti o scritti ed in che quantità. Il primo campo della struttura, +\var{iov\_base}, contiene l'indirizzo del buffer ed il secondo, +\var{iov\_len}, la dimensione dello stesso. + +\begin{figure}[!htb] + \footnotesize \centering + \begin{minipage}[c]{15cm} + \includestruct{listati/iovec.h} + \end{minipage} + \normalsize + \caption{La struttura \structd{iovec}, usata dalle operazioni di I/O + vettorizzato.} + \label{fig:file_iovec} +\end{figure} + +La lista dei buffer da utilizzare viene indicata attraverso l'argomento +\param{vector} che è un vettore di strutture \struct{iovec}, la cui lunghezza +è specificata dall'argomento \param{count}.\footnote{fino alle libc5, Linux + usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta + logica, che però è stata dismessa per restare aderenti allo standard + POSIX.1-2001.} Ciascuna struttura dovrà essere inizializzata opportunamente +per indicare i vari buffer da e verso i quali verrà eseguito il trasferimento +dei dati. Essi verranno letti (o scritti) nell'ordine in cui li si sono +specificati nel vettore \param{vector}. + +La standardizzazione delle due funzioni all'interno della revisione +POSIX.1-2001 prevede anche che sia possibile avere un limite al numero di +elementi del vettore \param{vector}. Qualora questo sussista, esso deve essere +indicato dal valore dalla costante \const{IOV\_MAX}, definita come le altre +costanti analoghe (vedi sez.~\ref{sec:sys_limits}) in \file{limits.h}; lo +stesso valore deve essere ottenibile in esecuzione tramite la funzione +\func{sysconf} richiedendo l'argomento \const{\_SC\_IOV\_MAX} (vedi +sez.~\ref{sec:sys_sysconf}). + +Nel caso di Linux il limite di sistema è di 1024, però se si usano le +\acr{glibc} queste forniscono un \textit{wrapper} per le system call che si +accorge se una operazione supererà il precedente limite, in tal caso i dati +verranno letti o scritti con le usuali \func{read} e \func{write} usando un +buffer di dimensioni sufficienti appositamente allocato e sufficiente a +contenere tutti i dati indicati da \param{vector}. L'operazione avrà successo +ma si perderà l'atomicità del trasferimento da e verso la destinazione finale. + +% TODO verificare cosa succederà a preadv e pwritev o alla nuova niovec +% vedi http://lwn.net/Articles/164887/ + + +\subsection{L'I/O diretto fra file descriptor: \func{sendfile} e \func{splice}} +\label{sec:file_sendfile_splice} + +Uno dei problemi che si presentano 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à potrebbe essere più +efficiente mantenere 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};\footnote{la funzione è stata + introdotta con i kernel della serie 2.2, e disponibile dalle \acr{glibc} + 2.1..} 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,\footnote{pertanto si eviti di utilizzarla + se si devono scrivere programmi portabili.} per cui per essa vengono +utilizzati prototipi e semantiche differenti; 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 il numero di byte trasferiti in caso di + successo e $-1$ in caso di errore, nel qual caso \var{errno} assumerà uno + dei valori: + \begin{errlist} + \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 + (vedi sez.~\ref{sec:file_locking}), o \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} + +La funzione copia direttamente \param{count} byte dal file descriptor +\param{in\_fd} al file descriptor \param{out\_fd}; in caso di successo +funzione ritorna il numero di byte effettivamente copiati da \param{in\_fd} a +\param{out\_fd} o $-1$ in caso di errore, come le ordinarie \func{read} e +\func{write} questo valore può essere inferiore a quanto richiesto con +\param{count}. + +Se il puntatore \param{offset} è nullo la funzione legge i dati a partire +dalla posizione corrente su \param{in\_fd}, altrimenti verrà usata la +posizione indicata dal valore puntato da \param{offset}. In questo caso detto +valore sarà aggiornato, come \textit{value result argument}, per indicare la +posizione del byte successivo all'ultimo che è stato letto, mentre la +posizione corrente sul file non sarà modificata. Se invece \param{offset} è +nullo la posizione corrente sul file sarà aggiornata tenendo conto dei byte +letti da \param{in\_fd}. + +Fino ai kernel della serie 2.4 la funzione è utilizzabile su un qualunque file +descriptor, e permette di sostituire la invocazione successiva di una +\func{read} ed una \func{write} (e l'allocazione del relativo buffer) con una +sola chiamata a \funcd{sendfile}. In questo modo si può diminuire il numero di +chiamate al sistema e risparmiare in trasferimenti di dati da kernel space a +user space e viceversa. La massima utilità della funzione si ha comunque per +il trasferimento di dati da un file su disco ad socket di rete,\footnote{il + caso classico del lavoro un server web, ed infatti Apache ha una opzione per + il supporto esplicito di questa funzione.} dato che in questo caso diventa +possibile effettuare il trasferimento diretto via DMA dal controller del disco +alla scheda di rete, senza neanche allocare un buffer nel kernel.\footnote{il + meccanismo è detto \textit{zerocopy} in quanto i dati non vengono mai + copiati dal kernel, che si limita a programmare solo le operazioni di + lettura e scrittura via DMA.} + +Con i kernel della serie 2.6 ci si è accorti però che, a parte quest'ultimo +caso, l'uso di \func{sendfile} non portava significativi miglioramenti delle +prestazioni rispetto all'uso in sequenza di \func{read} e \func{write}, +\footnote{nel caso generico infatti il kernel deve comunque allocare un buffer + ed effettuare la copia dei dati, e in tal caso il guadagno ottenibile nel + ridurre il numero di chiamate non compensa le ottimizzazioni che possono + essere fatte da una applicazione in user space che ha una maggiore + conoscenza su come questi sono strutturati.} e che anzi in certi casi si +avevano dei peggioramenti, questo ha portato alla decisione\footnote{per le + motivazioni di questa scelta si può fare riferimento a quanto illustrato da + Linus Torvalds in + \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}}.} +di consentire l'uso della funzione soltanto quando il file da cui si legge +supporta le operazioni di \textit{memory mapping} (vale a dire non è un +socket) e quello su cui si scrive è un socket; in tutti gli altri casi si avrà +un errore di \errcode{EINVAL}. + + + + +% 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} +%\label{sec:file_io_port} +% +% TODO l'I/O sulle porte di I/O +% consultare le manpage di ioperm, iopl e outb + + + + \section{Il file locking} \label{sec:file_locking} @@ -3818,7 +3866,8 @@ possibilit % LocalWords: EPOLLHUP EPOLLET EPOLLONESHOT shot maxevents ctlv ALL DONT HPUX % LocalWords: FOLLOW ONESHOT ONLYDIR FreeBSD EIO caching sysctl instances name % LocalWords: watches IGNORED ISDIR OVERFLOW overflow UNMOUNT queued cookie ls -% LocalWords: NUL sizeof casting printevent nread +% LocalWords: NUL sizeof casting printevent nread limits sysconf SC wrapper +% LocalWords: splice result argument DMA controller zerocopy Linus %%% Local Variables: