fileintro.tex

   1 \chapter{L'architettura dei file}
   2 \label{cha:file_intro}
   3
   4 Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
   5 cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
   6 dispositivi di input/output del computer viene effettuato attraverso
   7 un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
   8 file di dati.
   9
  10 Questo significa che si può accedere a qualunque periferica del computer,
  11 dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
  12 cosiddetti file di dispositivo (i \textit{device file}). Questi sono dei file
  13 speciali agendo sui quali i programmi possono leggere, scrivere e compiere
  14 operazioni direttamente sulle periferiche, usando le stesse funzioni che si
  15 usano per i normali file di dati.
  16
  17 In questo capitolo forniremo una descrizione dell'architettura dei file in
  18 Linux, iniziando da una panoramica sulle caratteristiche principali delle
  19 interfacce con cui i processi accedono ai file (che tratteremo in dettaglio
  20 nei capitoli seguenti), per poi passare ad una descrizione più dettagliata
  21 delle modalità con cui detto accesso viene realizzato dal sistema.
  22
  23
  24
  25 \section{L'architettura generale}
  26 \label{sec:file_access_arch}
  27
  28 Per poter accedere ai file, il kernel deve mettere a disposizione dei
  29 programmi le opportune interfacce che consentano di leggerne il contenuto; il
  30 sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera
  31 opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi.
  32 Questo viene fatto strutturando l'informazione sul disco attraverso quello che
  33 si chiama un \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi
  34 viene resa disponibile ai processi attraverso quello che viene chiamato il
  35 \textsl{montaggio} del \textit{filesystem}.
  36 % (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
  37
  38 In questa sezione faremo una panormamica generica su come il sistema presenta
  39 i file ai processi, trattando l'organizzazione di file e directory, i tipi di
  40 file ed introducendo le interfacce disponibili e le loro caratteristiche.
  41
  42
  43 \subsection{L'organizzazione di file e directory}
  44 \label{sec:file_organization}
  45
  46 In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
  47 file vengono tenuti all'interno di un unico albero la cui radice (quella che
  48 viene chiamata \textit{root directory}) viene montata all'avvio.  Un file
  49 viene identificato dall'utente usando quello che viene chiamato
  50 \textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa
  51   nomenclatura, che genererebbe confusione poiché \textit{path} indica anche
  52   un insieme di directory su cui effettuare una ricerca (come quello in cui si
  53   cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e
  54   di componente per il nome del file all'interno della directory. Non
  55   seguiremo questa scelta dato che l'uso della parola \textit{pathname} è
  56   ormai così comune che mantenerne l'uso è senz'altro più chiaro
  57   dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere
  58 al file a partire dalla \textit{root directory}, che è composto da una serie
  59 di nomi separati da una \file{/}.
  60
  61 All'avvio del sistema, completata la fase di inizializzazione, il kernel
  62 riceve dal boot loader l'indicazione di quale dispositivo contiene il
  63 filesystem da usare come punto di partenza e questo viene montato come radice
  64 dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem
  65 che possono essere su altri dispositivi dovranno poi essere inseriti
  66 nell'albero montandoli su opportune directory del filesystem montato come
  67 radice.
  68
  69 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
  70 alcune strutture interne del kernel) sono generati automaticamente dal kernel
  71 stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
  72
  73 Una directory, come vedremo in maggior dettaglio in
  74 \secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
  75 particolare che il kernel riconosce come tale. Il suo scopo è quello di
  76 contenere una lista di nomi di file e le informazioni che associano ciascun
  77 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
  78 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
  79 un'organizzazione ad albero inserendo directory in altre directory.
  80
  81 Un file può essere indicato rispetto alla directory corrente semplicemente
  82 specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
  83   contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
  84     components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
  85 contenuto.  All'interno dello stesso albero si potranno poi inserire anche
  86 tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
  87 come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
  88 ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
  89
  90 Il nome completo di un file viene chiamato \textit{pathname} ed il
  91 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
  92 risoluzione del nome (\textit{file name resolution} o \textit{pathname
  93   resolution}).  La risoluzione viene fatta esaminando il \textit{pathname} da
  94 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
  95 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
  96   costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
  97 perché il procedimento funzioni, occorre che i nomi indicati come directory
  98 esistano e siano effettivamente directory, inoltre i permessi (si veda
  99 \secref{sec:file_access_control}) devono consentire l'accesso all'intero
 100 \textit{pathname}.
 101
 102 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
 103 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
 104 \secref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
 105 directory radice dell'albero dei file: in questo caso si parla di un
 106 \textsl{pathname assoluto}\index{pathname assoluto}. Altrimenti la ricerca
 107 parte dalla directory corrente (su cui torneremo in
 108 \secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
 109   relativo}\index{pathname relativo}.
 110
 111 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
 112 in ogni directory: il primo fa riferimento alla directory corrente e il
 113 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
 114 la directory che contiene il riferimento alla directory corrente; nel caso
 115 questa sia la directory radice, allora il riferimento è a se stessa.
 116
 117
 118 \subsection{I tipi di file}
 119 \label{sec:file_file_types}
 120
 121 Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi
 122 sono implementati come oggetti del \textit{Virtual File System} (vedi
 123 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
 124 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
 125 \textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
 126
 127 Si tenga ben presente che questa classificazione non ha nulla a che fare con
 128 la classificazione sui tipi di file (che in questo caso sono sempre file di
 129 dati) in base al loro contenuto, o tipo di accesso.
 130
 131 \begin{table}[htb]
 132   \footnotesize
 133   \centering
 134     \begin{tabular}[c]{|l|l|p{7cm}|}
 135     \hline
 136     \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
 137     \hline
 138     \hline
 139       \textit{regular file} & \textsl{file regolare} &
 140       un file che contiene dei dati (l'accezione normale di file) \\
 141       \textit{directory} & \textsl{cartella o direttorio} &
 142       un file che contiene una lista di nomi associati a degli \textit{inodes}
 143       (vedi \secref{sec:file_vfs}).  \\
 144       \textit{symbolic link} & \textsl{collegamento simbolico} &
 145       un file che contiene un riferimento ad un altro file/directory \\
 146       \textit{char device} & \textsl{dispositivo a caratteri} &
 147       un file che identifica una periferica ad accesso a caratteri \\
 148       \textit{block device} & \textsl{dispositivo a blocchi} &
 149       un file che identifica una periferica ad accesso a blocchi \\
 150       \textit{fifo} & \textsl{``coda''} &
 151       un file speciale che identifica una linea di comunicazione software
 152       (unidirezionale) \\
 153       \textit{socket} & \textsl{``presa''} &
 154       un file speciale che identifica una linea di comunicazione software
 155       (bidirezionale) \\
 156     \hline
 157     \end{tabular}
 158     \caption{Tipologia dei file definiti nel VFS}
 159     \label{tab:file_file_types}
 160 \end{table}
 161
 162 Infatti una delle differenze principali con altri sistemi operativi (come il
 163 VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
 164 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
 165 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
 166 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
 167 per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
 168   kernel della serie 2.4 è disponibile, attraverso dei device file appositi,
 169   una forma di accesso diretto ai dischi (il \textit{raw access}) che però non
 170   ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
 171   passare attraverso un filesystem.}
 172
 173 Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
 174 codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
 175 il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
 176 del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
 177   dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
 178   conversione fra questi due formati di testo.} Questo può causare alcuni
 179 problemi qualora nei programmi si facciano assunzioni sul terminatore della
 180 riga.
 181
 182 Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
 183 dati e che non c'è nessun supporto del sistema per le estensioni come parte
 184 del filesystem. Ciò nonostante molti programmi adottano delle convenzioni per
 185 i nomi dei file, ad esempio il codice C normalmente si mette in file con
 186 l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
 187 universale, solo una convenzione.
 188
 189
 190 \subsection{Le due interfacce ai file}
 191 \label{sec:file_io_api}
 192
 193 In Linux le modalità di accesso ai file e le relative interfacce di
 194 programmazione sono due, basate su due diversi meccanismi con cui è possibile
 195 accedere al loro contenuto.
 196
 197 La prima è l'interfaccia standard di Unix, quella che il manuale delle
 198 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
 199   descriptor}).  È un'interfaccia specifica dei sistemi unix-like e fornisce
 200 un accesso non bufferizzato; la tratteremo in dettaglio in
 201 \capref{cha:file_unix_interface}.
 202
 203 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
 204 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
 205 direttamente le system call del kernel (in realtà il kernel effettua al suo
 206 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
 207 dispositivi); i \textit{file descriptor}\index{file descriptor} sono
 208 rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}).
 209 L'interfaccia è definita nell'header \file{unistd.h}.
 210
 211 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
 212 \textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso
 213 bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
 214 tratteremo in dettaglio nel \capref{cha:files_std_interface}.
 215
 216 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
 217 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
 218 e sono rappresentati da puntatori ad un opportuna struttura definita dalle
 219 librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il
 220 tipo \ctyp{FILE *}.  L'interfaccia è definita nell'header \file{stdio.h}.
 221
 222 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
 223 altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio
 224 a tempo opportuno), ma per poter accedere alle operazioni di controllo
 225 (descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque
 226 tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i
 227 \textit{file descriptor}. Allo stesso modo devono essere usati i \textit{file
 228   descriptor} se si vuole ricorrere a modalità speciali di I/O come il polling
 229 o il non-bloccante (vedi \capref{cha:file_advanced}).
 230
 231 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
 232 quella dei \textit{file descriptor}, che permette di poter scegliere tra
 233 diversi stili di bufferizzazione.  Il maggior vantaggio degli \textit{stream}
 234 è che l'interfaccia per le operazioni di input/output è enormemente più ricca
 235 di quella dei \textit{file descriptor}, che forniscono solo funzioni
 236 elementari per la lettura/scrittura diretta di blocchi di byte.  In
 237 particolare gli \textit{stream} dispongono di tutte le funzioni di
 238 formattazione per l'input e l'output adatte per manipolare anche i dati in
 239 forma di linee o singoli caratteri.
 240
 241 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
 242 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
 243 uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
 244 tempo uno \textit{stream} ad un \textit{file descriptor}.
 245
 246 In generale, se non necessitano specificatamente le funzionalità di basso
 247 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
 248 portabilità, essendo questi ultimi definiti nello standard ANSI C;
 249 l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
 250 POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
 251
 252
 253 % \subsection{Caratteristiche specifiche dei file in Unix}
 254 % \label{sec:fileint_unix_spec}
 255
 256 % Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
 257 % specifiche di un sistema unix-like che devono essere tenute in conto
 258 % nell'accesso ai file. È infatti normale che più processi o programmi possano
 259 % accedere contemporaneamente allo stesso file e devono poter eseguire le loro
 260 % operazioni indipendentemente da quello che fanno gli altri processi.
 261
 262 % Per questo motivo le strutture usate per all'accesso ai file sono relative al
 263 % processo che effettua l'accesso.  All'apertura di ogni file infatti viene
 264 % creata all'interno del processo una apposita struttura in cui sono memorizzati
 265 % tutti gli attributi del medesimo, che viene utilizzata per tutte le
 266 % operazioni. Questa è una struttura che resta locale al processo stesso; in
 267 % questo modo processi diversi possono usare le proprie strutture locali per
 268 % accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
 269 % indipendente.
 270
 271 % Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
 272 % sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
 273 % file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
 274 % successiva. Essa è rappresentata da un numero intero che indica il numero di
 275 % byte dall'inizio del file, che viene (a meno che non si apra il file in
 276 % append) inizializzato a zero all'apertura del medesimo.
 277
 278 % Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
 279 % ogni processo avrà la sua posizione corrente nel file, che non sarà
 280 % influenzata da quello che altri processi possono fare. Anzi, aprire un file
 281 % significa appunto creare ed inizializzare una tale struttura, per cui se si
 282 % apre due volte lo stesso file all'interno dello stesso processo, si otterranno
 283 % due file descriptor o due stream che avranno ancora una posizione corrente nel
 284 % file assolutamente indipendente.
 285
 286 % Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
 287 % accesso è un riferimento all'inode del file, pertanto anche se il file viene
 288 % cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
 289 % dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
 290 % chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
 291 % in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
 292 % cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
 293 % file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
 294 % saranno disponibili per tutto il tempo in cui il processo è attivo.
 295
 296 % Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
 297 % l'input/output sui file, esaminando in dettaglio come tutto ciò viene
 298 % realizzato.
 299
 300
 301 \section{L'architettura della gestione dei file}
 302 \label{sec:file_arch_func}
 303
 304 Per capire fino in fondo le proprietà di file e directory in un sistema
 305 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
 306 una breve introduzione al funzionamento gestione dei file da parte del kernel
 307 e sugli oggetti su cui è basato un filesystem. In particolare occorre tenere
 308 presente dov'è che si situa la divisione fondamentale fra kernel space e user
 309 space che tracciavamo al \capref{cha:intro_unix}.
 310
 311 In questa sezione esamineremo come viene implementato l'accesso ai file in
 312 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
 313 prima le caratteristiche generali di un filesystem di un sistema unix-like,
 314 per poi trattare in maniera un po' più dettagliata il filesystem standard di
 315 Linux, l'\acr{ext2}.
 316
 317 % in particolare si riprenderà, approfondendolo sul piano dell'uso nelle
 318 % funzioni di libreria, il concetto di \textit{inode} di cui abbiamo brevemente
 319 % accennato le caratteristiche (dal lato dell'implementazione nel kernel) in
 320 % \secref{sec:file_vfs}.
 321
 322
 323 \subsection{Il \textit{Virtual Filesystem} di Linux}
 324 \label{sec:file_vfs}
 325
 326 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
 327 % file.  L'argomento è abbastanza ``esoterico'' e questa sezione può essere
 328 % saltata ad una prima lettura; è bene però tenere presente che vengono
 329 % introdotti qui alcuni termini che potranno comparire in seguito, come
 330 % \textit{inode}, \textit{dentry}, \textit{dcache}.
 331
 332 In Linux il concetto di \textit{everything is a file} è stato implementato
 333 attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
 334 strato intermedio che il kernel usa per accedere ai più svariati filesystem
 335 mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce
 336 un livello di indirezione che permette di collegare le operazioni di
 337 manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di
 338 queste ultime nei vari modi in cui i diversi filesystem le effettuano,
 339 permettendo la coesistenza di filesystem differenti all'interno dello stesso
 340 albero delle directory.
 341
 342 Quando un processo esegue una system call che opera su un file, il kernel
 343 chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
 344 manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle
 345 opportune routine del filesystem specifico a cui si fa riferimento. Saranno
 346 queste a chiamare le funzioni di più basso livello che eseguono le operazioni
 347 di I/O sul dispositivo fisico, secondo lo schema riportato in
 348 \figref{fig:file_VFS_scheme}.
 349
 350 \begin{figure}[htb]
 351   \centering
 352   \includegraphics[width=7cm]{img/vfs}
 353   \caption{Schema delle operazioni del VFS.}
 354   \label{fig:file_VFS_scheme}
 355 \end{figure}
 356
 357 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
 358 implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
 359 le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
 360 \textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
 361 definite nel kernel.
 362
 363 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
 364 filesystem supportato: quando si vuole inserire il supporto di un nuovo
 365 filesystem tutto quello che occorre è chiamare la funzione
 366 \code{register\_filesystem} passandole un'apposita struttura
 367 (\var{file\_system\_type}) che contiene i dettagli per il riferimento
 368 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
 369
 370 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
 371 (o qualunque altro \textit{block device} che può contenere un filesystem), il
 372 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
 373 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
 374 il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili
 375 interne e restituire uno speciale descrittore dei filesystem montati al VFS;
 376 attraverso quest'ultimo diventa possibile accedere alle routine specifiche per
 377 l'uso di quel filesystem.
 378
 379 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
 380 una apposita struttura che contiene vari dati come le informazioni comuni ad
 381 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
 382 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
 383 usare le funzioni contenute nel \textit{filesystem descriptor} per accedere
 384 alle routine specifiche di quel filesystem.
 385
 386 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
 387 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
 388 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
 389 filesystem usate per l'accesso dal VFS; in particolare il descrittore
 390 dell'inode contiene i puntatori alle funzioni che possono essere usate su
 391 qualunque file (come \func{link}, \func{stat} e \func{open}), mentre il
 392 descrittore di file contiene i puntatori alle funzioni che vengono usate sui
 393 file già aperti.
 394
 395
 396 \subsection{Il funzionamento del VFS}
 397 \label{sec:file_vfs_work}
 398
 399 La funzione più importante implementata dal VFS è la system call \func{open}
 400 che permette di aprire un file. Dato un pathname viene eseguita una ricerca
 401 dentro la \textit{directory entry cache} (in breve \textit{dcache}), una
 402 tabella che contiene tutte le \textit{directory entry} (in breve
 403 \textit{dentry}) che permette di associare in maniera rapida ed efficiente il
 404 pathname a una specifica \textit{dentry}.
 405
 406 Una singola \textit{dentry} contiene in genere il puntatore ad un
 407 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
 408 identifica un singolo oggetto del VFS sia esso un file ordinario, una
 409 directory, un link simbolico, una FIFO, un file di dispositivo, o una
 410 qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di
 411 ``file'' riportati in \tabref{tab:file_file_types}). A ciascuno di essi è
 412 associata pure una struttura che sta in memoria, e che, oltre alle
 413 informazioni sullo specifico file, contiene anche il riferimento alle funzioni
 414 (i \textsl{metodi} del VFS) da usare per poterlo manipolare.
 415
 416 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
 417 vengono usate per motivi di velocità, gli \textit{inode} invece stanno su
 418 disco e vengono copiati in memoria quando serve, ed ogni cambiamento viene
 419 copiato all'indietro sul disco, gli inode che stanno in memoria sono inode del
 420 VFS ed è ad essi che puntano le singole \textit{dentry}.
 421
 422 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
 423 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
 424 parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
 425 per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
 426 pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode
 427 corrispondente in memoria.
 428
 429 Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode
 430 della directory che contiene il file; questo viene installato nelle relative
 431 strutture in memoria quando si effettua il montaggio lo specifico filesystem
 432 su cui l'inode va a vivere.
 433
 434 Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo
 435 \textit{inode}) diventa possibile accedere alle varie operazioni sul file come
 436 la \func{open} per aprire il file o la \func{stat} per leggere i dati
 437 dell'inode e passarli in user space.
 438
 439 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
 440 una struttura di tipo \var{file} in cui viene inserito un puntatore alla
 441 \textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
 442 metodi che implementano le operazioni disponibili sul file. In questo modo i
 443 processi in user space possono accedere alle operazioni attraverso detti
 444 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
 445 (su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
 446 operazioni previste dal kernel è riportato in \ntab.
 447
 448 \begin{table}[htb]
 449   \centering
 450   \footnotesize
 451   \begin{tabular}[c]{|l|p{8cm}|}
 452     \hline
 453     \textbf{Funzione} & \textbf{Operazione} \\
 454     \hline
 455     \hline
 456     \textsl{\code{open}}   & apre il file (vedi \secref{sec:file_open}). \\
 457     \textsl{\code{read}}   & legge dal file (vedi \secref{sec:file_read}).\\
 458     \textsl{\code{write}}  & scrive sul file (vedi \secref{sec:file_write}).\\
 459     \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi
 460                              \secref{sec:file_lseek}). \\
 461     \textsl{\code{ioctl}}  & accede alle operazioni di controllo
 462                              (vedi \secref{sec:file_ioctl}).\\
 463     \textsl{\code{readdir}}& legge il contenuto di una directory \\
 464     \textsl{\code{poll}}   & usata nell'I/O multiplexing (vedi
 465                              \secref{sec:file_multiplexing}). \\
 466     \textsl{\code{mmap}}   & mappa il file in memoria (vedi
 467                              \secref{sec:file_memory_map}). \\
 468     \textsl{\code{release}}& chiamata quando l'ultima referenza a un file
 469                              aperto è chiusa. \\
 470     \textsl{\code{fsync}}  & sincronizza il contenuto del file (vedi
 471                              \secref{sec:file_sync}). \\
 472     \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
 473                              \secref{sec:file_asyncronous_io}) sul file. \\
 474     \hline
 475   \end{tabular}
 476   \caption{Operazioni sui file definite nel VFS.}
 477   \label{tab:file_file_operations}
 478 \end{table}
 479
 480 In questo modo per ciascun file diventano possibili una serie di operazioni
 481 (non è detto che tutte siano disponibili), che costituiscono l'interfaccia
 482 astratta del VFS.  Qualora se ne voglia eseguire una, il kernel andrà ad
 483 utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
 484 di file in questione.
 485
 486 In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
 487 su normale un file di dati; ovviamente certe operazioni (nel caso della
 488 seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
 489 sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
 490 MacOs) è immediato e (relativamente) trasparente per l'utente ed il
 491 programmatore.
 492
 493
 494 \subsection{Il funzionamento di un filesystem Unix}
 495 \label{sec:file_filesystem}
 496
 497 Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema
 498 unix-like) organizza i dati che tiene su disco attraverso l'uso di un
 499 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
 500 quella di poter supportare, grazie al VFS, una enorme quantità di filesystem
 501 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
 502 proprie.  Per questo, per il momento non entreremo nei dettagli di un
 503 filesystem specifico, ma daremo una descrizione a grandi linee che si adatta
 504 alle caratteristiche comuni di qualunque filesystem di sistema unix-like.
 505
 506 Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
 507 partizione può contenere un filesystem. La strutturazione tipica
 508 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
 509 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
 510 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
 511 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
 512 comune di tutti i filesystem per Unix, indipendentemente da come poi viene
 513 strutturata nei dettagli questa informazione, prevedere una divisione fra la
 514 lista degli inodes e lo spazio a disposizione per i dati e le directory.
 515
 516 \begin{figure}[htb]
 517   \centering
 518   \includegraphics[width=12cm]{img/disk_struct}
 519   \caption{Organizzazione dello spazio su un disco in partizioni e
 520   filesystem.}
 521   \label{fig:file_disk_filesys}
 522 \end{figure}
 523
 524 Se si va ad esaminare con maggiore dettaglio la strutturazione
 525 dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
 526 relativi al funzionamento del filesystem stesso come la strutturazione in
 527 gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
 528 esemplificare la situazione con uno schema come quello esposto in \nfig.
 529
 530 \begin{figure}[htb]
 531   \centering
 532   \includegraphics[width=12cm]{img/filesys_struct}
 533   \caption{Strutturazione dei dati all'interno di un filesystem.}
 534   \label{fig:file_filesys_detail}
 535 \end{figure}
 536
 537 Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
 538 filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
 539 per capire il funzionamento delle funzioni che manipolano i file e le
 540 directory che tratteremo nel prossimo capitolo; in particolare è opportuno
 541 ricordare sempre che:
 542
 543 \begin{enumerate}
 544
 545 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
 546   tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
 547   fisici che contengono i dati e così via; le informazioni che la funzione
 548   \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
 549   troverà solo il nome del file e il numero dell'\textit{inode} ad esso
 550   associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
 551   traduzione dell'inglese \textit{directory entry}, che non useremo anche per
 552   evitare confusione con le \textit{dentry} del kernel di cui si parlava in
 553   \secref{sec:file_vfs}).
 554
 555 \item Come mostrato in \curfig\ si possono avere più voci che puntano allo
 556   stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
 557   numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
 558   solo quando questo contatore si annulla i dati del file vengono
 559   effettivamente rimossi dal disco. Per questo la funzione per cancellare un
 560   file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
 561   file, ma si limita ad eliminare la relativa voce da una directory e
 562   decrementare il numero di riferimenti nell'\textit{inode}.
 563
 564 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
 565   nello stesso filesystem e non ci può essere una directory che contiene
 566   riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
 567   l'uso del comando \cmd{ln} (che crea una nuova voce per un file
 568   esistente, con la funzione \func{link}) al filesystem corrente.
 569
 570 \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto
 571   del file non viene spostato fisicamente, viene semplicemente creata una
 572   nuova voce per l'\textit{inode} in questione e rimossa la vecchia (questa è
 573   la modalità in cui opera normalmente il comando \cmd{mv} attraverso la
 574   funzione \func{rename}).
 575
 576 \end{enumerate}
 577
 578 Infine è bene avere presente che, essendo file pure loro, esiste un numero di
 579 riferimenti anche per le directory; per cui, se a partire dalla situazione
 580 mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
 581 \file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
 582 abbiamo aggiunto dei numeri di inode.
 583
 584 \begin{figure}[htb]
 585   \centering
 586   \includegraphics[width=12cm]{img/dir_links}
 587   \caption{Organizzazione dei link per le directory.}
 588   \label{fig:file_dirs_link}
 589 \end{figure}
 590
 591 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
 592 è referenziata dalla directory da cui si era partiti (in cui è inserita la
 593 nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
 594 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
 595 che non contenga a sua volta altre directory. Al contempo, la directory da
 596 cui si era partiti avrà un numero di riferimenti di almeno tre, in quanto
 597 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
 598
 599
 600 \subsection{Il filesystem \textsl{ext2}}
 601 \label{sec:file_ext2}
 602
 603 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
 604   filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
 605 caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di
 606 file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di
 607 4~Tb.
 608
 609 Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
 610 non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
 611 \begin{itemize}
 612 \item i \textit{file attributes} consentono di modificare il comportamento del
 613   kernel quando agisce su gruppi di file. Possono essere impostati su file e
 614   directory e in quest'ultimo caso i nuovi file creati nella directory
 615   ereditano i suoi attributi.
 616 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
 617   montaggio. La semantica BSD comporta che i file in una directory sono creati
 618   con lo stesso identificatore di gruppo della directory che li contiene. La
 619   semantica SVr4 comporta che i file vengono creati con l'identificatore del
 620   gruppo primario del processo, eccetto il caso in cui la directory ha il bit
 621   di \acr{sgid} impostato (per una descrizione dettagliata del significato di
 622   questi termini si veda \secref{sec:file_access_control}), nel qual caso file
 623   e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
 624 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
 625   in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
 626   permettono un accesso più veloce, ma sprecano più spazio disco).
 627 \item il filesystem implementa link simbolici veloci, in cui il nome del file
 628   non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando
 629   letture multiple e spreco di spazio), non tutti i nomi però possono essere
 630   gestiti così per limiti di spazio (il limite è 60 caratteri).
 631 \item vengono supportati i file immutabili (che possono solo essere letti) per
 632   la protezione di file di configurazione sensibili, o file
 633   \textit{append-only} che possono essere aperti in scrittura solo per
 634   aggiungere dati (caratteristica utilizzabile per la protezione dei file di
 635   log).
 636 \end{itemize}
 637
 638 La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD:
 639 un filesystem è composto da un insieme di blocchi, la struttura generale è
 640 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
 641 è divisa in gruppi di blocchi.
 642
 643 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
 644 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
 645 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
 646 superblock principale.
 647
 648 \begin{figure}[htb]
 649   \centering
 650   \includegraphics[width=9cm]{img/dir_struct}
 651   \caption{Struttura delle directory nel \textit{second extented filesystem}.}
 652   \label{fig:file_ext2_dirs}
 653 \end{figure}
 654
 655 L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
 656 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
 657 inode.
 658
 659 Le directory sono implementate come una linked list con voci di dimensione
 660 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
 661 lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
 662 in questo modo è possibile implementare nomi per i file anche molto lunghi
 663 (fino a 1024 caratteri) senza sprecare spazio disco.
 664
 665
 666
 667
 668 %%% Local Variables:
 669 %%% mode: latex
 670 %%% TeX-master: "gapil"
 671 %%% End: