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