Piccole correzioni e aggiornamenti.
authorSimone Piccardi <piccardi@gnulinux.it>
Sat, 30 Jan 2010 15:43:39 +0000 (15:43 +0000)
committerSimone Piccardi <piccardi@gnulinux.it>
Sat, 30 Jan 2010 15:43:39 +0000 (15:43 +0000)
filedir.tex
fileintro.tex
fileunix.tex
system.tex

index b1f8e7615086434a0acb31c9ba9073c20c879594..e14c105d31f6e07a39d8d7bac9efe5a3b44b8d81 100644 (file)
@@ -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à
-  \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
@@ -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
-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,
index 4bcbd4209fc9e40fbf62d646f2c8a8bbd08152ad..0048b3b67473735040a5c6086ff501186d6465a8 100644 (file)
@@ -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
-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
@@ -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
-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
-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}.
 
@@ -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
-riferimento è a se stessa.  \itindend{pathname}
+riferimento è a se stessa.  
+
+\itindend{pathname}
 
 
 \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
-  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
-  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}
@@ -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
-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
@@ -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}).\\
-    \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 
@@ -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
-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}
 
@@ -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,
-  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
-  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
-  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
-  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}
-  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}
 
-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}
-  \caption{Organizzazione dei link per le directory.}
+  \caption{Organizzazione dei \textit{link} per le directory.}
   \label{fig:file_dirs_link}
 \end{figure}
 
@@ -598,20 +615,15 @@ era partiti avr
 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},
-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
@@ -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.}
 
-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}  
@@ -671,6 +678,11 @@ superblock principale.
   \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.
@@ -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.
 
+% 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
@@ -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:  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:  sgid append only log fs linux extented linked list third
+% LocalWords:  sgid append only log fs linux extented linked list third MacOS
 
 
 %%% Local Variables: 
index 3a9d1c0ba63e5a10f116f159ec9fa3ff549feab6..4327719ad6735520c873d9682c5b288695b2496c 100644 (file)
@@ -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}.}
 
+%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
index 4f6dd4eeb672c497301c8f75ced7d009b61faddf..b2f8249e32511b8fe697850e8055e1dda6ee9791 100644 (file)
@@ -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 è
-  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}