1 \chapter{L'architettura dei file}
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
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.
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.
25 \section{L'architettura generale}
26 \label{sec:file_access_arch}
28 Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
29 le opportune interfacce che consentano di leggerne il contenuto; il sistema
30 cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
31 l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
32 fatto strutturando l'informazione sul disco attraverso quello che si chiama un
33 \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa
34 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}).
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.
43 \subsection{L'organizzazione di file e directory}
44 \label{sec:file_organization}
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{anche se il manuale della \acr{glibc} depreca
51 questa nomenclatura, poiché genererebbe confusione, dato che con
52 \textit{path} si indica anche un insieme di directory su cui effettuare una
53 ricerca (come quello in cui si cercano i comandi) non seguiremo questa
54 scelta dato che l'uso della parola \textit{pathname} è ormai così comune che
55 mantenerne l'uso è senz'altro più chiaro dell'alternativa proposta.}, cioè
56 il percorso che si deve fare per accedere al file a partire dalla \textit{root
57 directory}, che è composto da una serie di nomi separati da una \file{/}.
59 All'avvio del sistema, comletata la fase di inizializzazione il kernel riceve
60 dal boot loader l'indicazione di quale dispositivo contiene il filesystem da
61 usare come punto di partenza e questo viene montato come radice dell'albero
62 (cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono
63 essere su altri dispositivi dovranno poi essere inseriti nell'albero
64 montandoli su opportune directory del filesystem montato come radice.
66 Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
67 alcune strutture interne del kernel) sono generati automaticamente dal kernel
68 stesso, ma anche essi devono essere montati all'interno dell'albero dei file.
70 Una directory, come vedremo in maggior dettaglio in
71 \secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file
72 particolare che il kernel riconosce come tale. Il suo scopo è quello di
73 contenere una lista di nomi di file e le informazioni che associano ciascun
74 nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque
75 oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente
76 un'organizzazione ad albero inserendo directory in altre directory.
78 Un file può essere indicato rispetto alla directory corrente semplicemente
79 specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi
80 contenuti nelle directory \textsl{componenti} (in inglese \textit{file name
81 components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
82 contenuto. All'interno dello stesso albero si potranno poi inserire anche
83 tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
84 come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
85 ultimi, per convenzione, sono inseriti nella directory \file{/dev}).
87 Il nome completo di un file viene chiamato \textit{pathname} ed il
88 procedimento con cui si individua il file a cui esso fa riferimento è chiamato
89 risoluzione del nome (\textit{file name resolution} o \textit{pathname
90 resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
91 sinistra a destra e localizzando ogni nome nella directory indicata dal nome
92 precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il
93 costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente
94 perché il procedimento funzioni occorre che i nomi indicati come directory
95 esistano e siano effettivamente directory, inoltre i permessi (si veda
96 \secref{sec:file_access_control}) devono consentire l'accesso.
98 Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory
99 radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in
100 \secref{sec:file_chroot}) è la stessa per tutti i processi ed equivale alla
101 directory radice dell'albero dei file: in questo caso si parla di un
102 \textsl{pathname assoluto}\index{pathname assoluto}. Altrimenti la ricerca
103 parte dalla directory corrente (su cui torneremo in
104 \secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname
105 relativo}\index{pathname relativo}.
107 I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
108 in ogni directory, il primo fa riferimento alla directory corrente e il
109 secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
110 la directory che contiene il riferimento alla directory corrente; nel caso
111 questa sia la directory radice allora il riferimento è a se stessa.
114 \subsection{I tipi di file}
115 \label{sec:file_file_types}
117 Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi
118 sono implementati come oggetti del \textit{Virtual File System} (vedi
119 \secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
120 utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
121 \textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
123 Si tenga ben presente che questa classificazione non ha nulla a che fare con
124 la classificazione sui tipi di file (che in questo caso sono sempre file di
125 dati) in base al loro contenuto, o tipo di accesso.
130 \begin{tabular}[c]{|l|l|p{7cm}|}
132 \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
135 \textit{regular file} & \textsl{file normale} &
136 un file che contiene dei dati (l'accezione normale di file) \\
137 \textit{directory} & \textsl{cartella o direttorio} &
138 un file che contiene una lista di nomi associati a degli \textit{inodes}
139 (vedi \secref{sec:file_vfs}). \\
140 \textit{symbolic link} & \textsl{collegamento simbolico} &
141 un file che contiene un riferimento ad un altro file/directory \\
142 \textit{char device} & \textsl{dispositivo a caratteri} &
143 un file che identifica una periferica ad accesso sequenziale \\
144 \textit{block device} & \textsl{dispositivo a blocchi} &
145 un file che identifica una periferica ad accesso diretto \\
146 \textit{fifo} & \textsl{``tubo''} &
147 un file speciale che identifica una linea di comunicazione software
149 \textit{socket} & \textsl{``spina''} &
150 un file speciale che identifica una linea di comunicazione software
154 \caption{Tipologia dei file definiti nel VFS}
155 \label{tab:file_file_types}
158 Infatti una delle differenze principali con altri sistemi operativi (come il
159 VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
160 un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
161 dal sistema file di diverso contenuto o formato (come nel caso di quella fra
162 file di testo e binari che c'è in Windows) né c'è una strutturazione a record
163 per il cosiddetto ``accesso diretto'' come nel caso del VMS\footnote{con i
164 kernel della serie 2.4 è disponibile una forma di accesso diretto ai dischi
165 (il \textit{raw access}) attraverso dei device file appositi, che però non
166 ha nulla a che fare con questo}.
168 Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
169 codificata in maniera diversa da Windows o Mac, in particolare il fine
170 riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
171 (\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
172 problemi qualora nei programmi si facciano assunzioni sul terminatore della
175 Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
176 dati e che non c'è nessun supporto del sistema per le estensioni come parte
177 del filesystem. Ciò non ostante molti programmi adottano delle convenzioni per
178 i nomi dei file, ad esempio il codice C normalmente si mette in file con
179 l'estensione \file{.c}, ma questa è, appunto, solo una convenzione.
183 \subsection{Le due interfacce ai file}
184 \label{sec:file_io_api}
186 In Linux le modalità di accesso ai file e le relative interfacce di
187 programmazione sono due, basate su due diversi meccanismi con cui è possibile
188 accedere al loro contenuto.
190 La prima è l'interfaccia standard di Unix, quella che il manuale delle
191 \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file
192 descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede
193 un accesso non bufferizzato; la tratteremo in dettaglio in
194 \capref{cha:file_unix_interface}.
196 L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
197 bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
198 direttamente le system call del kernel (in realtà il kernel effettua al suo
199 interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
200 dispositivi); i \textit{file descriptor}\index{file descriptor} sono
201 rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}).
202 L'interfaccia è definita nell'header \file{unistd.h}.
204 La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli
205 \textit{stream}\index{stream}, essa provvede funzioni più evolute e un accesso
206 bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la
207 tratteremo in dettaglio nel \capref{cha:files_std_interface}.
209 Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
210 anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi
211 e sono rappresentati da puntatori ad un opportuna struttura definita dalle
212 librerie del C, si accede ad essi sempre in maniera indiretta utilizzando il
213 tipo \type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}.
215 Entrambe le interfacce possono essere usate per l'accesso ai file come agli
216 altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
217 a tempo opportuno), ma per poter accedere alle operazioni di controllo su un
218 qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix
219 coi \textit{file descriptor}. Allo stesso modo devono essere usati i
220 \textit{file descriptor} se si vuole ricorrere a modalità speciali di I/O come
221 il polling o il non-bloccante (vedi \capref{cha:file_advanced}).
223 Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra
224 quella dei \textit{file descriptor}, che permette di poter scegliere tra
225 diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream}
226 è che l'interfaccia per le operazioni di input/output è enormemente più ricca
227 di quella dei \textit{file descriptor}, che provvedono solo funzioni
228 elementari per la lettura/scrittura diretta di blocchi di byte. In
229 particolare gli \textit{stream} dispongono di tutte le funzioni di
230 formattazione per l'input e l'output adatte per manipolare anche i dati in
231 forma di linee o singoli caratteri.
233 In ogni caso, dato che gli stream sono implementati sopra l'interfaccia
234 standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da
235 uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo
236 tempo uno \textit{stream} ad un \textit{file descriptor}.
238 In generale, se non necessitano specificatamente le funzionalità di basso
239 livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore
240 portabilità, essendo questi ultimi definiti nello standard ANSI C;
241 l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard
242 POSIX.1 dei sistemi Unix, ed è pertanto di portabilità più limitata.
245 % \subsection{Caratteristiche specifiche dei file in Unix}
246 % \label{sec:fileint_unix_spec}
248 % Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
249 % specifiche di un sistema unix-like che devono essere tenute in conto
250 % nell'accesso ai file. È infatti normale che più processi o programmi possano
251 % accedere contemporaneamente allo stesso file e devono poter eseguire le loro
252 % operazioni indipendentemente da quello che fanno gli altri processi.
254 % Per questo motivo le strutture usate per all'accesso ai file sono relative al
255 % processo che effettua l'accesso. All'apertura di ogni file infatti viene
256 % creata all'interno del processo una apposita struttura in cui sono memorizzati
257 % tutti gli attributi del medesimo, che viene utilizzata per tutte le
258 % operazioni. Questa è una struttura che resta locale al processo stesso; in
259 % questo modo processi diversi possono usare le proprie strutture locali per
260 % accedere ai file (che può essere sempre lo stesso) in maniera assolutamente
263 % Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i
264 % sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
265 % file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
266 % successiva. Essa è rappresentata da un numero intero che indica il numero di
267 % byte dall'inizio del file, che viene (a meno che non si apra il file in
268 % append) inizializzato a zero all'apertura del medesimo.
270 % Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
271 % ogni processo avrà la sua posizione corrente nel file, che non sarà
272 % influenzata da quello che altri processi possono fare. Anzi, aprire un file
273 % significa appunto creare ed inizializzare una tale struttura, per cui se si
274 % apre due volte lo stesso file all'interno dello stesso processo, si otterranno
275 % due file descriptor o due stream che avranno ancora una posizione corrente nel
276 % file assolutamente indipendente.
278 % Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di
279 % accesso è un riferimento all'inode del file, pertanto anche se il file viene
280 % cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
281 % dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
282 % chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
283 % in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
284 % cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
285 % file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
286 % saranno disponibili per tutto il tempo in cui il processo è attivo.
288 % Ritorneremo su questo più avanti in \secref{sec:file_fd}, quando tratteremo
289 % l'input/output sui file, esaminando in dettaglio come tutto ciò viene
293 \section{L'architettura della gestione dei file}
294 \label{sec:file_arch_func}
296 Per capire fino in fondo le proprietà di file e directory in un sistema
297 unix-like ed il comportamento delle relative funzioni di manipolazione occorre
298 una breve introduzione al funzionamento gestione dei file da parte del kernel
299 e sugli oggetti su cui è basato un filesystem di tipo unix. In particolare
300 occorre tenere presente dov'è che si situa la divisione fondamentale fra
301 kernel space e user space che tracciavamo al \capref{cha:intro_unix}.
303 In questa sezione esamineremo come viene implementato l'accesso ai file in
304 Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
305 prima le caratteristiche generali di un filesystem Unix, per poi trattare in
306 maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}.
309 % in particolare si riprenderà, approfondendolo sul piano
310 % dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
311 % abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
312 % nel kernel) in \secref{sec:file_vfs}.
315 \subsection{Il \textit{virtual filesystem} di Linux}
318 % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
319 % file. L'argomento è abbastanza ``esoterico'' e questa sezione può essere
320 % saltata ad una prima lettura; è bene però tenere presente che vengono
321 % introdotti qui alcuni termini che potranno comparire in seguito, come
322 % \textit{inode}, \textit{dentry}, \textit{dcache}.
324 In Linux il concetto di \textit{everything is a file} è stato implementato
325 attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
326 l'interfaccia che il kernel rende disponibile ai programmi in user space
327 attraverso la quale vengono manipolati i file; esso provvede un livello di
328 indirezione che permette di collegare le operazioni di manipolazione sui file
329 alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
330 modi in cui diversi filesystem la effettuano, permettendo la coesistenza
331 di filesystem differenti all'interno dello stesso albero delle directory
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 alla
336 opportune routine 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 \nfig.
342 \includegraphics[width=7cm]{img/vfs}
343 \caption{Schema delle operazioni del VFS}
344 \label{fig:file_VFS_scheme}
347 Il VFS definisce un insieme di funzioni che tutti i filesystem devono
348 implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
349 le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
350 \textit{inode} e \textit{file}, corrispondenti a tre apposite strutture
353 Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
354 filesystem supportato: quando si vuole inserire il supporto di un nuovo
355 filesystem tutto quello che occorre è chiamare la funzione
356 \code{register\_filesystem} passandole un'apposita struttura
357 (\var{file\_system\_type}) che contiene i dettagli per il riferimento
358 all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
360 In questo modo quando viene effettuata la richiesta di montare un nuovo disco
361 (o qualunque altro \textit{block device} che può contenere un filesystem), il
362 VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
363 nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
364 il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
365 variabili interne e restituire uno speciale descrittore dei filesystem montati
366 al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
367 specifiche per l'uso di quel filesystem.
369 Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
370 una apposita struttura che contiene vari dati come le informazioni comuni ad
371 ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
372 puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
373 usare le funzioni contenute nel filesystem descriptor per accedere alle routine
374 specifiche di quel filesystem.
376 Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
377 su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni
378 relative al file in uso, insieme ai puntatori alle funzioni dello specifico
379 filesystem usate per l'accesso dal VFS; in particolare il descrittore
380 dell'inode contiene i puntatori alle funzioni che possono essere usate su
381 qualunque file (come \func{link}, \func{stat} e \func{open}), mentre il
382 descrittore di file contiene i puntatori alle funzioni che vengono usate sui
386 \subsection{Il funzionamento del VFS}
387 \label{sec:file_vfs_work}
389 La funzione più fondamentale implementata dal VFS è la system call
390 \func{open} che permette di aprire un file. Dato un pathname viene eseguita
391 una ricerca dentro la \textit{directory entry cache} (in breve
392 \textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
393 entry} (in breve \textit{dentry}) che permette di associare in maniera
394 rapida ed efficiente il pathname a una specifica dentry.
396 Una singola \textit{dentry} contiene in genere il puntatore ad un
397 \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
398 identifica un singolo oggetto del VFS sia esso un file ordinario, una
399 directory, un link simbolico, una FIFO, un file di dispositivo, o una
400 qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
401 ``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
402 una struttura che sta in memoria, e che oltre alle informazioni sullo
403 specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
404 da usare per poterlo manipolare.
406 Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
407 vengono usate per motivi di velocità, gli inode invece stanno su disco e
408 vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
409 all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
410 è ad essi che puntano le singole \textit{dentry}.
412 La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
413 l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
414 parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
415 per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
416 pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode
417 corrispondente in memoria.
419 Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode
420 della directory che contiene il file; questo viene installato nelle relative
421 strutture in memoria quando si effettua il montaggio lo specifico filesystem
422 su cui l'inode va a vivere.
424 Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
425 diventa possibile accedere alle varie operazioni sul file come la
426 \func{open} per aprire il file o la \func{stat} per leggere i dati
427 dell'inode e passarli in user space.
429 L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
430 una struttura di tipo \var{file} in cui viene inserito un puntatore alla
431 \textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
432 metodi che implementano le operazioni disponibili sul file. In questo modo i
433 processi in user space possono accedere alle operazioni attraverso detti
434 metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
435 (su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
436 operazioni previste dal kernel è riportato in \ntab.
441 \begin{tabular}[c]{|l|p{7cm}|}
443 \textbf{Funzione} & \textbf{Operazione} \\
446 \textsl{\code{open}} & apre il file \\
447 \textsl{\code{read}} & legge dal file \\
448 \textsl{\code{write}} & scrive sul file \\
449 \textsl{\code{llseek}} & sposta la posizione corrente sul file \\
450 \textsl{\code{ioctl}} & accede alle operazioni di controllo
451 (tramite la \func{ioctl})\\
452 \textsl{\code{readdir}}& per leggere il contenuto di una directory \\
453 \textsl{\code{poll}} & \\
454 \textsl{\code{mmap}} & chiamata dalla system call \func{mmap}.
455 mappa il file in memoria\\
456 \textsl{\code{release}}& chiamata quando l'ultima referenza a un file
458 \textsl{\code{fsync}} & chiamata dalla system call \func{fsync} \\
459 \textsl{\code{fasync}} & chiamate da \func{fcntl} quando è abilitato
460 il modo asincrono per l'I/O su file. \\
463 \caption{Operazioni sui file definite nel VFS.}
464 \label{tab:file_file_operations}
467 In questo modo per ciascun file diventano utilizzabili una serie di operazioni
468 (non è dette che tutte siano disponibili), che costituiscono l'interfaccia
469 astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
470 utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
471 di file in questione.
473 Così sarà possibile scrivere sulla porta seriale come su un file di dati
474 normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
475 \code{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
476 diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
477 (relativamente) trasparente per l'utente ed il programmatore.
480 \subsection{Il funzionamento di un filesystem unix}
481 \label{sec:file_filesystem}
483 Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
484 in generale) organizza i dati che tiene su disco attraverso l'uso di un
485 filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
486 quella di poter supportare grazie al VFS una enorme quantità di filesystem
487 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
488 proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
489 daremo una descrizione a grandi linee che si adatta alle caratteristiche
490 comuni di un qualunque filesystem standard unix.
492 Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
493 partizione può contenere un filesystem; la strutturazione tipica
494 dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
495 alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
496 in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
497 di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
498 comune di tutti i filesystem unix, indipendentemente da come poi viene
499 strutturata nei dettagli questa informazione, prevedere una divisione fra la
500 lista degli inodes e lo spazio a disposizione per i dati e le directory.
504 \includegraphics[width=9cm]{img/disk_struct}
505 \caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
506 \label{fig:file_disk_filesys}
509 Se si va ad esaminare con maggiore dettaglio la strutturazione
510 dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
511 relativi al funzionamento del filesystem stesso come la strutturazione in
512 gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
513 esemplificare la situazione con uno schema come quello esposto in \nfig.
517 \includegraphics[width=11cm]{img/filesys_struct}
518 \caption{Strutturazione dei dati all'interno di un filesystem}
519 \label{fig:file_filesys_detail}
522 Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
523 cui è bene porre attenzione in quanto sono fondamentali per capire il
524 funzionamento delle funzioni che manipolano i file e le directory su cui
525 torneremo in seguito; in particolare è opportuno ricordare sempre che:
529 \item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
530 tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
531 fisici che contengono i dati e così via; le informazioni che la funzione
532 \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
533 troverà solo il nome del file e il numero dell'\textit{inode} ad esso
534 associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
535 (traduzione approssimata dell'inglese \textit{directory entry}, che non
536 useremo anche per evitare confusione con le \textit{dentry} del kernel di
537 cui si parlava in \secref{sec:file_vfs}).
539 \item Come mostrato in \curfig si possono avere più voci che puntano allo
540 stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
541 numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
542 solo quando questo contatore si annulla i dati del file vengono
543 effettivamente rimossi dal disco. Per questo la funzione per cancellare un
544 file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
545 file, ma si limita a eliminare la relativa voce da una directory e
546 decrementare il numero di riferimenti nell'\textit{inode}.
548 \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
549 nello stesso filesystem e non ci può essere una directory che contiene
550 riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
551 l'uso del comando \cmd{ln} (che crea una nuova voce per un file
552 esistente, con la funzione \func{link}) al filesystem corrente.
554 \item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
555 del file non deve essere spostato, viene semplicemente creata una nuova voce
556 per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
557 in cui opera normalmente il comando \cmd{mv} attraverso la funzione
562 Infine è bene avere presente che essendo file pure loro, esiste un numero di
563 riferimenti anche per le directory; per cui se ad esempio a partire dalla
564 situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
565 directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
566 chiarezza abbiamo aggiunto dei numeri di inode.
570 \includegraphics[width=11cm]{img/dir_links}
571 \caption{Organizzazione dei link per le directory}
572 \label{fig:file_dirs_link}
575 La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
576 è referenziata dalla directory da cui si era partiti (in cui è inserita la
577 nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
578 che è sempre inserita in ogni directory; questo vale sempre per ogni directory
579 che non contenga a sua volta altre directory. Al contempo la directory da
580 cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
581 adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
584 \subsection{Il filesystem \textsl{ext2}}
585 \label{sec:file_ext2}
587 Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
588 filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
589 caratteristiche di un filesystem standard unix, è in grado di gestire
590 filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
593 Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
594 che non sono presenti sugli altri filesystem unix, le cui principali sono le
597 \item i \textit{file attributes} consentono di modificare il comportamento del
598 kernel quando agisce su gruppi di file. Possono essere settati su file e
599 directory e in quest'ultimo caso i nuovi file creati nella directory
600 ereditano i suoi attributi.
601 \item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
602 montaggio. La semantica BSD comporta che i file in una directory sono creati
603 con lo stesso identificatore di gruppo della directory che li contiene. La
604 semantica SVr4 comporta che i file vengono creati con l'identificatore del
605 gruppo primario del processo, eccetto il caso in cui la directory ha il bit
606 di \acr{sgid} settato (per una descrizione dettagliata del significato di
607 questi termini si veda \secref{sec:file_access_control}), nel qual caso file
608 e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
609 \item l'amministratore può scegliere la dimensione dei blocchi del filesystem
610 in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
611 permettono un accesso più veloce, ma sprecano più spazio disco).
612 \item il filesystem implementa link simbolici veloci, in cui il nome del file
613 non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando
614 letture multiple e spreco di spazio), non tutti i nomi però possono essere
615 gestiti così per limiti di spazio (il limite è 60 caratteri).
616 \item vengono supportati i file immutabili (che possono solo essere letti) per
617 la protezione di file di configurazione sensibili, o file
618 \textit{append-only} che possono essere aperti in scrittura solo per
619 aggiungere dati (caratteristica utilizzabile per la protezione dei file di
623 La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
624 un filesystem è composto da un insieme di blocchi, la struttura generale è
625 quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
626 è divisa in gruppi di blocchi.
628 Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
629 filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
630 una maggiore affidabilità e possibilità di recupero in caso di corruzione del
631 superblock principale.
635 \includegraphics[width=9cm]{img/dir_struct}
636 \caption{Struttura delle directory nel \textit{second extented filesystem}.}
637 \label{fig:file_ext2_dirs}
640 L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
641 prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
644 Le directory sono implementate come una linked list con voci di dimensione
645 variabile. Ciascuna voce della lista contiene il numero di inode, la sua
646 lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
647 in questo modo è possibile implementare nomi per i file anche molto lunghi
648 (fino a 1024 caratteri) senza sprecare spazio disco.
655 %%% TeX-master: "gapil"