fileintro.tex

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