Piccole correzioni e aggiornamenti.

diff --git a/filedir.tex b/filedir.tex
index b1f8e7615086434a0acb31c9ba9073c20c879594..e14c105d31f6e07a39d8d7bac9efe5a3b44b8d81 100644 (file)
--- a/filedir.tex
+++ b/filedir.tex
@@ -2648,9 +2648,10 @@ a scongiurare l'abuso dei \itindex{suid~bit} bit \acr{suid} e \acr{sgid}; essa
 consiste nel cancellare automaticamente questi bit dai permessi di un file
 qualora un processo che non appartenga all'amministratore\footnote{per la
   precisione un processo che non dispone della \itindex{capabilities} capacità
 consiste nel cancellare automaticamente questi bit dai permessi di un file
 qualora un processo che non appartenga all'amministratore\footnote{per la
   precisione un processo che non dispone della \itindex{capabilities} capacità

-  \const{CAP\_FSETID}.} effettui una scrittura. In questo modo anche se un
-utente malizioso scopre un file \acr{suid} su cui può scrivere, un'eventuale
-modifica comporterà la perdita di questo privilegio.
+  \const{CAP\_FSETID}, vedi sez.~\ref{sec:proc_capabilities}.} effettui una
+scrittura. In questo modo anche se un utente malizioso scopre un file
+\acr{suid} su cui può scrivere, un'eventuale modifica comporterà la perdita di
+questo privilegio.

 
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati
 
 Le funzioni \func{chmod} e \func{fchmod} ci permettono di modificare i
 permessi di un file, resta però il problema di quali sono i permessi assegnati


