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