Correzioni varie, la task struct aggiornata per il 2.6 riguardo le
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 20 Jun 2009 14:57:25 +0000 (14:57 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 20 Jun 2009 14:57:25 +0000 (14:57 +0000)
priorita', aggiornate le spiegazioni su tempi dei file e di relatime,
inizio di documentazione di utimes.

filedir.tex
img/task_struct.dia
prochand.tex
system.tex

index eca8d1d3be2bbdadad35813fb41b710432826314..7c9beee7b8d4bc6fbfed0ddcee71f2a975d418b8 100644 (file)
@@ -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
 \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
 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.
 
 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
 
 \begin{table}[htb]
   \centering
@@ -1861,21 +1899,6 @@ articoli sulla base di questo tempo).
   \label{tab:file_times_effects}  
 \end{table}
 
   \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
 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.
 
 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)} 
 
 \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
 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.
 
 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
 
 
 %TODO documentare utimes
 
index 585939016fe6e04fc7d4fd41a53081e0820d87f4..8fcdf23d02ea54cbd5b7d811c69fe47f334e6451 100644 (file)
Binary files a/img/task_struct.dia and b/img/task_struct.dia differ
index 6b527b79dfce74df87f8e315c2f416ad71ec95eb..3693f9186eafdf8b12df0eba71943a2cfb61b2ca 100644 (file)
@@ -742,8 +742,6 @@ che sia cos
 terminato; si potrebbe avere cioè quello che si chiama un processo
 \textsl{orfano}. 
 
 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
 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.
 
 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}
 
 \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ò
                                     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
     \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}
 
   \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
 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
index e77104ef59fa1092726f33493c0d571428dd850f..e69639be2fae01f47e4ee8ea13a34a865f5b15e6 100644 (file)
@@ -1420,7 +1420,7 @@ In genere includere esplicitamente \file{<sys/time.h>} 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
 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
 
 Questa è la stessa struttura utilizzata da \func{wait4} (si ricordi quando
 visto in sez.~\ref{sec:proc_wait}) per ricavare la quantità di risorse