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