fileintro.tex

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