@@ -2942,7 +2943,7 @@ un insieme di \textsl{capacit
 potessero essere abilitate e disabilitate in maniera indipendente per ciascun
 processo con privilegi di amministratore, permettendo così una granularità
 molto più fine nella distribuzione degli stessi che evitasse la originaria
 potessero essere abilitate e disabilitate in maniera indipendente per ciascun
 processo con privilegi di amministratore, permettendo così una granularità
 molto più fine nella distribuzione degli stessi che evitasse la originaria

-situazione di \textsl{tutto o nulla}.
+situazione di ``\textsl{tutto o nulla}''.

 
 Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
   si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,
 
 Il meccanismo completo delle \textit{capabilities}\footnote{l'implementazione
   si rifà ad una bozza di quello che doveva diventare lo standard POSIX.1e,

diff --git a/fileintro.tex b/fileintro.tex
index 4bcbd4209fc9e40fbf62d646f2c8a8bbd08152ad..0048b3b67473735040a5c6086ff501186d6465a8 100644 (file)
--- a/fileintro.tex
+++ b/fileintro.tex
@@ -68,7 +68,7 @@ viene identificato dall'utente usando quello che viene chiamato
   ormai così comune che mantenerne l'uso è senz'altro più chiaro
   dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
 al file a partire dalla \textit{root directory}, che è composto da una serie
   ormai così comune che mantenerne l'uso è senz'altro più chiaro
   dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
 al file a partire dalla \textit{root directory}, che è composto da una serie

-di nomi separati da una \file{/}.
+di nomi separati da una ``\file{/}''.

 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 riceve dal bootloader l'indicazione di quale dispositivo contiene il
 
 All'avvio del sistema, completata la fase di inizializzazione, il kernel
 riceve dal bootloader l'indicazione di quale dispositivo contiene il


@@ -103,21 +103,21 @@ convenzione, sono inseriti nella directory \file{/dev}).
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 risoluzione del nome (\textit{filename resolution} o \textit{pathname
 Il nome completo di un file viene chiamato \textit{pathname} ed il
 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
 risoluzione del nome (\textit{filename resolution} o \textit{pathname

-resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
+  resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da

 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
 sinistra a destra e localizzando ogni nome nella directory indicata dal nome

-precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto,
-il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
-perché il procedimento funzioni, occorre che i nomi indicati come directory
-esistano e siano effettivamente directory, inoltre i permessi (si veda
-sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
-\textit{pathname}.
-
-Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla
-directory radice del processo; questa, a meno di un \func{chroot} (su cui
-torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed
-equivale alla directory radice dell'albero dei file: in questo caso si parla
-di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.  Altrimenti la
-ricerca parte dalla directory corrente (su cui torneremo in
+precedente usando il carattere ``\texttt{/}'' come separatore\footnote{nel
+  caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a
+  \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
+indicati come directory esistano e siano effettivamente directory, inoltre i
+permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
+l'accesso all'intero \textit{pathname}.
+
+Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
+parte dalla directory radice del processo; questa, a meno di un \func{chroot}
+(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
+processi ed equivale alla directory radice dell'albero dei file: in questo
+caso si parla di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.
+Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in

 sez.~\ref{sec:file_work_dir}) ed il pathname è detto
 \itindsub{pathname}{relativo} \textsl{pathname relativo}.
 
 sez.~\ref{sec:file_work_dir}) ed il pathname è detto
 \itindsub{pathname}{relativo} \textsl{pathname relativo}.
 


@@ -126,7 +126,9 @@ inseriti in ogni directory: il primo fa riferimento alla directory corrente e
 il secondo alla directory \textsl{genitrice} (o \textit{parent directory})
 cioè la directory che contiene il riferimento alla directory corrente; nel
 caso la directory corrente coincida con la directory radice, allora il
 il secondo alla directory \textsl{genitrice} (o \textit{parent directory})
 cioè la directory che contiene il riferimento alla directory corrente; nel
 caso la directory corrente coincida con la directory radice, allora il

-riferimento è a se stessa.  \itindend{pathname}
+riferimento è a se stessa.  
+
+\itindend{pathname}

 
 
 \subsection{I tipi di file}
 
 
 \subsection{I tipi di file}


@@ -201,33 +203,35 @@ VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione
   \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
   fare con tutto ciò, di effettuare, attraverso degli appositi
   \index{file!di~dispositivo} file di dispositivo, operazioni di I/O
   \textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
   fare con tutto ciò, di effettuare, attraverso degli appositi
   \index{file!di~dispositivo} file di dispositivo, operazioni di I/O

-  direttamente sui dischi senza passare attraverso un filesystem (il
-  cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x).}
-
-Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
-codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
-il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
-del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
-  dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
-  conversione fra questi due formati di testo.} Questo può causare alcuni
-problemi qualora nei programmi si facciano assunzioni sul terminatore della
-riga.
+  direttamente sui dischi senza passare attraverso un filesystem, il
+  cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ed
+  in sostanziale disuso.}
+
+Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
+codificata in maniera diversa da Windows o dal vecchio MacOS, in particolare
+il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
+(\verb|\r|) del vecchio MacOS e del \texttt{CR LF} di Windows.\footnote{per
+  questo esistono in Linux dei programmi come \cmd{unix2dos} e \cmd{dos2unix}
+  che effettuano una conversione fra questi due formati di testo.} Questo può
+causare alcuni problemi qualora nei programmi si facciano assunzioni sul
+terminatore della riga.

 
 Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
 tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
 estensioni come parte del filesystem.\footnote{non è così ad esempio nel
   filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
   che specificano fra l'altro il contenuto ed il programma da usare per
 
 Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
 tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
 estensioni come parte del filesystem.\footnote{non è così ad esempio nel
   filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
   che specificano fra l'altro il contenuto ed il programma da usare per

-  leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
-  possibilità di associare delle risorse ai file, ma è una caratteristica
-  tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
-  file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
-convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
-in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
-utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
-che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
-accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
-demandato alle applicazioni stesse.
+  leggerlo. In realtà per alcuni filesystem esiste la possibilità di
+  associare delle risorse ai file con gli \textit{extended attributes} (vedi
+  sez.~\ref{sec:file_xattr}), ma è una caratteristica tutt'ora poco
+  utilizzata, dato che non corrisponde al modello classico dei file in un
+  sistema Unix.} Ciò nonostante molti programmi adottano delle convenzioni per
+i nomi dei file, ad esempio il codice C normalmente si mette in file con
+l'estensione \file{.c}; un'altra tecnica molto usata è quella di utilizzare i
+primi 4 byte del file per memorizzare un \textit{magic number} che classifichi
+il contenuto; entrambe queste tecniche, per quanto usate ed accettate in
+maniera diffusa, restano solo delle convenzioni il cui rispetto è demandato
+alle applicazioni stesse.

 
 
 \subsection{Le due interfacce ai file}
 
 
 \subsection{Le due interfacce ai file}


@@ -410,8 +414,9 @@ da usare per poterlo manipolare.
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
 stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
 stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento

-viene copiato all'indietro sul disco, gli \index{inode} inode che stanno in
-memoria sono \index{inode} inode del VFS ed è ad essi che puntano le singole
+viene copiato all'indietro sul disco (aggiornando i cosiddetti
+\textsl{metadati} del file), gli \index{inode} inode che stanno in memoria
+sono \index{inode} inode del VFS ed è ad essi che puntano le singole

 \textit{dentry}.
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 \textit{dentry}.
 
 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto


@@ -457,7 +462,8 @@ tab.~\ref{tab:file_file_operations}.
                              sez.~\ref{sec:file_lseek}).\\
     \textsl{\code{ioctl}}  & Accede alle operazioni di controllo 
                              (vedi sez.~\ref{sec:file_ioctl}).\\
                              sez.~\ref{sec:file_lseek}).\\
     \textsl{\code{ioctl}}  & Accede alle operazioni di controllo 
                              (vedi sez.~\ref{sec:file_ioctl}).\\

-    \textsl{\code{readdir}}& Legge il contenuto di una directory.\\
+    \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi 
+                             sez.~\ref{sec:file_dir_read}).\\

     \textsl{\code{poll}}   & Usata nell'I/O multiplexing (vedi
                              sez.~\ref{sec:file_multiplexing}).\\
     \textsl{\code{mmap}}   & Mappa il file in memoria (vedi 
     \textsl{\code{poll}}   & Usata nell'I/O multiplexing (vedi
                              sez.~\ref{sec:file_multiplexing}).\\
     \textsl{\code{mmap}}   & Mappa il file in memoria (vedi 


@@ -483,7 +489,7 @@ tipo di file in questione.
 Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
 normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
 esempio la \code{seek}) non saranno disponibili, però con questo sistema
 Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un
 normale file di dati; ovviamente certe operazioni (nel caso della seriale ad
 esempio la \code{seek}) non saranno disponibili, però con questo sistema

-l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
+l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è

 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 \itindend{Virtual~File~System}
 
 immediato e (relativamente) trasparente per l'utente ed il programmatore.
 \itindend{Virtual~File~System}
 


@@ -543,49 +549,60 @@ particolare 
   
 \item L'\textit{inode} \index{inode} contiene tutte le informazioni
   riguardanti il file: il tipo di file, i permessi di accesso, le dimensioni,
   
 \item L'\textit{inode} \index{inode} contiene tutte le informazioni
   riguardanti il file: il tipo di file, i permessi di accesso, le dimensioni,

-  i puntatori ai blocchi fisici che contengono i dati e così via; le
-  informazioni che la funzione \func{stat} fornisce provengono
-  dall'\textit{inode}; dentro una directory si troverà solo il nome del file e
-  il numero \index{inode} dell'\textit{inode} ad esso associato, cioè quella
-  che da qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
+  i puntatori ai blocchi fisici che contengono i dati e così via, cioè quelli
+  che in genere vengono chiamati i \textsl{metadati} del file; le informazioni
+  che la funzione \func{stat} fornisce provengono dall'\textit{inode}; dentro
+  una directory si troverà solo il nome del file e il numero \index{inode}
+  dell'\textit{inode} ad esso associato, cioè quella che da qui in poi
+  chiameremo una ``\textsl{voce}'', come traduzione dell'inglese

   \textit{directory entry}, che non useremo anche per evitare confusione con
   \textit{directory entry}, che non useremo anche per evitare confusione con

-  le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}).
+  le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}.

   
 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
   
 \item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
   voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un

