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