From: Simone Piccardi Date: Mon, 17 Apr 2006 00:48:00 +0000 (+0000) Subject: Indicizzazioni varie X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=2ba81410053202b58aec9ce40344794d1c131491;p=gapil.git Indicizzazioni varie --- diff --git a/fileadv.tex b/fileadv.tex index 904e81e..7f6868e 100644 --- a/fileadv.tex +++ b/fileadv.tex @@ -907,8 +907,8 @@ richiesta, o in caso di errore. Non \errcode{EINVAL} siano rilevati immediatamente al momento della chiamata, potrebbero anche emergere nelle fasi successive delle operazioni. Lettura e scrittura avvengono alla posizione indicata da \var{aio\_offset}, a meno che -il file non sia stato aperto in \textit{append mode} (vedi -sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate +il file non sia stato aperto in \itindex{append~mode} \textit{append mode} +(vedi sez.~\ref{sec:file_open}), nel qual caso le scritture vengono effettuate comunque alla fine de file, nell'ordine delle chiamate a \func{aio\_write}. Si tenga inoltre presente che deallocare la memoria indirizzata da @@ -1856,18 +1856,20 @@ mappatura che gi \label{sec:file_locking} \index{file!locking|(} + In sez.~\ref{sec:file_sharing} abbiamo preso in esame le modalità in cui un sistema unix-like gestisce la condivisione dei file da parte di processi diversi. In quell'occasione si è visto come, con l'eccezione dei file aperti -in \textit{append mode}, quando più processi scrivono contemporaneamente sullo -stesso file non è possibile determinare la sequenza in cui essi opereranno. - -Questo causa la possibilità di una \textit{race condition} -\itindex{race~condition}; in generale le situazioni più comuni sono due: -l'interazione fra un processo che scrive e altri che leggono, in cui questi -ultimi possono leggere informazioni scritte solo in maniera parziale o -incompleta; o quella in cui diversi processi scrivono, mescolando in maniera -imprevedibile il loro output sul file. +in \itindex{append~mode} \textit{append mode}, quando più processi scrivono +contemporaneamente sullo stesso file non è possibile determinare la sequenza +in cui essi opereranno. + +Questo causa la possibilità di una \itindex{race~condition} \textit{race + condition}; in generale le situazioni più comuni sono due: l'interazione fra +un processo che scrive e altri che leggono, in cui questi ultimi possono +leggere informazioni scritte solo in maniera parziale o incompleta; o quella +in cui diversi processi scrivono, mescolando in maniera imprevedibile il loro +output sul file. In tutti questi casi il \textit{file locking} è la tecnica che permette di evitare le \textit{race condition}\itindex{race~condition}, attraverso una diff --git a/filestd.tex b/filestd.tex index c6cf457..f4b41a7 100644 --- a/filestd.tex +++ b/filestd.tex @@ -268,21 +268,23 @@ possono essere aperti con le funzioni delle librerie standard del C. \hline \hline \texttt{r} & Il file viene aperto, l'accesso viene posto in sola - lettura, lo stream è posizionato all'inizio del file.\\ - \texttt{r+} & Il file viene aperto, l'accesso viene posto in lettura e - scrittura, lo stream è posizionato all'inizio del file. \\ + lettura, lo stream è posizionato all'inizio del file.\\ + \texttt{r+}& Il file viene aperto, l'accesso viene posto in lettura e + scrittura, lo stream è posizionato all'inizio del file. \\ % \hline \texttt{w} & Il file viene aperto e troncato a lunghezza nulla (o - creato se non esiste), l'accesso viene posto in sola scrittura, lo - stream è posizionato all'inizio del file.\\ - \texttt{w+} & Il file viene aperto e troncato a lunghezza nulla (o - creato se non esiste), l'accesso viene posto in scrittura e lettura, - lo stream è posizionato all'inizio del file.\\ + creato se non esiste), l'accesso viene posto in sola + scrittura, lo stream è posizionato all'inizio del file.\\ + \texttt{w+}& Il file viene aperto e troncato a lunghezza nulla (o + creato se non esiste), l'accesso viene posto in scrittura e + lettura, lo stream è posizionato all'inizio del file.\\ % \hline \texttt{a} & Il file viene aperto (o creato se non esiste) in - \textit{append mode}, l'accesso viene posto in sola scrittura. \\ - \texttt{a+} & Il file viene aperto (o creato se non esiste) in - \textit{append mode}, l'accesso viene posto in lettura e scrittura. \\ + \itindex{append~mode} \textit{append mode}, l'accesso viene + posto in sola scrittura.\\ + \texttt{a+}& Il file viene aperto (o creato se non esiste) in + \itindex{append~mode} \textit{append mode}, l'accesso viene + posto in lettura e scrittura.\\ \hline \texttt{b} & specifica che il file è binario, non ha alcun effetto. \\ \texttt{x} & l'apertura fallisce se il file esiste già. \\ diff --git a/fileunix.tex b/fileunix.tex index 1bae4dd..bfaab85 100644 --- a/fileunix.tex +++ b/fileunix.tex @@ -304,7 +304,8 @@ descriptor con il valore pi a 31 bit. \\ \hline \hline % modalità di operazione coi file - \const{O\_APPEND} & Il file viene aperto in append mode. Prima di ciascuna + \const{O\_APPEND} & Il file viene aperto in \itindex{append~mode} + \textit{append mode}. Prima di ciascuna scrittura la posizione corrente viene sempre impostata alla fine del file. Con NFS si può avere una corruzione del file se più di un processo scrive allo @@ -355,9 +356,10 @@ descriptor con il valore pi \label{tab:file_open_flags} \end{table} -\footnotetext[4]{il problema è che NFS non supporta la scrittura in append, ed - il kernel deve simularla, ma questo comporta la possibilità di una race - condition, vedi sez.~\ref{sec:file_atomic}.} +\footnotetext[4]{il problema è che NFS non supporta la scrittura in + \itindex{append~mode} \textit{append}, ed il kernel deve simularla, ma + questo comporta la possibilità di una \itindex{race~condition} \textit{race + condition}, vedi sez.~\ref{sec:file_atomic}.} \footnotetext[5]{l'opzione origina da SVr4, dove però causava il ritorno da una \func{read} con un valore nullo e non con un errore, questo introduce @@ -493,9 +495,10 @@ positivo come numero di byte dall'inizio del file. Tutte le operazioni di lettura e scrittura avvengono a partire da questa posizione che viene automaticamente spostata in avanti del numero di byte letti o scritti. -In genere (a meno di non avere richiesto la modalità \const{O\_APPEND}) questa -posizione viene impostata a zero all'apertura del file. È possibile impostarla -ad un valore qualsiasi con la funzione \funcd{lseek}, il cui prototipo è: +In genere (a meno di non avere richiesto la modalità \itindex{append~mode} +\const{O\_APPEND}) questa posizione viene impostata a zero all'apertura del +file. È possibile impostarla ad un valore qualsiasi con la funzione +\funcd{lseek}, il cui prototipo è: \begin{functions} \headdecl{sys/types.h} \headdecl{unistd.h} @@ -708,11 +711,11 @@ scrivere su di esso utilizzando la funzione \funcd{write}, il cui prototipo Come nel caso di \func{read} la funzione tenta di scrivere \param{count} byte a partire dalla posizione corrente nel file e sposta automaticamente la posizione in avanti del numero di byte scritti. Se il file è aperto in -modalità \const{O\_APPEND} i dati vengono sempre scritti alla fine del file. -Lo standard POSIX richiede che i dati scritti siano immediatamente disponibili -ad una \func{read} chiamata dopo che la \func{write} che li ha scritti è -ritornata; ma dati i meccanismi di caching non è detto che tutti i filesystem -supportino questa capacità. +modalità \itindex{append~mode} \const{O\_APPEND} i dati vengono sempre scritti +alla fine del file. Lo standard POSIX richiede che i dati scritti siano +immediatamente disponibili ad una \func{read} chiamata dopo che la +\func{write} che li ha scritti è ritornata; ma dati i meccanismi di caching +non è detto che tutti i filesystem supportino questa capacità. Se \param{count} è zero la funzione restituisce zero senza fare nient'altro. Per i file ordinari il numero di byte scritti è sempre uguale a quello @@ -781,10 +784,11 @@ stesso file, in particolare occorre tenere presente che: scrittura eccede la dimensione corrente del file questo verrà esteso automaticamente con l'aggiornamento del campo \var{i\_size} nell'inode\index{inode}. -\item se un file è in modalità \const{O\_APPEND} tutte le volte che viene - effettuata una scrittura la posizione corrente viene prima impostata alla - dimensione corrente del file letta dall'inode\index{inode}. Dopo la - scrittura il file viene automaticamente esteso. +\item se un file è in modalità \itindex{append~mode} \const{O\_APPEND} tutte + le volte che viene effettuata una scrittura la posizione corrente viene + prima impostata alla dimensione corrente del file letta + dall'inode\index{inode}. Dopo la scrittura il file viene automaticamente + esteso. \item l'effetto di \func{lseek} è solo quello di cambiare il campo \var{f\_pos} nella struttura \struct{file} della \textit{file table}, non c'è nessuna operazione sul file su disco. Quando la si usa per porsi alla @@ -855,11 +859,12 @@ ma il nostro primo processo avr Il problema è che usare due system call in successione non è un'operazione atomica; il problema è stato risolto introducendo la modalità -\const{O\_APPEND}. In questo caso infatti, come abbiamo descritto in -precedenza, è il kernel che aggiorna automaticamente la posizione alla fine -del file prima di effettuare la scrittura, e poi estende il file. Tutto questo -avviene all'interno di una singola system call (la \func{write}) che non -essendo interrompibile da un altro processo costituisce un'operazione atomica. +\itindex{append~mode} \const{O\_APPEND}. In questo caso infatti, come abbiamo +descritto in precedenza, è il kernel che aggiorna automaticamente la posizione +alla fine del file prima di effettuare la scrittura, e poi estende il file. +Tutto questo avviene all'interno di una singola system call (la \func{write}) +che non essendo interrompibile da un altro processo costituisce un'operazione +atomica. Un altro caso tipico in cui è necessaria l'atomicità è quello in cui si vuole creare un \textsl{file di lock}\index{file!di lock}, bloccandosi se il file diff --git a/ipc.tex b/ipc.tex index 452962b..49d3338 100644 --- a/ipc.tex +++ b/ipc.tex @@ -2506,10 +2506,10 @@ corrispondente comportamento della funzione, sono i seguenti: \var{shm\_perm.uid} e \var{shm\_perm.gid} occorre essere il proprietario o il creatore del segmento, oppure l'amministratore. Compiuta l'operazione aggiorna anche il valore del campo \var{shm\_ctime}. -\item[\const{SHM\_LOCK}] Abilita il \textit{memory locking} - \itindex{memory~locking}\footnote{impedisce cioè che la memoria usata per il - segmento venga salvata su disco dal meccanismo della memoria - virtuale\index{memoria~virtuale}; si ricordi quanto trattato in +\item[\const{SHM\_LOCK}] Abilita il \itindex{memory~locking} \textit{memory + locking}\footnote{impedisce cioè che la memoria usata per il segmento + venga salvata su disco dal meccanismo della \index{memoria~virtuale} + memoria virtuale; si ricordi quanto trattato in sez.~\ref{sec:proc_mem_lock}.} sul segmento di memoria condivisa. Solo l'amministratore può utilizzare questo comando. \item[\const{SHM\_UNLOCK}] Disabilita il \textit{memory locking} @@ -2519,7 +2519,7 @@ corrispondente comportamento della funzione, sono i seguenti: i primi tre comandi sono gli stessi già visti anche per le code di messaggi e gli insiemi di semafori, gli ultimi due sono delle estensioni specifiche previste da Linux, che permettono di abilitare e disabilitare il meccanismo -della memoria virtuale\index{memoria~virtuale} per il segmento. +della memoria virtuale \index{memoria~virtuale} per il segmento. L'argomento \param{buf} viene utilizzato solo con i comandi \const{IPC\_STAT} e \const{IPC\_SET} nel qual caso esso dovrà puntare ad una struttura diff --git a/prochand.tex b/prochand.tex index 5048c7d..45b4282 100644 --- a/prochand.tex +++ b/prochand.tex @@ -1993,8 +1993,9 @@ implementata.\footnote{per attualmente si intende fino al kernel 2.6.13, e chiamante ha nel suo insieme di capacità permesse) da qualunque processo.\\ \const{CAP\_LINUX\_IMMUTABLE}& la capacità di impostare gli attributi - \textit{immutable} e \textit{append only} per i - file su un filesystem che supporta questi + \textit{immutable} e \itindex{append~mode} + \textit{append only} per i file su un + filesystem che supporta questi attributi estesi.\\ \const{CAP\_NET\_BIND\_SERVICE}& la capacità di porre in ascolto server su porte riservate (vedi diff --git a/system.tex b/system.tex index ee6a624..5ba240a 100644 --- a/system.tex +++ b/system.tex @@ -765,25 +765,26 @@ valori riportati in tab.~\ref{tab:sys_mount_flags}. \textbf{Parametro} & \textbf{Valore}&\textbf{Significato}\\ \hline \hline - \const{MS\_RDONLY} & 1 & monta in sola lettura\\ + \const{MS\_RDONLY} & 1 & monta in sola lettura.\\ \const{MS\_NOSUID} & 2 & ignora i bit \itindex{suid~bit} \acr{suid} e - \itindex{sgid~bit}\acr{sgid}\\ - \const{MS\_NODEV} & 4 & impedisce l'accesso ai file di dispositivo\\ - \const{MS\_NOEXEC} & 8 & impedisce di eseguire programmi \\ - \const{MS\_SYNCHRONOUS}& 16 & abilita la scrittura sincrona \\ - \const{MS\_REMOUNT} & 32 & rimonta il filesystem cambiando i flag\\ + \itindex{sgid~bit}\acr{sgid}.\\ + \const{MS\_NODEV} & 4 & impedisce l'accesso ai file di dispositivo.\\ + \const{MS\_NOEXEC} & 8 & impedisce di eseguire programmi.\\ + \const{MS\_SYNCHRONOUS}& 16 & abilita la scrittura sincrona.\\ + \const{MS\_REMOUNT} & 32 & rimonta il filesystem cambiando i flag.\\ \const{MS\_MANDLOCK} & 64 & consente il \textit{mandatory locking} (vedi - sez.~\ref{sec:file_mand_locking})\\ - \const{S\_WRITE} & 128 & scrive normalmente \\ - \const{S\_APPEND} & 256 & consente la scrittura solo in \textit{append - mode} (vedi sez.~\ref{sec:file_sharing})\\ - \const{S\_IMMUTABLE} & 512 & impedisce che si possano modificare i file \\ + sez.~\ref{sec:file_mand_locking}).\\ + \const{S\_WRITE} & 128 & scrive normalmente.\\ + \const{S\_APPEND} & 256 & consente la scrittura solo in + \itindex{append~mode} \textit{append mode} + (vedi sez.~\ref{sec:file_sharing}).\\ + \const{S\_IMMUTABLE} & 512 & impedisce che si possano modificare i file.\\ \const{MS\_NOATIME} &1024 & non aggiorna gli \textit{access time} (vedi - sez.~\ref{sec:file_file_times})\\ + sez.~\ref{sec:file_file_times}).\\ \const{MS\_NODIRATIME}&2048 & non aggiorna gli \textit{access time} delle - directory\\ - \const{MS\_BIND} &4096 & monta il filesystem altrove\\ - \const{MS\_MOVE} &8192 & sposta atomicamente il punto di montaggio \\ + directory.\\ + \const{MS\_BIND} &4096 & monta il filesystem altrove.\\ + \const{MS\_MOVE} &8192 & sposta atomicamente il punto di montaggio.\\ \hline \end{tabular} \caption{Tabella dei codici dei flag di montaggio di un filesystem.} @@ -1748,10 +1749,10 @@ semplice esempio per l'uso di questa funzione Quando si attiva la contabilità, il file che si indica deve esistere; esso verrà aperto in sola scrittura;\footnote{si applicano al pathname indicato da \param{filename} tutte le restrizioni viste in cap.~\ref{cha:file_intro}.} -le informazioni verranno registrate in \textit{append} in coda al file tutte -le volte che un processo termina. Le informazioni vengono salvate in formato -binario, e corrispondono al contenuto della apposita struttura dati definita -all'interno del kernel. +le informazioni verranno registrate in \itindex{append~mode} \textit{append} +in coda al file tutte le volte che un processo termina. Le informazioni +vengono salvate in formato binario, e corrispondono al contenuto della +apposita struttura dati definita all'interno del kernel. Il funzionamento di \func{acct} viene inoltre modificato da uno specifico parametro di sistema, modificabile attraverso \file{/proc/sys/kernel/acct} (o @@ -2252,7 +2253,7 @@ e impostano anche la variabile \var{tzname} con l'informazione della \textit{time zone} corrente; \func{ctime} è banalmente definita in termini di \func{asctime} come \code{asctime(localtime(t)}. Dato che l'uso di una stringa statica rende le funzioni non rientranti POSIX.1c e SUSv2 prevedono due -sostitute rientranti, il cui nome è al solito ottenuto appendendo un +sostitute rientranti, il cui nome è al solito ottenuto aggiungendo un \code{\_r}, che prendono un secondo argomento \code{char *buf}, in cui l'utente deve specificare il buffer su cui la stringa deve essere copiata (deve essere di almeno 26 caratteri). diff --git a/tcpsock.tex b/tcpsock.tex index a129fce..31667f1 100644 --- a/tcpsock.tex +++ b/tcpsock.tex @@ -373,7 +373,7 @@ fig.~\ref{fig:TCP_conn_example}: assumendo che l'ultimo ACK della sequenza (quello del capo che ha eseguito la chiusura attiva) venga perso, chi esegue la chiusura passiva non ricevendo risposta rimanderà un ulteriore FIN, per questo motivo chi esegue la chiusura attiva deve mantenere lo stato della -connessione per essere in grado di rinviare l'ACK e chiuderla correttamente. +connessione per essere in grado di reinviare l'ACK e chiuderla correttamente. Se non fosse così la risposta sarebbe un RST (un altro tipo si segmento) che verrebbe interpretato come un errore. @@ -913,9 +913,10 @@ infatti vengono mantenute due code: handshake} non si è ancora concluso. Questi socket sono tutti nello stato \texttt{SYN\_RECV}. \item La coda delle connessioni complete (\textit{complete connection queue} - che contiene un ingresso per ciascun socket per il quale il \textit{three - way handshake} è stato completato ma ancora \func{accept} non è ritornata. - Questi socket sono tutti nello stato \texttt{ESTABLISHED}. + che contiene un ingresso per ciascun socket per il quale il + \itindex{three~way~handshake} \textit{three way handshake} è stato + completato ma ancora \func{accept} non è ritornata. Questi socket sono + tutti nello stato \texttt{ESTABLISHED}. \end{enumerate} Lo schema di funzionamento è descritto in fig.~\ref{fig:TCP_listen_backlog}: @@ -923,7 +924,7 @@ quando arriva un SYN da un client il server crea una nuova voce nella coda delle connessioni incomplete, e poi risponde con il SYN$+$ACK. La voce resterà nella coda delle connessioni incomplete fino al ricevimento dell'ACK dal client o fino ad un timeout. Nel caso di completamento del -\itindex{three~way~handshake}\textit{three way handshake} la voce viene +\itindex{three~way~handshake} \textit{three way handshake} la voce viene spostata nella coda delle connessioni complete. Quando il processo chiama la funzione \func{accept} (vedi sez.~\ref{sec:TCP_func_accept}) la prima voce nella coda delle connessioni complete è passata al programma, o, se la coda è @@ -980,7 +981,7 @@ che il compito principale della coda sia quello di gestire il caso in cui il server è occupato fra chiamate successive alla \func{accept} (per cui la coda più occupata sarebbe quella delle connessioni completate), ma piuttosto quello di gestire la presenza di un gran numero di SYN in attesa di concludere il -\textit{three way handshake}\itindex{three~way~handshake}. +\itindex{three~way~handshake} \textit{three way handshake}. Infine va messo in evidenza che, nel caso di socket TCP, quando un SYN arriva con tutte le code piene, il pacchetto deve essere ignorato. Questo perché la @@ -1917,10 +1918,11 @@ A questo punto si pu \textit{three way handshake} la connessione è stabilita; la \func{connect} ritornerà nel client\footnote{si noti che è sempre la \func{connect} del client a ritornare per prima, in quanto questo avviene alla ricezione del - secondo segmento (l'ACK del server) del \textit{three way handshake}, la - \func{accept} del server ritorna solo dopo un altro mezzo RTT quando il - terzo segmento (l'ACK del client) viene ricevuto.} e la \func{accept} nel -server, ed usando di nuovo \cmd{netstat} otterremmo che: + secondo segmento (l'ACK del server) del \itindex{three~way~handshake} + \textit{three way handshake}, la \func{accept} del server ritorna solo dopo + un altro mezzo RTT quando il terzo segmento (l'ACK del client) viene + ricevuto.} e la \func{accept} nel server, ed usando di nuovo \cmd{netstat} +otterremmo che: \begin{verbatim} Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State @@ -2264,7 +2266,7 @@ Bench con dei server molto occupati. In tal caso, con una struttura del server simile a quella del nostro esempio, in cui la gestione delle singole connessioni è demandata a processi figli, può accadere che il \textit{three - way handshake}\itindex{three~way~handshake} venga completato e la relativa + way handshake} \itindex{three~way~handshake} venga completato e la relativa connessione abortita subito dopo, prima che il padre, per via del carico della macchina, abbia fatto in tempo ad eseguire la chiamata ad \func{accept}. Di nuovo si ha una situazione analoga a quella illustrata in @@ -2374,23 +2376,23 @@ anarres.echo > gont.34559: R 511689732:511689732(0) win 0 \end{verbatim} Le prime tre righe vengono prodotte al momento in cui lanciamo il nostro -client, e corrispondono ai tre pacchetti del -\itindex{three~way~handshake}\textit{three way handshake}. L'output del -comando riporta anche i numeri di sequenza iniziali, mentre la lettera -\texttt{S} indica che per quel pacchetto si aveva il SYN flag attivo. Si noti -come a partire dal secondo pacchetto sia sempre attivo il campo \texttt{ack}, -seguito dal numero di sequenza per il quale si da il ricevuto; quest'ultimo, a -partire dal terzo pacchetto, viene espresso in forma relativa per maggiore -compattezza. Il campo \texttt{win} in ogni riga indica la \textit{advertising - window} di cui parlavamo in sez.~\ref{sec:TCP_TCP_opt}. Allora si può -verificare dall'output del comando come venga appunto realizzata la sequenza -di pacchetti descritta in sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal -client un primo pacchetto con il SYN che inizia la connessione, a cui il -server risponde dando il ricevuto con un secondo pacchetto, che a sua volta -porta un SYN, cui il client risponde con un il terzo pacchetto di ricevuto. +client, e corrispondono ai tre pacchetti del \itindex{three~way~handshake} +\textit{three way handshake}. L'output del comando riporta anche i numeri di +sequenza iniziali, mentre la lettera \texttt{S} indica che per quel pacchetto +si aveva il SYN flag attivo. Si noti come a partire dal secondo pacchetto sia +sempre attivo il campo \texttt{ack}, seguito dal numero di sequenza per il +quale si da il ricevuto; quest'ultimo, a partire dal terzo pacchetto, viene +espresso in forma relativa per maggiore compattezza. Il campo \texttt{win} in +ogni riga indica la \textit{advertising window} di cui parlavamo in +sez.~\ref{sec:TCP_TCP_opt}. Allora si può verificare dall'output del comando +come venga appunto realizzata la sequenza di pacchetti descritta in +sez.~\ref{sec:TCP_conn_cre}: prima viene inviato dal client un primo pacchetto +con il SYN che inizia la connessione, a cui il server risponde dando il +ricevuto con un secondo pacchetto, che a sua volta porta un SYN, cui il client +risponde con un il terzo pacchetto di ricevuto. Ritorniamo allora alla nostra sessione con il servizio echo: dopo le tre righe -del \textit{three way handshake}\itindex{three~way~handshake} non avremo nulla +del \textit{three way handshake} \itindex{three~way~handshake} non avremo nulla fin tanto che non scriveremo una prima riga sul client; al momento in cui facciamo questo si genera una sequenza di altri quattro pacchetti. Il primo, dal client al server, contraddistinto da una lettera \texttt{P} che significa