-  contatore che contiene il numero di riferimenti (\textit{link count}) che
-  sono stati fatti ad esso; solo quando questo contatore si annulla i dati del
-  file vengono effettivamente rimossi dal disco. Per questo la funzione per
-  cancellare un file si chiama \func{unlink}, ed in realtà non cancella
-  affatto i dati del file, ma si limita ad eliminare la relativa voce da una
-  directory e decrementare il numero di riferimenti \index{inode}
+  contatore che contiene il numero di riferimenti che sono stati fatti ad esso
+  (il cosiddetto \textit{link count}); solo quando questo contatore si annulla
+  i dati del file vengono effettivamente rimossi dal disco. Per questo la
+  funzione per cancellare un file si chiama \func{unlink}, ed in realtà non
+  cancella affatto i dati del file, ma si limita ad eliminare la relativa voce
+  da una directory e decrementare il numero di riferimenti \index{inode}

   nell'\textit{inode}.
   
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
   Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
   nell'\textit{inode}.
   
 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
   nello stesso filesystem e non ci può essere una directory che contiene
   riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
   Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un

-  file esistente, con la funzione \func{link}) al filesystem corrente.
+  file esistente con la funzione \func{link}) al filesystem corrente.

   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
   nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la
   vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
   
 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
   del file non viene spostato fisicamente, viene semplicemente creata una
   nuova voce per \index{inode} l'\textit{inode} in questione e rimossa la
   vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}

