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