X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileadv.tex;h=3b0575ae289f19441b6dbe59a50d2b032f809c0b;hp=687d7cd52403e07036170e3d91eab53b0ab959df;hb=34f320bccbbb744f178061b94e3a7197c35edd28;hpb=247c7ba624f39b283f9e85816c0616348f39c1b6 diff --git a/fileadv.tex b/fileadv.tex index 687d7cd..3b0575a 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -388,10 +388,11 @@ implementata sia direttamente nel kernel, che in user space attraverso l'uso di thread. Al momento\footnote{fino ai kernel della serie 2.4.x, nella serie 2.5.x è però iniziato un lavoro completo di riscrittura di tutto il sistema di I/O, che prevede anche l'introduzione di un nuovo layer per l'I/O - asincrono.} esiste una sola versione stabile di questa interfaccia, quella -delle \acr{glibc}, che è realizzata completamente in user space. Esistono -comunque vari progetti sperimentali (come il KAIO della SGI, o i patch di -Benjamin La Haise) che prevedono un supporto diretto da parte del kernel. + asincrono (effettuato a partire dal 2.5.32).} esiste una sola versione +stabile di questa interfaccia, quella delle \acr{glibc}, che è realizzata +completamente in user space. Esistono comunque vari progetti sperimentali +(come il KAIO della SGI, o i patch di Benjamin La Haise) che prevedono un +supporto diretto da parte del kernel. Lo standard prevede che tutte le operazioni di I/O asincrono siano controllate attraverso l'uso di una apposita struttura \type{aiocb} (il cui nome sta per @@ -546,17 +547,8 @@ errore; il suo prototipo \param{aiocbp}. \bodydesc{La funzione restituisce 0 se le operazioni si sono concluse con - successo, altrimenti restituisce il codice di errore.} -% }, che viene salvato -% anche in \var{errno}, i valori possibili sono: -% \begin{errlist} -% \item[\macro{ENOSYS}] La funzione non è implementata. -% \item[\macro{EINPROGRESS}] L'operazione è ancora in corso. -% \item[\macro{EINVAL}] Si è specificato un valore non valido per i campi -% \var{aio\_offset} o \var{aio\_reqprio} di \param{aiocbp}. -% \item[\macro{EBADF}] Si è specificato un file descriptor sbagliato. -% \end{errlist} -% più tutti quelli possibili per le sottostanti operazioni, .} + successo, altrimenti restituisce il codice di errore relativo al loro + fallimento.} \end{prototype} Se l'operazione non si è ancora completata viene restituito l'errore di @@ -765,11 +757,11 @@ operazioni. Per questo motivo BSD 4.2\footnote{Le due funzioni sono riprese da BSD4.4 ed integrate anche dallo standard Unix 98; fino alle libc5 Linux usava \type{size\_t} come tipo dell'argomento \param{count}, una scelta logica, - che è stata dismessa per restare aderenti allo standard.} ha introdotto due -nuove system call, \func{readv} e \func{writev}, 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: + che però è stata dismessa per restare aderenti allo standard.} ha introdotto +due nuove system call, \func{readv} e \func{writev}, 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} @@ -821,10 +813,12 @@ struct iovec { \label{fig:file_iovec} \end{figure} -I buffer da utilizzare sono specificati attraverso l'argomento \var{vector} che -è un vettore di tale strutture, la cui lunghezza è specificata da \param{count}. -Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati. - +I buffer da utilizzare sono indicati attraverso l'argomento \param{vector} che +è un vettore di strutture \var{iovec}, la cui lunghezza è specificata da +\param{count}. Ciascuna struttura dovrà essere inizializzata per +opportunamente per indicare i vari buffer da/verso i quali verrà eseguito il +trasferimento dei dati. Essi verranno letti (o scritti) nell'ordine in cui li +si sono specificati nel vattore \var{vector}. \subsection{File mappati in memoria} @@ -832,23 +826,37 @@ Essi verranno letti (o scritti) nell'ordine in cui li si sono specificati. Una modalità alternativa di I/O, che usa una interfaccia completamente diversa rispetto a quella classica vista in \capref{cha:file_unix_interface}, è il -cosiddetto \textit{memory-mapped I/O}, che attraverso il meccanismo della +cosiddetto \textit{memory-mapped I/O}, che, attraverso il meccanismo della \textsl{paginazione}\index{paginazione} usato dalla memoria virtuale (vedi -\secref{sec:proc_mem_gen}) permette di \textsl{mappare} il contenuto di un -file in una sezione dello spazio di indirizzi del processo. +\secref{sec:proc_mem_gen}), permette di \textsl{mappare} il contenuto di un +file in una sezione dello spazio di indirizzi del processo. Il meccanismo è +illustrato in \figref{fig:file_mmap_layout}, una sezione del file viene +riportata direttamente nello spazio degli indirizzi del programma. Tutte le +operazioni su questa zona verranno riportate indietro sul file dal meccanismo +della memoria virtuale che trasferirà il contenuto di quel segmento sul file +invece che nella swap, per cui si può parlare tanto di file mappato in +memoria, quanto di memoria mappata su file. + +\begin{figure}[htb] + \centering + \includegraphics[width=9.5cm]{img/mmap_layout} + \caption{Disposizione della memoria di un processo quando si esegue la + mappatuara in memoria di un file.} + \label{fig:file_mmap_layout} +\end{figure} Tutto questo comporta una notevole semplificazione delle operazioni di I/O, in quanto non sarà più necessario utilizzare dei buffer intermedi su cui appoggiare i dati da traferire, ma questi potranno essere acceduti -direttamente dalla sezione di memoria; inoltre questa interfaccia -è più efficiente delle usuali funzioni di I/O, in quanto permette di caricare -in memoria solo le parti del file che sono effettivamente usate ad un dato +direttamente nella sezione di memoria mappata; inoltre questa interfaccia è +più efficiente delle usuali funzioni di I/O, in quanto permette di caricare in +memoria solo le parti del file che sono effettivamente usate ad un dato istante. Infatti, dato che l'accesso è fatto direttamente attraverso la memoria virtuale, la sezione di memoria mappata su cui si opera sarà a sua volta letta o scritta sul file una pagina alla volta e solo per le parti effettivamente -usate, il tutto in maniera completamente trasparente al processo; l'acceso +usate, il tutto in maniera completamente trasparente al processo; l'accesso alle pagine non ancora caricate avverrà allo stesso modo con cui vengono caricate in memoria le pagine che sono state salvate sullo swap. @@ -858,15 +866,15 @@ vengono scritte sulla swap; questo consente di accedere ai file su dimensioni il cui solo limite è quello dello spazio di indirizzi disponibile, e non della memoria su cui possono esserne lette delle porzioni. -L'interfaccia prevede varie funzioni per la gestione del \textit{memory - mapping}, la prima di queste è \func{mmap}, che esegue la mappatura in -memoria un file; il suo prototipo è: +L'interfaccia prevede varie funzioni per la gestione del \textit{memory mapped + I/O}, la prima di queste è \func{mmap}, che serve ad eseguire la mappatura +in memoria di un file; il suo prototipo è: \begin{functions} \headdecl{unistd.h} \headdecl{sys/mman.h} - \funcdecl{void * mmap(void *start, size\_t length, int prot, int flags, int + \funcdecl{void * mmap(void * start, size\_t length, int prot, int flags, int fd, off\_t offset)} Esegue la mappatura in memoria del file \param{fd}. @@ -891,7 +899,7 @@ memoria un file; il suo prototipo \item[\macro{EAGAIN}] Il file è bloccato, o si è bloccata troppa memoria. \item[\macro{ENOMEM}] Non c'è memoria o si è superato il limite sul numero di mappature possibili. - \item[\macro{ENODEV}] Il filesystem di \param{fd} no supporta il memory + \item[\macro{ENODEV}] Il filesystem di \param{fd} non supporta il memory mapping. \end{errlist} } @@ -900,18 +908,8 @@ memoria un file; il suo prototipo La funzione richiede di mappare in memoria la sezione del file \param{fd} a partire da \param{offset} per \param{lenght} byte, preferibilmente all'indirizzo \param{start}. Il valore di \param{offset} deve essere un -multiplo della dimensione di una pagina di memoria. Il valore dell'argomento -\param{prot} indica la protezione\footnote{in Linux la memoria reale è divisa - in pagine: ogni processo vede la sua memoria attraverso uno o più segmenti - lineari di memoria virtuale. Per ciascuno di questi segmenti il kernel - mantiene nella \textit{page table} la mappatura sulle pagine di memoria - reale, ed le modalità di accesso (lettura, esecuzione, scrittura); una loro - violazione causa quella che si chiama una \textit{segment violation}, e la - relativa emissione del segnale \macro{SIGSEGV}.} da applicare al segmento di -memoria e deve essere specificato come maschera binaria ottenuta dall'OR di -uno o più dei valori riportati in \tabref{tab:file_mmap_flag}; il valore -specificato deve essere compatibile con la modalità con cui si è aperto il -file. +multiplo della dimensione di una pagina di memoria. + \begin{table}[htb] \centering @@ -932,8 +930,21 @@ file. \label{tab:file_mmap_prot} \end{table} -L'argomento \param{flags} specifica qual'è il tipo di oggetto mappato, le -opzioni relative alle modalità con cui è effettuata la mappatura e alle + +Il valore dell'argomento \param{prot} indica la protezione\footnote{in Linux + la memoria reale è divisa in pagine: ogni processo vede la sua memoria + attraverso uno o più segmenti lineari di memoria virtuale. Per ciascuno di + questi segmenti il kernel mantiene nella \textit{page table} la mappatura + sulle pagine di memoria reale, ed le modalità di accesso (lettura, + esecuzione, scrittura); una loro violazione causa quella che si chiama una + \textit{segment violation}, e la relativa emissione del segnale + \macro{SIGSEGV}.} da applicare al segmento di memoria e deve essere +specificato come maschera binaria ottenuta dall'OR di uno o più dei valori +riportati in \tabref{tab:file_mmap_flag}; il valore specificato deve essere +compatibile con la modalità di accesso con cui si è aperto il file. + +L'argomento \param{flags} specifica infine qual'è il tipo di oggetto mappato, +le opzioni relative alle modalità con cui è effettuata la mappatura e alle modalità con cui le modifiche alla memoria mappata vengono condivise o mantenute private al processo che le ha effettuate. Deve essere specificato come maschera binaria ottenuta dall'OR di uno o più dei valori riportati in @@ -976,8 +987,8 @@ come maschera binaria ottenuta dall'OR di uno o pi \macro{MAP\_EXECUTABLE}& Ignorato. \\ \macro{MAP\_NORESERVE} & Si usa con \macro{MAP\_PRIVATE}. Non riserva delle pagine di swap ad uso del meccanismo di - \textit{copy on write} per mantenere le modifiche - fatte alla regione mappata, in + \textit{copy on write} per mantenere le + modifiche fatte alla regione mappata, in questo caso dopo una scrittura, se non c'è più memoria disponibile, si ha l'emissione di un \macro{SIGSEGV}. \\ @@ -1002,35 +1013,85 @@ come maschera binaria ottenuta dall'OR di uno o pi \footnotetext{L'uso di questo flag con \macro{MAP\_SHARED} è stato implementato in Linux a partire dai kernel della serie 2.4.x.} -Un file viene sempre mappato su multipli delle dimensioni di una pagina, -qualora esso sia più corto la parte restante è riempita con zeri; eventuali -scritture in quella zona di memoria non vengono riportate sul file. Se le -dimensioni del file cambiano (esso viene esteso o troncato), non è specificato -quale effetto viene a aversi sulle pagine di memoria che corrispondono alle -regioni aggiunte o tolte. - -Si tenga presente che non tutti i file possono venire mappati in memoria, la -mappatura infatti introduce una corrispondenza biunivoca fra una sezione di un -file ed una sezione di memoria, pertanto si può parlare tanto di file mappato -in memoria, quanto di memoria mappata su file. Questo comporta che ad esempio -non è possibile mappare in memoria pipe, socket e fifo, per le quali non ha -senso parlare di \textsl{sezione}. Lo stesso vale anche per alcuni file di -dispositivo, che non dispongono della relativa operazione \var{mmap} (si -ricordi quanto esposto in \secref{sec:file_vfs_work}), ma esistono anche casi -(un esempio è l'interfaccia ponte PCI-VME del chip Universe) di dispositivi -che sono utilizzabili praticamente solo con questa interfaccia. - -Passando attraverso una \func{fork} i file mappati in memoria vengono -ereditati in maniera trasparente dal processo figlio, mantenendo gli stessi -attributi avuti nel padre; così se si è usato \macro{MAP\_SHARED} padre e -figlio accederanno allo stesso file in maniera condivisa, mentre se si è usato -\macro{MAP\_PRIVATE} ciascuno di essi manterrà una sua versione privata -indipendente. Non c'è invece nessun passaggio attraverso una \func{exec}, dato -che quest'ultima sostituisce tutto lo spazio degli indirizzi di un processo -con quello di un nuovo programma. +Gli effetti dell'accesso ad una zona di memoria mappata su file possono essere +piuttosto complessi, essi si possono comprendere solo tenendo presente che +tutto quanto è comunque basato sul basato sul meccanismo della memoria +virtuale. Questo comporta allora una serie di conseguenze. La più ovvia è che +se si cerca di scrivere su una zona mappata in sola lettura si avrà +l'emissione di un segnale di violazione di accesso (\macro{SIGSEGV}), dato che +i permessi sul segmento di memoria relativo non consentono questo tipo di +accesso. + +È invece assai diversa la questione relativa agli accessi al di fuori della +regione di cui si è richiesta la mappatura. A prima vista infatti si potrebbe +ritenere che anch'essi debbano generare un segnale di violazione di accesso; +questo però non tiene conto del fatto che, essendo basata sul meccanismo della +paginazione, la mappatura in memoria non può che essere eseguita su un +segmento di dimensioni rigorosamente multiple di quelle di una pagina, ed in +generale queste potranno non corrispondere alle dimensioni effettive del file +o della sezione che si vuole mappare. Il caso più comune è quello illustrato +in \figref{fig:file_mmap_boundary}, in cui la sezione di file non rientra nei +confini di una pagina: in tal caso verrà il file sarà mappato su un segmento +di memoria che si estende fino al bordo della pagina successiva. + +\begin{figure}[htb] + \centering + \includegraphics[width=10cm]{img/mmap_boundary} + \caption{Schema della mappatura in memoria di una sezione di file di + dimensioni non corripondenti al bordo di una pagina.} + \label{fig:file_mmap_boundary} +\end{figure} + + +In questo caso è possibile accedere a quella zona di memoria che eccede le +dimensioni specificate da \param{lenght}, senza ottenere un \macro{SIGSEGV} +poiché essa è presente nello spazio di indirizzi del processo, anche se non è +mappata sul file. Il comportamento del sistema è quello di restituire un +valore nullo per quanto viene letto, e di non riportare su file quanto viene +scritto. + +Un caso più complesso è quello che si viene a creare quando le dimensioni del +file mappato sono più corte delle dimensioni della mappatura, oppure quando il +file è stato troncato, dopo che è stato mappato, ad una dimensione inferiore a +quella della mappatura in memoria. + +\begin{figure}[htb] + \centering + \includegraphics[width=13cm]{img/mmap_exceed} + \caption{Schema della mappatura in memoria di file di dimensioni inferiori + alla lunghezza richiesta.} + \label{fig:file_mmap_exceed} +\end{figure} + +In questa situazione, per la sezione di pagina parzialmente coperta dal +contenuto del file, vale esattamente quanto visto in precedenza; invece per la +parte che eccede, fino alle dimensioni date da \param{length}, l'accesso non +sarà più possibile, ma il segnale emesso non sarà \macro{SIGSEGV}, ma +\macro{SIGBUS}, come illustrato in \figref{fig:file_mmap_exceed}. + +Non tutti i file possono venire mappati in memoria, dato che, come illustrato +in \figref{fig:file_mmap_layout}, la mappatura introduce una corrispondenza +biunivoca fra una sezione di un file ed una sezione di memoria. Questo +comporta che ad esempio non è possibile mappare in memoria file descriptor +relativi a pipe, socket e fifo, per i quali non ha senso parlare di +\textsl{sezione}. Lo stesso vale anche per alcuni file di dispositivo, che non +dispongono della relativa operazione \var{mmap} (si ricordi quanto esposto in +\secref{sec:file_vfs_work}). Si tenga presente però che esistono anche casi di +dispositivi (un esempio è l'interfaccia al ponte PCI-VME del chip Universe) +che sono utilizzabili solo con questa interfaccia. + +Dato che passando attraverso una \func{fork} lo spazio di indirizzi viene +copiato integralmente, i file mappati in memoria verranno ereditati in maniera +trasparente dal processo figlio, mantenendo gli stessi attributi avuti nel +padre; così se si è usato \macro{MAP\_SHARED} padre e figlio accederanno allo +stesso file in maniera condivisa, mentre se si è usato \macro{MAP\_PRIVATE} +ciascuno di essi manterrà una sua versione privata indipendente. Non c'è +invece nessun passaggio attraverso una \func{exec}, dato che quest'ultima +sostituisce tutto lo spazio degli indirizzi di un processo con quello di un +nuovo programma. Quando si effettua la mappatura di un file vengono pure modificati i tempi ad -esso associati (si ricordi quanto esposto in \secref{sec:file_file_times}). Il +esso associati (di cui si è trattato in \secref{sec:file_file_times}). Il valore di \var{st\_atime} può venir cambiato in qualunque istante a partire dal momento in cui la mappatura è stata effettuata: il primo riferimento ad una pagina mappata su un file aggiorna questo tempo. I valori di @@ -1042,19 +1103,19 @@ o in corrispondenza di una eventuale \func{msync}. Dato per i file mappati in memoria le operazioni di I/O sono gestite direttamente dalla memoria virtuale, occorre essere consapevoli delle interazioni che possono esserci con operazioni effettuate con l'interfaccia -standard dei file di \capref{sec:file_unix_interface}. Il problema è che una +standard dei file di \capref{cha:file_unix_interface}. Il problema è che una volta che si è mappato un file, le operazioni di lettura e scrittura saranno eseguite sulla memoria, e riportate su disco in maniera autonoma dal sistema della memoria virtuale. Pertanto se si modifica un file con l'interfaccia standard queste modifiche potranno essere visibili o meno a seconda del momento in cui la memoria -virtuale leggerà dal disco in memoria quella sezione del file, perciò è del -tutto indefinito il risultato della modifica nei confronti del contenuto della -memoria mappata. +virtuale trasporterà dal disco in memoria quella sezione del file, perciò è +del tutto imprevedibile il risultato della modifica di un file nei confronti +del contenuto della memoria mappata su cui è mappato. -Se è, per quanto appena visto, sconsigliabile eseguire scritture su file -attraverso l'interfaccia standard quando lo si è mappato in memoria, è invece +Per quanto appena visto, è sempre sconsigliabile eseguire scritture su file +attraverso l'interfaccia standard, quando lo si è mappato in memoria, è invece possibile usare l'interfaccia standard per leggere un file mappato in memoria, purché si abbia una certa cura; infatti l'interfaccia dell'I/O mappato in memoria mette a disposizione la funzione \func{msync} per sincronizzare il @@ -1085,16 +1146,6 @@ relativi tempi di modifica. In questo modo si di \func{msync} le funzioni dell'interfaccia standard troveranno un contenuto del file aggiornato. -L'argomento \param{flag} è specificato come maschera binaria composta da un OR -dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però -\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore -infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al -meccanismo della memoria virtuale, ritornando subito, mentre con il secondo -attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo -flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte -le mappature dello stesso file, così che esse possano essere immediatamente -aggiornate ai nuovi valori. - \begin{table}[htb] \centering \footnotesize @@ -1113,6 +1164,16 @@ aggiornate ai nuovi valori. \label{tab:file_mmap_rsync} \end{table} +L'argomento \param{flag} è specificato come maschera binaria composta da un OR +dei valori riportati in \tabref{tab:file_mmap_rsync}, di questi però +\macro{MS\_ASYNC} e \macro{MS\_SYNC} sono incompatibili; con il primo valore +infatti la funzione si limita ad inoltrare la richiesta di sincronizzazione al +meccanismo della memoria virtuale, ritornando subito, mentre con il secondo +attende che la sincronizzazione sia stata effettivamente eseguita. Il terzo +flag fa invalidare le pagine di cui si richiede la sincronizzazione per tutte +le mappature dello stesso file, così che esse possano essere immediatamente +aggiornate ai nuovi valori. + Una volta che si sono completate le operazioni di I/O si può eliminare la mappatura della memoria usando la funzione \func{munmap}, il suo prototipo è: \begin{functions} @@ -1140,8 +1201,8 @@ pagine contenute (anche parzialmente) nell'intervallo indicato, verr Indicare un intervallo che non contiene pagine mappate non è un errore. Alla conclusione del processo, ogni pagina mappata verrà automaticamente -rilasciata, mentre la chiusura del file descriptor non ha alcun effetto sulla -mappatura della memoria. +rilasciata, mentre la chiusura del file descriptor usato per effettuare la +mappatura in memoria non ha alcun effetto sulla stessa. \section{Il file locking} @@ -1189,14 +1250,14 @@ opportune verifiche nei processi, questo verrebbe comunque rispettato. Per poter utilizzare il \textit{mandatory locking} è stato introdotto un utilizzo particolare del bit \acr{suid}. Se si ricorda quanto esposto in -\secref{sec:file_suid_sgid}), esso viene di norma utlizzato per cambiare -l'\textit{effective user ID} con cui viene eseguito un programma, ed è -pertanto sempre associato alla presenza del permesso di esecuzione. Impostando -questo bit su un file senza permesso di esecuzione in un sistema che supporta -il \textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il -file in questione. In questo modo una combinaizone dei permessi -originariamente non contemplata, in quanto senza significato, diventa -l'indicazione della presenza o meno del \textit{mandatory locking}. +\secref{sec:file_suid_sgid}), esso viene di norma utilizzato per cambiare +l'userid effettivo con cui viene eseguito un programma, ed è pertanto sempre +associato alla presenza del permesso di esecuzione. Impostando questo bit su +un file senza permesso di esecuzione in un sistema che supporta il +\textit{mandatory locking}, fa sì che quest'ultimo venga attivato per il file +in questione. In questo modo una combinaizone dei permessi originariamente non +contemplata, in quanto senza significato, diventa l'indicazione della presenza +o meno del \textit{mandatory locking}.