-  attraverso la funzione \func{rename}).
+  attraverso la funzione \func{rename}). Questa operazione non modifica
+  minimamente neanche l'\textit{inode} del file dato che non si opera su
+  questo ma sulla directory che lo contiene.
+
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
+  blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
+  in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+  possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
+  gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+  spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
+  creare nuovi file, ma si potranno estendere quelli che ci sono.

 
 \end{enumerate}
 
 
 \end{enumerate}
 

-Infine è bene avere presente che, essendo file pure loro, esiste un numero di
-riferimenti anche per le directory; per cui, se a partire dalla situazione
-mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory
-\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+Infine si noti che, essendo file pure loro, il numero di riferimenti esiste
+anche per le directory; per cui, se a partire dalla situazione mostrata in
+fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img}
+nella directory \file{gapil}, avremo una situazione come quella in

 fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
 di \index{inode} inode.
 
 \begin{figure}[htb]
   \centering 
   \includegraphics[width=14cm]{img/dir_links}
 fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
 di \index{inode} inode.
 
 \begin{figure}[htb]
   \centering 
   \includegraphics[width=14cm]{img/dir_links}

-  \caption{Organizzazione dei link per le directory.}
+  \caption{Organizzazione dei \textit{link} per le directory.}

   \label{fig:file_dirs_link}
 \end{figure}
 
   \label{fig:file_dirs_link}
 \end{figure}
 


@@ -598,20 +615,15 @@ era partiti avr
 referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}.
 
 
 referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}.
 
 

-% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
-% possono incontrare (in particolare quelle relative alla perdita di contenuti
-% in caso di crash del sistema)
-

 \subsection{I filesystem di uso comune}
 \label{sec:file_ext2}
 
 Il filesystem standard più usato con Linux è il cosiddetto \textit{third
   extended filesystem}, identificato dalla sigla \acr{ext3}. Esso nasce come
 evoluzione del precedente \textit{second extended filesystem}, o \acr{ext2},
 \subsection{I filesystem di uso comune}
 \label{sec:file_ext2}
 
 Il filesystem standard più usato con Linux è il cosiddetto \textit{third
   extended filesystem}, identificato dalla sigla \acr{ext3}. Esso nasce come
 evoluzione del precedente \textit{second extended filesystem}, o \acr{ext2},

-di cui eredita gran parte delle caratteristiche di base, per questo motivo
-parleremo anzitutto di questo, dato che molto di quanto diremo si applica
-anche ad \acr{ext3}.
-
+di cui eredita gran parte delle caratteristiche di base, per questo, per
+mantenere un minimo di semplicità, parleremo anzitutto di questo, dato che
+molto di quanto diremo si applica anche ad \acr{ext3}.

 
 Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
 prime versioni del kernel e supporta tutte le caratteristiche di un
 
 Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
 prime versioni del kernel e supporta tutte le caratteristiche di un


@@ -659,11 +671,6 @@ in gruppi di blocchi.\footnote{non si confonda questa definizione con
   \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
   kernel.}
 
   \texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
   kernel.}
 

-Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
-filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
-una maggiore affidabilità e possibilità di recupero in caso di corruzione del
-superblock principale.
-

 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct}  
 \begin{figure}[htb]
   \centering
   \includegraphics[width=9cm]{img/dir_struct}  


@@ -671,6 +678,11 @@ superblock principale.
   \label{fig:file_ext2_dirs}
 \end{figure}
 
   \label{fig:file_ext2_dirs}
 \end{figure}
 

+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+superblock principale.
+

 L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi
 nelle prestazioni dato che viene ridotta la distanza fra i dati e la tabella
 degli \index{inode} inode.
 L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi
 nelle prestazioni dato che viene ridotta la distanza fra i dati e la tabella
 degli \index{inode} inode.


@@ -682,6 +694,10 @@ lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo
 è possibile implementare nomi per i file anche molto lunghi (fino a 1024
 caratteri) senza sprecare spazio disco.
 
 è possibile implementare nomi per i file anche molto lunghi (fino a 1024
 caratteri) senza sprecare spazio disco.
 

+% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
+% possono incontrare (in particolare quelle relative alla perdita di contenuti
+% in caso di crash del sistema)
+

 
 % LocalWords:  everything is device kernel filesystem sez pathname root glibc
 % LocalWords:  path filename bootloader proc name components fifo socket dev LF
 
 % LocalWords:  everything is device kernel filesystem sez pathname root glibc
 % LocalWords:  path filename bootloader proc name components fifo socket dev LF


