From: Simone Piccardi Date: Sat, 20 Jun 2009 14:57:25 +0000 (+0000) Subject: Correzioni varie, la task struct aggiornata per il 2.6 riguardo le X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=46f04a7875f34640b75aab2d5163ea86afe1bf71;p=gapil.git Correzioni varie, la task struct aggiornata per il 2.6 riguardo le priorita', aggiornate le spiegazioni su tempi dei file e di relatime, inizio di documentazione di utimes. --- diff --git a/filedir.tex b/filedir.tex index eca8d1d..7c9beee 100644 --- a/filedir.tex +++ b/filedir.tex @@ -1765,8 +1765,8 @@ riportato un esempio delle funzioni che effettuano cambiamenti su di essi. \end{table} Il primo punto da tenere presente è la differenza fra il cosiddetto tempo di -modifica (il \textit{modification time} \var{st\_mtime}) e il tempo di -cambiamento di stato (il \textit{change time} \var{st\_ctime}). Il primo +modifica (il \textit{modification time}, \var{st\_mtime}) e il tempo di +cambiamento di stato (il \textit{change time}, \var{st\_ctime}). Il primo infatti fa riferimento ad una modifica del contenuto di un file, mentre il secondo ad una modifica \itindex{inode} dell'\textit{inode}; siccome esistono molte operazioni (come la funzione \func{link} e molte altre che vedremo in @@ -1774,12 +1774,50 @@ seguito) che modificano solo le informazioni contenute \itindex{inode} nell'\textit{inode} senza toccare il contenuto del file, diventa necessario l'utilizzo di un altro tempo. -Il sistema non tiene conto dell'ultimo accesso \itindex{inode} -all'\textit{inode}, pertanto funzioni come \func{access} o \func{stat} non -hanno alcuna influenza sui tre tempi. Il tempo di ultimo accesso (ai dati) -viene di solito usato per cancellare i file che non servono più dopo un certo -lasso di tempo (ad esempio il programma \cmd{leafnode} cancella i vecchi -articoli sulla base di questo tempo). +Il tempo di ultima modifica viene usato ad esempio da programmi come +\cmd{make} per decidere quali file necessitano di essere ricompilati o +(talvolta insieme anche al tempo di cambiamento di stato) per decidere quali +file devono essere archiviati per il backup. Il tempo di ultimo accesso viene +di solito usato per identificare i file che non vengono più utilizzati per un +certo lasso di tempo. Ad esempio un programma come \texttt{leafnode} lo usa +per cancellare gli articoli letti più vecchi, mentre \texttt{mutt} lo usa per +marcare i messaggi di posta che risultano letti. Il sistema non tiene conto +dell'ultimo accesso \itindex{inode} all'\textit{inode}, pertanto funzioni come +\func{access} o \func{stat} non hanno alcuna influenza sui tre tempi. Il +comando \cmd{ls} (quando usato con le opzioni \cmd{-l} o \cmd{-t}) mostra i +tempi dei file secondo lo schema riportato nell'ultima colonna di +tab.~\ref{tab:file_file_times}. + +L'aggiornamento del tempo di ultimo accesso è stato a lungo considerato un +difetto progettuale di Unix, questo infatti comporta la necessità di +effettuare un accesso in scrittura sul disco anche in tutti i casi in cui +questa informazione non interessa e sarebbe possibile avere un semplice +accesso in lettura sui dati bufferizzati. Questo comporta un ovvio costo sia +in termini di prestazioni, che di consumo di risorse come la batteria per i +portatili, o cicli di riscrittura per i dischi su memorie riscrivibili. + +Per questo motivo, onde evitare di mantenere una informazione che nella +maggior parte dei casi non interessa, è sempre stato possibile disabilitare +l'aggiornamento del tempo di ultimo accesso con l'opzione di montaggio +\texttt{noatime}. Dato però che questo può creare problemi a qualche +programma, in Linux è stata introdotta la opzione \texttt{relatime} che esegue +l'aggiornamnto soltanto se il tempo di ultimo accesso è precedente al tempo di +ultima modifica o cambiamneto, così da rendere evidente che vi è stato un +accesso dopo la scrittura, ed evitando al contempo ulteriori operazioni su +disco negli accessi successivi. In questo modo l'informazione relativa al +fatto che un file sia stato letto resta disponibile, e ad esempio i programmi +citati in precedenza continuano a funzionare. Questa opzione, a partire dal +kernel 2.6.30, è diventata il comportamento di default e non deve più essere +specificata esplicitamente.\footnote{si può comunque riottere il vecchio + comportamento usando la opzione di montaggio \texttt{strictatime}.} + +L'effetto delle varie funzioni di manipolazione dei file sui relativi tempi è +illustrato in tab.~\ref{tab:file_times_effects}, facendo riferimento al +comportamento classico per quanto riguarda \var{st\_atime}. Si sono riportati +gli effetti sia per il file a cui si fa riferimento, sia per la directory che +lo contiene; questi ultimi possono essere capiti se si tiene conto di quanto +già detto, e cioè che anche le directory sono file (che contengono una lista +di nomi) che il sistema tratta in maniera del tutto analoga a tutti gli altri. \begin{table}[htb] \centering @@ -1861,21 +1899,6 @@ articoli sulla base di questo tempo). \label{tab:file_times_effects} \end{table} - -Il tempo di ultima modifica invece viene usato da \cmd{make} per decidere -quali file necessitano di essere ricompilati o (talvolta insieme anche al -tempo di cambiamento di stato) per decidere quali file devono essere -archiviati per il backup. Il comando \cmd{ls} (quando usato con le opzioni -\cmd{-l} o \cmd{-t}) mostra i tempi dei file secondo lo schema riportato -nell'ultima colonna di tab.~\ref{tab:file_file_times}. - -L'effetto delle varie funzioni di manipolazione dei file sui tempi è -illustrato in tab.~\ref{tab:file_times_effects}. Si sono riportati gli effetti -sia per il file a cui si fa riferimento, sia per la directory che lo contiene; -questi ultimi possono essere capiti se si tiene conto di quanto già detto, e -cioè che anche le directory sono file (che contengono una lista di nomi) che -il sistema tratta in maniera del tutto analoga a tutti gli altri. - Per questo motivo tutte le volte che compiremo un'operazione su un file che comporta una modifica del nome contenuto nella directory, andremo anche a scrivere sulla directory che lo contiene cambiandone il tempo di modifica. Un @@ -1889,8 +1912,8 @@ esiste. Per questo motivo quando si copia un file, a meno di preservare esplicitamente i tempi (ad esempio con l'opzione \cmd{-p} di \cmd{cp}) esso avrà sempre il tempo corrente come data di ultima modifica. -I tempi di ultimo accesso e modifica possono essere cambiati usando la -funzione \funcd{utime}, il cui prototipo è: +I tempi di ultimo accesso e modifica possono essere modificati esplicitamente +usando la funzione \funcd{utime}, il cui prototipo è: \begin{prototype}{utime.h} {int utime(const char *filename, struct utimbuf *times)} @@ -1934,20 +1957,42 @@ cambiamento di stato del file, che viene comunque cambiato dal kernel tutte le volte che si modifica \itindex{inode} l'\textit{inode} (quindi anche alla chiamata di \func{utime}). Questo serve anche come misura di sicurezza per evitare che si possa modificare un file nascondendo completamente le proprie -tracce. In realtà la cosa resta possibile, se si è in grado di accedere al +tracce. In realtà la cosa resta possibile, se si è in grado di accedere al file di dispositivo, scrivendo direttamente sul disco senza passare attraverso il filesystem, ma ovviamente in questo modo la cosa è molto più complicata da realizzare. -Infine a partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei -campi di tab.~\ref{tab:file_file_times} è espressa in secondi, è stata -portata ai nanosecondi per la gran parte dei filesystem. La ulteriore -informazione può essere acceduta attraverso altri campi; se si sono definite -le macro \macro{\_BSD\_SOURCE} o \macro{\_SVID\_SOURCE} questi sono -\var{st\_atim.tv\_nsec}, \var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se -queste non sono definite, \var{st\_atimensec}, \var{st\_mtimensec} e -\var{st\_mtimensec}. Qualora il supporto per questa maggior precisione sia -assente questi campi aggiuntivi saranno nulli. +A partire dal kernel 2.6 la risoluzione dei tempi dei file, che nei campi di +tab.~\ref{tab:file_file_times} è espressa in secondi, è stata portata ai +nanosecondi per la gran parte dei filesystem. La ulteriore informazione può +essere acceduta attraverso altri campi appositamente aggiunti alla struttura +\struct{stat}. Se si sono definite le macro \macro{\_BSD\_SOURCE} o +\macro{\_SVID\_SOURCE} questi sono \var{st\_atim.tv\_nsec}, +\var{st\_mtim.tv\_nsec} e \var{st\_ctim.tv\_nsec} se queste non sono definite, +\var{st\_atimensec}, \var{st\_mtimensec} e \var{st\_mtimensec}. Qualora il +supporto per questa maggior precisione sia assente questi campi aggiuntivi +saranno nulli. + +Per la gestione di questi nuovi valori è stata definita una seconda funzione +di modifica, \funcd{utimes}, che consente di specificare tempi con maggior +precisione; il suo prototipo è: +\begin{prototype}{utime.h} +{int utimes(const char *filename, struct timeval times[2])} + +Cambia i tempi di ultimo accesso e modifica \itindex{inode} +dell'\textit{inode} specificato da \param{filename} secondo i valori +specificati da \param{times}. Se questo è \val{NULL} allora viene usato il +tempo corrente. + +\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{EACCES}] non si ha il permesso di scrittura sul file. + \item[\errcode{ENOENT}] \param{filename} non esiste. + \end{errlist}} +\end{prototype} + +La funzione usa %TODO documentare utimes diff --git a/img/task_struct.dia b/img/task_struct.dia index 5859390..8fcdf23 100644 Binary files a/img/task_struct.dia and b/img/task_struct.dia differ diff --git a/prochand.tex b/prochand.tex index 6b527b7..3693f91 100644 --- a/prochand.tex +++ b/prochand.tex @@ -742,8 +742,6 @@ che sia cos terminato; si potrebbe avere cioè quello che si chiama un processo \textsl{orfano}. -% TODO verificare il reparenting - Questa complicazione viene superata facendo in modo che il processo orfano venga \textsl{adottato} da \cmd{init}. Come già accennato quando un processo termina, il kernel controlla se è il padre di altri processi in esecuzione: in @@ -2096,8 +2094,6 @@ attivi. In particolare prenderemo in esame i vari meccanismi con cui viene gestita l'assegnazione del tempo di CPU, ed illustreremo le varie funzioni di gestione. -% TODO: rivedere alla luce degli aggiornamenti del 2.6 (man sched_setscheduler) - \subsection{I meccanismi di \textit{scheduling}} \label{sec:proc_sched} @@ -2172,7 +2168,8 @@ fintanto che esso si trova in uno qualunque degli altri stati. 2.6.25, sostanzialmente identico all'\textbf{Uninterrutible Sleep} con la sola differenza che il processo può - terminato (con \const{SIGKILL}).\\ + terminato con \const{SIGKILL} (usato per + lo più per NFS).\\ \hline \end{tabular} \caption{Elenco dei possibili stati di un processo in Linux, nella colonna @@ -2181,8 +2178,6 @@ fintanto che esso si trova in uno qualunque degli altri stati. \label{tab:proc_proc_states} \end{table} -% TODO nel 2.6.25 è stato aggiunto TASK_KILLABLE, da capire dova va messo. - Si deve quindi tenere presente che l'utilizzo della CPU è soltanto una delle risorse che sono necessarie per l'esecuzione di un programma, e a seconda dello scopo del programma non è detto neanche che sia la più importante (molti diff --git a/system.tex b/system.tex index e77104e..e69639b 100644 --- a/system.tex +++ b/system.tex @@ -1420,7 +1420,7 @@ In genere includere esplicitamente \file{} non necessario, ma aumenta la portabilità, e serve comunque quando, come nella maggior parte dei casi, si debba accedere ai campi di \struct{rusage} relativi ai tempi di utilizzo del processore, che sono definiti come strutture di tipo -\struct{timeval}. +\struct{timeval} (vedi fig.~\ref{fig:sys_timeval_struct}). Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse