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