@@ -691,9 +707,9 @@ caratteri) senza sprecare spazio disco.
 % LocalWords:  nell'header unistd stream dall'ANSI stdio locking POSIX fig type
 % LocalWords:  register superblock dell'inode stat entry cache dcache dentry ln
 % LocalWords:  l'inode lookup ops read write llseek ioctl readdir poll nell'I
 % LocalWords:  nell'header unistd stream dall'ANSI stdio locking POSIX fig type
 % LocalWords:  register superblock dell'inode stat entry cache dcache dentry ln
 % LocalWords:  l'inode lookup ops read write llseek ioctl readdir poll nell'I

-% LocalWords:  multiplexing mmap fsync fasync seek MacOs group dall' dell' img
+% LocalWords:  multiplexing mmap fsync fasync seek group dall' dell' img

 % LocalWords:  count unlink nell' rename gapil second Tb attributes BSD SVr gid
 % LocalWords:  count unlink nell' rename gapil second Tb attributes BSD SVr gid

-% LocalWords:  sgid append only log fs linux extented linked list third
+% LocalWords:  sgid append only log fs linux extented linked list third MacOS

 
 
 %%% Local Variables: 
 
 
 %%% Local Variables: 

diff --git a/fileunix.tex b/fileunix.tex
index 3a9d1c0ba63e5a10f116f159ec9fa3ff549feab6..4327719ad6735520c873d9682c5b288695b2496c 100644 (file)
--- a/fileunix.tex
+++ b/fileunix.tex
@@ -386,6 +386,9 @@ ritorno il file descriptor con il valore pi
   \itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione
   della suddetta modalità con \func{fcntl}.}
 
   \itindex{thread} \textit{thread}, fra l'apertura del file e l'impostazione
   della suddetta modalità con \func{fcntl}.}
 

+%TODO trattare le differenze fra O_DSYNC, O_SYNC e O_RSYNC introdotte con 
+% il kernel 2.6.33, vedi http://lwn.net/Articles/350219/
+

 Questa caratteristica permette di prevedere qual è il valore del file
 descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
 alcune applicazioni per sostituire i file corrispondenti ai file standard
 Questa caratteristica permette di prevedere qual è il valore del file
 descriptor che si otterrà al ritorno di \func{open}, e viene talvolta usata da
 alcune applicazioni per sostituire i file corrispondenti ai file standard

diff --git a/system.tex b/system.tex
index 4f6dd4eeb672c497301c8f75ced7d009b61faddf..b2f8249e32511b8fe697850e8055e1dda6ee9791 100644 (file)
--- a/system.tex
+++ b/system.tex
@@ -1651,12 +1651,13 @@ Nello specificare un limite, oltre a fornire dei valori specifici, si pu
 anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso
 di una risorsa; ma si ricordi che solo un processo con i privilegi di
 amministratore\footnote{per essere precisi in questo caso quello che serve è
 anche usare la costante \const{RLIM\_INFINITY} che permette di sbloccare l'uso
 di una risorsa; ma si ricordi che solo un processo con i privilegi di
 amministratore\footnote{per essere precisi in questo caso quello che serve è

-  la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}.}
-può innalzare un limite al di sopra del valore corrente del limite massimo ed
-usare un valore qualsiasi per entrambi i limiti. Si tenga conto infine che
-tutti i limiti vengono ereditati dal processo padre attraverso una \func{fork}
-(vedi sez.~\ref{sec:proc_fork}) e mantenuti per gli altri programmi eseguiti
-attraverso una \func{exec} (vedi sez.~\ref{sec:proc_exec}).
+  la \itindex{capabilities} \textit{capability} \const{CAP\_SYS\_RESOURCE}
+  (vedi sez.~\ref{sec:proc_capabilities}).}  può innalzare un limite al di
+sopra del valore corrente del limite massimo ed usare un valore qualsiasi per
+entrambi i limiti. Si tenga conto infine che tutti i limiti vengono ereditati
+dal processo padre attraverso una \func{fork} (vedi sez.~\ref{sec:proc_fork})
+e mantenuti per gli altri programmi eseguiti attraverso una \func{exec} (vedi
+sez.~\ref{sec:proc_exec}).

 
 
 \subsection{Le risorse di memoria e processore}
 
 
 \subsection{Le risorse di memoria e processore}