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