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