-
-\chapter{I files: l'architettura}
-\label{cha:files_intro}
+\chapter{I file: l'architettura}
+\label{cha:file_intro}
Uno dei concetti fondamentali della architettura di unix è il cosiddetto
\textit{everything is a file}, cioè il fatto che l'accesso ai vari dispositivi
Questo significa che si può accedere a qualunque periferica del computer,
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
-cosiddetti file di dispositivo (i \textit{device files}). Questi sono dei file
+cosiddetti file di dispositivo (i \textit{device file}). Questi sono dei file
speciali agendo sui quali i programmi possono leggere, scrivere e compiere
operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.
contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
varie caratteristiche distintive.
-\section{L'organizzazione di files e directories}
-\label{sec:fileintr_organization}
-Il primo passo nella trattazione dell'achitettura della gestione dei file in
+
+\section{L'organizzazione di file e directory}
+\label{sec:file_organization}
+
+Il primo passo nella trattazione dell'architettura della gestione dei file in
un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
di quale è la struttura che hanno all'interno del sistema.
-\subsection{La struttura di files e directory}
-\label{sec:fileintr_filedir_struct}
+\subsection{La struttura di file e directory}
+\label{sec:file_file_struct}
Partiamo allora da come viene strutturata nel sistema la disposizione dei
file: per potervi accedere il kernel usa una apposita interfaccia che permetta
di accedere all'informazione tenuta sullo spazio grezzo disponibile sui
dischi, cioè quello che si chiama un \textit{filesystem}\footnote{useremo per
brevità questo nome al posto della più prolissa traduzione italiana sistema
- di file}, che descriviremo in dettaglio in \secref{sec:fileintr_vfs}.
+ di file}, che descriveremo in dettaglio in \secref{sec:file_vfs}.
Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati
-memorizzati all'interno del disco stesso, strutturando l'informazione in files
+memorizzati all'interno del disco stesso, strutturando l'informazione in file
e directory. Per poter accedere ai file contenuti in un disco occorrerà
perciò attivare il filesystem, questo viene fatto \textsl{montando} il disco
(o la partizione del disco).
%In generale un filesystem piazzerà opportunamente sul disco dei blocchi di
%informazioni riservate che tengono conto degli inodes allocati, di quelli
-%liberi, e delle posizioni fisiche su disco dei dati contenuti nei files, per
+%liberi, e delle posizioni fisiche su disco dei dati contenuti nei file, per
In unix, a differenza di quanto avviene in altri sistemi operativi, tutti i
file vengono tenuti all'interno di un unico albero la cui radice (la directory
Dopo la fase di inizializzazione il kernel riceve dal boot loader
l'indicazione di quale dispositivo contiene il filesystem da usare come punto
di partenza e questo viene montato come radice dell'albero (cioè nella
-directory \texttt{/}); tutti gli ulteriori dischi devono poi essere inseriti
+directory \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
nell'albero utilizzando opportune subdirectory.
-Alcuni filesystem speciali (come \texttt{/proc} che contiene un'interfaccia ad
+Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad
alcune strutture interne del kernel) sono generati automaticamente dal kernel
stesso, ma anche essi devono essere montati all'interno dell'albero.
All'interno dello stesso albero si potranno poi inserire anche gli altri
-oggetti visti attraverso l'interfaccia che manipola i files come le FIFO, i
+oggetti visti attraverso l'interfaccia che manipola i file come le FIFO, i
link, i socket e gli stessi i file di dispositivo (questi ultimi, per
-convenzione, sono inseriti nella directory \texttt{/dev}).
+convenzione, sono inseriti nella directory \file{/dev}).
L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei
medesimi nell'albero descritto in precedenza; una directory comunque, come già
-specificato in \secref{sec:fileintr_vfs}, è solo un particolare tipo di file
+specificato in \secref{sec:file_vfs}, è solo un particolare tipo di file
che contiene le informazioni che associano un nome al contenuto.
% Per questo, anche se è usuale parlare di ``file in una directory'' in realtà
I manuale delle glibc chiama i nomi contenuti nelle directory
\textsl{componenti} (in inglese \textit{file name components}), noi li
-chiameremo più semplicemente nomi. Un file può essere indicato rispetto alla
-directory corrente semplicemente specificando il nome da essa contenuto. Una
-directory contiene semplicemente un elenco di questi nomi, che possono
-corrispondere a un qualunque oggetto del filesystem, compresa un'altra
+chiameremo più semplicemente \textit{nomi}. Un file può essere indicato
+rispetto alla directory corrente semplicemente specificando il nome da essa
+contenuto. Una directory contiene semplicemente un elenco di questi nomi, che
+possono corrispondere a un qualunque oggetto del filesystem, compresa un'altra
directory; l'albero viene appunto creato inserendo directory in altre
directory.
-Il nome completo di file generico è composto da una serie di questi
-\textsl{componenti} separati da una \texttt{/} (in Linux più \texttt{/}
-consecutive sono considerate equivalenti ad una sola). Il nome completo di un
-file viene usualmente chiamato \textit{pathname}, e anche se il manuale della
-glibc depreca questo nome (poiché genererebbe confusione, dato che con
-\textit{path} si indica anche un insieme di directory su cui effettuare una
-ricerca, come quello in cui si cercano i comandi); l'uso è ormai così comune
-che è senz'altro più chiaro dell'alternativa proposta.
+Il nome completo di file generico è composto da una serie di nomi separati da
+una \file{/} (in Linux più \file{/} consecutive sono considerate
+equivalenti ad una sola). Il nome completo di un file viene usualmente
+chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo
+nome (poiché genererebbe confusione, dato che con \textit{path} si indica
+anche un insieme di directory su cui effettuare una ricerca, come quello in
+cui si cercano i comandi); non seguiremo questa scelta dato che l'uso della
+parola \textit{pathname} è ormai così comune che è senz'altro più chiaro
+dell'alternativa proposta.
Il processo con cui si associa ad un pathname uno specifico file è chiamato
risoluzione del nome (\textit{file name resolution} o \textit{pathname
indicati come directory esistano e siano effettivamente directory, inoltre i
permessi devono consentire l'accesso.
-Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice
+Se il pathname comincia per \file{/} la ricerca parte dalla directory radice
del processo; questa, a meno di un \textit{chroot} (su cui torneremo in
seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed
equivale alla directory radice dell'albero (come descritto in
-\secref{sec:fileintr_organization}): in questo caso si parla di un pathname
+\secref{sec:file_organization}): in questo caso si parla di un pathname
\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
-cui torneremo più avanti in \secref{sec:filedir_work_dir}) ed il pathname è
+cui torneremo più avanti in \secref{sec:file_work_dir}) ed il pathname è
detto \textsl{relativo}.
-I nomi \texttt{.} e \texttt{..} hanno un significato speciale e vengono
-inseriti in ogni directory, il primo fa riferimento alla directory corrente e
-il secondo alla directory \textsl{genitore} (\textit{parent directory}) cioè
-la directory che contiene il riferimento alla directory corrente; nel caso
-questa sia la directory radice allora il riferimento è a se stessa.
+I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti
+in ogni directory, il primo fa riferimento alla directory corrente e il
+secondo alla directory \textsl{genitrice} (\textit{parent directory}) cioè la
+directory che contiene il riferimento alla directory corrente; nel caso questa
+sia la directory radice allora il riferimento è a se stessa.
-\subsection{I tipi di files}
-\label{sec:fileintr_file_types}
+\subsection{I tipi di file}
+\label{sec:file_file_types}
Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
sono implementati come oggetti del \textit{Virtual File System} (vedi
-\secref{sec:fileintro_vfs}) e sono presenti in tutti i filesystem unix-like
+\secref{sec:file_vfs}) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual
File System è riportato in \ntab.
dati) in base al loro contenuto, o tipo di accesso.
\begin{table}[htb]
- \begin{center}
- \begin{tabular}[c]{l l p{7cm}}
- \multicolumn{2}{c}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
+ \footnotesize
+ \centering
+ \begin{tabular}[c]{|l|l|p{7cm}|}
+ \hline
+ \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\
+ \hline
\hline
\textit{regular file} & \textsl{file normale} &
un file che contiene dei dati (l'accezione normale di file) \\
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
- \label{tab:fileintr_file_types}
- \end{center}
+ \label{tab:file_file_types}
\end{table}
Infatti una delle differenze principali con altri sistemi operativi (come il
VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
-un flusso continuo di bytes. Non esiste cioè differenza per come vengono visti
+un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
dal sistema file di diverso contenuto o formato (come nel caso di quella fra
file di testo e binari che c'è in Windows) né c'è una strutturazione a record
per il cosiddetto ``accesso diretto'' come nel caso del VMS\footnote{con i
ha nulla a che fare con questo}.
Una seconda differenza è nel formato dei file ASCII; in Unix la fine riga è
-codificata in maniera diversa da Windows o MacIntosh, in particolare il fine
+codificata in maniera diversa da Windows o Mac, in particolare il fine
riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
-(\verb|\r|) del mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
+(\verb|\r|) del Mac e del \texttt{CR LF} di Windows. Questo può causare alcuni
problemi qualora nei programmi si facciano assunzioni sul terminatore della
riga.
\subsection{Le due interfacce ai file}
-\label{sec:fileintr_io_api}
+\label{sec:file_io_api}
In unix le modalità di accesso ai file e le relative interfacce di
programmazione sono due, basate su due diversi meccanismi con cui è possibile
La prima è l'interfaccia standard di unix, quella che il manuale delle glibc
chiama interfaccia dei descrittori di file (o \textit{file descriptor}). È
-un'interfaccia specifica di unix e provvede un accesso non bufferizzato.
+un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la
+tratteremo in dettaglio in \capref{cha:file_unix_interface}.
L'interfaccia è primitiva ed essenziale, l'accesso viene detto non
bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando
direttamente le system call del kernel (in realtà il kernel effettua al suo
interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai
-dispositivi); i file descriptors sono rappresentati da numeri interi (cioè
-semplici variabili di tipo \texttt{int}). L'interfaccia è definita
-nell'header \texttt{unistd.h}.
+dispositivi); i file descriptor sono rappresentati da numeri interi (cioè
+semplici variabili di tipo \type{int}). L'interfaccia è definita
+nell'header \file{unistd.h}.
La seconda interfaccia è quella che il manuale della glibc chiama degli
\textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato
-(controllato dalla implementazione fatta dalle librerie del C). Questa è
-l'interfaccia standard specificata dall'ANSI C e perciò si trova anche su
-tutti i sistemi non Unix. Gli stream sono oggetti complessi e sono
+(controllato dalla implementazione fatta dalle librerie del C), la tratteremo
+in dettaglio in \capref{cha:files_std_interface}.
+
+Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova
+anche su tutti i sistemi non unix. Gli stream sono oggetti complessi e sono
rappresentati da puntatori ad un opportuna struttura definita dalle librerie
del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo
-\texttt{FILE *}. L'interfaccia è definita nell'header \texttt{stdio.h}.
+\type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}.
Entrambe le interfacce possono essere usate per l'accesso ai file come agli
-altri oggetti del VFS (pipes, socket, device), ma per poter accedere alle
+altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle
operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre
-usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo
+usare l'interfaccia standard di unix coi file descriptor. Allo stesso modo
devono essere usati i file descriptor se si vuole ricorrere a modalità
speciali di I/O come il polling o il non-bloccante (vedi
-\secref{sec:file_xxx}).
+\secref{sec:file_noblocking}).
Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
maggior vantaggio degli stream è che l'interfaccia per le operazioni di
input/output è enormemente più ricca di quella dei file descriptor, che
provvedono solo funzioni elementari per la lettura/scrittura diretta di
-blocchi di bytes. In particolare gli stream dispongono di tutte le funzioni
+blocchi di byte. In particolare gli stream dispongono di tutte le funzioni
di formattazione per l'input e l'output adatte per manipolare anche i dati in
forma di linee o singoli caratteri.
\label{sec:fileint_unix_spec}
Essendo un sistema multitasking e multiutente esistono alcune caratteristiche
-specifiche di Unix che devono essere tenute in conto nell'accesso ai file. È
-infatti normale che più processi o programmi possano accedere
-contemporaneamente allo stesso file e devono poter eseguire le loro operazioni
-indipendentemente da quello che fanno gli altri processi.
+specifiche di un sistema unix-like che devono essere tenute in conto
+nell'accesso ai file. È infatti normale che più processi o programmi possano
+accedere contemporaneamente allo stesso file e devono poter eseguire le loro
+operazioni indipendentemente da quello che fanno gli altri processi.
Per questo motivo le strutture usate per all'accesso ai file sono relative al
processo che effettua l'accesso. All'apertura di ogni file infatti viene
sistemi POSIX uno degli attributi di un file aperto è la posizione corrente nel
file, cioè il punto nel file in cui verrebbe letto o scritto alla operazione
successiva. Essa è rappresentata da un numero intero che indica il numero di
-bytes dall'inizio del file, che viene (a meno che non si apra il file in
+byte dall'inizio del file, che viene (a meno che non si apra il file in
append) inizializzato a zero all'apertura del medesimo.
Questo è uno dei dati che viene mantenuto nella suddetta struttura, per cui
cancellato da un altro processo, sarà sempre possibile mantenere l'accesso ai
dati, e lo spazio su disco non verrà rilasciato fintanto che il file non sarà
chiuso e l'ultimo riferimento cancellato. È pertanto possibile (come vedremo
-in dettaglio in \secref{sec:fileintr_link}) aprire un file provvisorio per
+in dettaglio in \secref{sec:file_link}) aprire un file provvisorio per
cancellarlo immediatamente dopo; in questo modo all'uscita del programma il
file scomparirà definitivamente dal disco, ma il file ed il suo contenuto
saranno disponibili per tutto il tempo in cui il processo è attivo.
Ritorneremo su questo più avanti, quando tratteremo l'input/output sui file,
esaminando in dettaglio come tutto ciò viene realizzato.
-Si ricordi infine che in unix non esistono i tipi di file e che non c'è nessun
-supporto per le estensioni come parte del filesystem. Ciò non ostante molti
-programmi adottano delle convenzioni per i nomi dei file, ad esempio il codice
-C normalmente si mette in file con l'estensione .c, ma questa è, appunto, solo
-una convenzione.
-
+Si ricordi infine che in ambiente unix non esistono i tipi di file e che non
+c'è nessun supporto per le estensioni come parte del filesystem. Ciò non
+ostante molti programmi adottano delle convenzioni per i nomi dei file, ad
+esempio il codice C normalmente si mette in file con l'estensione .c, ma
+questa è, appunto, solo una convenzione.
\section{L'architettura della gestione dei file}
-\label{sec:fileintro_architecture}
+\label{sec:file_architecture}
-Per capire fino in fondo le proprietà di files e directories in un sistema
-unix ed il funzionamento delle relative funzioni di manipolazione occorre una
-breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato
-un filesystem unix. In particolare occorre tenere presente dov'è che si situa
-la divisione fondamentale fra kernel space e user space che tracciavamo al
-\capref{cha:intro_unix}.
+Per capire fino in fondo le proprietà di file e directory in un sistema
+unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
+una breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è
+basato un filesystem di tipo unix. In particolare occorre tenere presente
+dov'è che si situa la divisione fondamentale fra kernel space e user space che
+tracciavamo al \capref{cha:intro_unix}.
-In questa sezione esamineremo come viene implementato l'accesso ai files in
+In questa sezione esamineremo come viene implementato l'accesso ai file in
Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
poi in maniera un po' più dettagliata il filesystem standard di Linux,
-l'\texttt{ext2}, come esempio di un filesystem unix-like.
+l'\acr{ext2}, come esempio di un filesystem unix-like.
% in particolare si riprenderà, approfondendolo sul piano
% dell'uso nelle funzioni di libreria, il concetto di \textit{inode} di cui
% abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione
-% nel kernel) in \secref{sec:fileintr_vfs}.
+% nel kernel) in \secref{sec:file_vfs}.
+
\subsection{Il \textit{virtual filesystem} di Linux}
-\label{sec:fileintr_vfs}
+\label{sec:file_vfs}
% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
-% files. L'argomento è abbastanza ``esoterico'' e questa sezione può essere
+% file. L'argomento è abbastanza ``esoterico'' e questa sezione può essere
% saltata ad una prima lettura; è bene però tenere presente che vengono
% introdotti qui alcuni termini che potranno comparire in seguito, come
% \textit{inode}, \textit{dentry}, \textit{dcache}.
In Linux il concetto di \textit{everything is a file} è stato implementato
attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è
l'interfaccia che il kernel rende disponibile ai programmi in user space
-attraverso la quale vengono manipolati i files; esso provvede un livello di
-indirezione che permette di collegare le operazioni di manipolazione sui files
+attraverso la quale vengono manipolati i file; esso provvede un livello di
+indirezione che permette di collegare le operazioni di manipolazione sui file
alle operazioni di I/O e gestisce l'organizzazione di questi ultimi nei vari
modi in cui diversi filesystem la effettuano, permettendo la coesistenza
di filesystem differenti all'interno dello stesso albero delle directory
Quando un processo esegue una system call che opera su un file il kernel
chiama sempre una funzione implementata nel VFS; la funzione eseguirà le
-manipolazioni sulle strutture generiche e utilizzaerà poi la chiamata alla
+manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alla
opportune routine del filesystem specifico a cui si fa riferimento. Saranno
queste a chiamare le funzioni di più basso livello che eseguono le operazioni
di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig.
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=7cm]{img/vfs}
\caption{Schema delle operazioni del VFS}
- \label{fig:fileintro_VFS_scheme}
+ \label{fig:file_VFS_scheme}
\end{figure}
Il VFS definisce un insieme di funzioni che tutti i filesystem devono
implementare. L'interfaccia comprende tutte le funzioni che riguardano i
-files; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
+file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
e file, corrispondenti a tre apposite strutture definite nel kernel.
Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
-filesystem supportato, quando si vuole inserire il supporto di un nuovo
-filesystem tutto quello che occorre è una chiamata alla funzione
-\func{register\_filesystem} passando un'apposita struttura che
-(\var{file\_system\_type}) contiene l'implementazione edl medesimo, che sarà
-aggiunta alla citata tabella.
+filesystem supportato: quando si vuole inserire il supporto di un nuovo
+filesystem tutto quello che occorre è chiamare la funzione
+\func{register\_filesystem} passandole un'apposita struttura
+(\var{file\_system\_type}) che contiene i dettagli per il riferimento
+all'implementazione del medesimo, che sarà aggiunta alla citata tabella.
In questo modo quando viene effettuata la richiesta di montare un nuovo disco
(o qualunque altro \textit{block device} che può contenere un filesystem), il
VFS può ricavare dalla citata tabella il puntatore alle funzioni da chiamare
nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
-il superblock (vedi \ref{sec:fileintro_ext2}), inizializzare tutte le
+il superblock (vedi \ref{sec:file_ext2}), inizializzare tutte le
variabili interne e restituire uno speciale descrittore dei filesystem montati
-al VFS; attraverso quest'ultimo diventa possible accedere alle routine
+al VFS; attraverso quest'ultimo diventa possibile accedere alle routine
specifiche per l'uso di quel filesystem.
Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad
una apposita struttura che contiene vari dati come le informazioni comuni ad
ogni filesystem, i dati privati relativi a quel filesystem specifico, e i
puntatori alle funzioni del kernel relative al filesystem. Il VFS può così
-usare le funzioni contenute nel filesystem decriptor per accedere alle routine
+usare le funzioni contenute nel filesystem descriptor per accedere alle routine
specifiche di quel filesystem.
Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti
\subsection{Il funzionamento del VFS}
-\label{sec:fileintr_vfs_work}
+\label{sec:file_vfs_work}
La funzione più fondamentale implementata dal VFS è la system call
-\texttt{open} che permette di aprire un file. Dato un pathname viene eseguita
+\func{open} che permette di aprire un file. Dato un pathname viene eseguita
una ricerca dentro la \textit{directory entry cache} (in breve
\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory
entry} (in breve \textit{dentry}) che permette di associare in maniera
rapida ed efficiente il pathname a una specifica dentry.
-Una singola dentry contiene in genere il puntatore ad un \textit{inode};
-quest'ultimo è la struttura base che sta sul disco e che identifica un singolo
-oggetto del VFS sia esso un file ordinario, una directory, una FIFO, un file
-di dispositivo, o una qualsiasi altra cosa che possa essere rappresentata dal
-VFS (sui tipi di ``files'' possibili torneremo in seguito). A ciascuno di essi
-è associata pure una struttura che sta in memoria, e che oltre alle
-informazioni sullo specifico file contiene pure il riferimento alle funzioni
-(i \textsl{metodi}) da usare per poterlo manipolare.
-
-Le dentries ``vivono'' in memoria e non vengono mai salvate su disco, vengono
-usate per motivi di velocità, gli inodes invece stanno su disco e vengono
-copiati in memoria quando serve, ed ogni cambiamento viene copiato
-all'indietro sul disco, gli inodes che stanno in memoria sono inodes del VFS
-ed è ad essi che puntano le singole dentry.
-
-La dcache costituisce perciò una sorta di vista completa di tutto l'albero dei
-files, ovviamente per non riempire tutta la memoria questa vista è parziale
-(la dcache cioè contiene solo le dentry per i file per i quali è stato
-richiesto l'accesso), quando si vuole risolvere un nuovo pathname il VFS deve
-creare una nuova dentry e caricare l'inode corrispondente in memoria.
-
-Questo procedimento viene eseguito dal metodo \texttt{lookup()} dell'inode
+Una singola \textit{dentry} contiene in genere il puntatore ad un
+\textit{inode}; quest'ultimo è la struttura base che sta sul disco e che
+identifica un singolo oggetto del VFS sia esso un file ordinario, una
+directory, un link simbolico, una FIFO, un file di dispositivo, o una
+qualsiasi altra cosa che possa essere rappresentata dal VFS (sui tipi di
+``file'' possibili torneremo in seguito). A ciascuno di essi è associata pure
+una struttura che sta in memoria, e che oltre alle informazioni sullo
+specifico file contiene pure il riferimento alle funzioni (i \textsl{metodi})
+da usare per poterlo manipolare.
+
+Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
+vengono usate per motivi di velocità, gli inode invece stanno su disco e
+vengono copiati in memoria quando serve, ed ogni cambiamento viene copiato
+all'indietro sul disco, gli inode che stanno in memoria sono inode del VFS ed
+è ad essi che puntano le singole \textit{dentry}.
+
+La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
+l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è
+parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file
+per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo
+pathname il VFS deve creare una nuova \textit{dentry} e caricare l'inode
+corrispondente in memoria.
+
+Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode
della directory che contiene il file; questo viene installato nelle relative
strutture in memoria quando si effettua il montaggio lo specifico filesystem
su cui l'inode va a vivere.
Una volta che il VFS ha a disposizione la dentry (ed il relativo inode)
diventa possibile accedere alle varie operazioni sul file come la
-\texttt{open} per aprire il file o la \texttt{stat} per leggere i dati
+\func{open} per aprire il file o la \func{stat} per leggere i dati
dell'inode e passarli in user space.
L'apertura di un file richiede comunque un'altra operazione, l'allocazione di
-una struttura di tipo \texttt{file} in cui viene inserito un puntatore alla
-dentry e una struttura \verb|f_ops| che contiene i puntatori ai metodi che
-implementano le operazioni disponibili sul file. In questo modo i processi in
-user space possono accedere alle operazioni attraverso detti metodi, che
-saranno diversi a seconda del tipo di file (o dispositivo) aperto (su questo
-torneremo in dettaglio in \secref{sec:fileunix_fd}). Un elenco delle operazioni
-previste dal kernel è riportato in \ntab.
+una struttura di tipo \var{file} in cui viene inserito un puntatore alla
+\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai
+metodi che implementano le operazioni disponibili sul file. In questo modo i
+processi in user space possono accedere alle operazioni attraverso detti
+metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
+(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
+operazioni previste dal kernel è riportato in \ntab.
\begin{table}[htb]
\centering
- \begin{tabular}[c]{c p{7cm}}
- \textbf{funzione} & \textbf{operazione} \\
+ \footnotesize
+ \begin{tabular}[c]{|l|p{7cm}|}
\hline
- \textit{open} & apre il file \\
- \textit{read} & legge dal file \\
- \textit{write} & scrive sul file \\
- \textit{llseek} & sposta la posizione corrente sul file \\
- \textit{ioctl} & accede alle operazioni di controllo
- (tramite la \texttt{ioctl})\\
- \textit{readdir} & per leggere il contenuto di una directory \\
- \textit{poll} & \\
- \textit{mmap} & chiamata dalla system call \texttt{mmap}.
+ \textbf{Funzione} & \textbf{Operazione} \\
+ \hline
+ \hline
+ \textsl{\func{open}} & apre il file \\
+ \textsl{\func{read}} & legge dal file \\
+ \textsl{\func{write}} & scrive sul file \\
+ \textsl{\func{llseek}} & sposta la posizione corrente sul file \\
+ \textsl{\func{ioctl}} & accede alle operazioni di controllo
+ (tramite la \func{ioctl})\\
+ \textsl{\func{readdir}}& per leggere il contenuto di una directory \\
+ \textsl{\func{poll}} & \\
+ \textsl{\func{mmap}} & chiamata dalla system call \func{mmap}.
mappa il file in memoria\\
- \textit{release} & chiamata quando l'ultima referenza a un file
+ \textsl{\func{release}}& chiamata quando l'ultima referenza a un file
aperto è chiusa\\
- \textit{fsync} & chiamata dalla system call \texttt{fsync} \\
- \textit{fasync} & chiamate da \texttt{fcntl} quando è abilitato
- il modo asincrono per l'I/O su file. \\
+ \textsl{\func{fsync}} & chiamata dalla system call \func{fsync} \\
+ \textsl{\func{fasync}} & chiamate da \func{fcntl} quando è abilitato
+ il modo asincrono per l'I/O su file. \\
\hline
\end{tabular}
\caption{Operazioni sui file definite nel VFS.}
- \label{tab:fileintr_file_operations}
+ \label{tab:file_file_operations}
\end{table}
In questo modo per ciascun file diventano utilizzabili una serie di operazioni
(non è dette che tutte siano disponibili), che costituiscono l'interfaccia
astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad
-utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo
+utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
di file in questione.
Così sarà possibile scrivere sulla porta seriale come su un file di dati
normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
-\textit{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
+\func{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
diversi filesystem (come quelli usati da Windows o MacOs) è immediato e
(relativamente) trasparente per l'utente ed il programmatore.
\subsection{Il funzionamento di un filesystem unix}
-\label{sec:fileintr_filesystem}
+\label{sec:file_filesystem}
-Come già accennato in \secref{sec:fileintr_organization} Linux (ed ogni unix
+Come già accennato in \secref{sec:file_organization} Linux (ed ogni unix
in generale) organizza i dati che tiene su disco attraverso l'uso di un
filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
comuni di un qualunque filesystem standard unix.
Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem; quest'ultimo è in genere strutturato
-secondo \nfig, con una lista di inodes all'inizio e il resto dello spazio a
-disposizione per i dati e le directory.
+partizione può contenere un filesystem; la strutturazione tipica
+dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
+alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
+in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
+di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
+comune di tutti i filesystem unix, indipendentemente da come poi viene
+strutturata nei dettagli questa informazione, prevedere una divisione fra la
+lista degli inodes e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=9cm]{img/disk_struct}
\caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
- \label{fig:fileintr_disk_filesys}
+ \label{fig:file_disk_filesys}
\end{figure}
-Se si va ad esaminare come è strutturata l'informazione all'interno di un
-singolo filesystem (tralasciando le parti connesse alla strutturazione e al
-funzionamento del filesystem stesso come il super-block) avremo una situazione
-del tipo di quella esposta in \nfig.
+Se si va ad esaminare con maggiore dettaglio la strutturazione
+dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
+relativi al funzionamento del filesystem stesso come la strutturazione in
+gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
+esemplificare la situazione con uno schema come quello esposto in \nfig.
+
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione di un filesystem}
- \label{fig:fileintr_filesys_detail}
+ \includegraphics[width=11cm]{img/filesys_struct}
+ \caption{Strutturazione dei dati all'interno di un filesystem}
+ \label{fig:file_filesys_detail}
\end{figure}
-da questa figura si evidenziano alcune caratteristiche su cui è bene porre
-attenzione in quanto sono fondamentali per capire il funzionamento delle
-funzioni che manipolano i file e le directory su cui torneremo fra poco; in
-particolare è opportuno ricordare sempre che:
+
+Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
+cui è bene porre attenzione in quanto sono fondamentali per capire il
+funzionamento delle funzioni che manipolano i file e le directory su cui
+torneremo in seguito; in particolare è opportuno ricordare sempre che:
\begin{enumerate}
\item L'\textit{inode} contiene tutte le informazioni riguardanti il file: il
tipo di file, i permessi di accesso, le dimensioni, i puntatori ai blocchi
fisici che contengono i dati e così via; le informazioni che la funzione
- \texttt{stat} fornisce provengono dall'\textit{inode}; dentro una directory
- si troverà solo il nome del file e il numero dell'\textit{inode} ad esso
+ \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si
+ troverà solo il nome del file e il numero dell'\textit{inode} ad esso
associato, cioè quella che da qui in poi chiameremo una \textsl{voce}
(traduzione approssimata dell'inglese \textit{directory entry}, che non
- useremo anche per evitare confusione con le \textit{dentries} del kernel di
- cui si parlava in \secref{sec:fileintr_vfs}).
+ useremo anche per evitare confusione con le \textit{dentry} del kernel di
+ cui si parlava in \secref{sec:file_vfs}).
\item Come mostrato in \curfig si possono avere più voci che puntano allo
stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
solo quando questo contatore si annulla i dati del file vengono
effettivamente rimossi dal disco. Per questo la funzione per cancellare un
- file si chiama \texttt{unlink}, ed in realtà non cancella affatto i dati del
+ file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
file, ma si limita a eliminare la relativa voce da una directory e
decrementare il numero di riferimenti nell'\textit{inode}.
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
riferimenti ad \textit{inodes} relativi ad altri filesystem. Questo limita
- l'uso del comando \texttt{ln} (che crea una nuova voce per un file
- esistente, con la funzione \texttt{link}) al filesystem corrente.
+ l'uso del comando \cmd{ln} (che crea una nuova voce per un file
+ esistente, con la funzione \func{link}) al filesystem corrente.
\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto
del file non deve essere spostato, viene semplicemente creata una nuova voce
per l'\textit{inode} in questione e rimossa la vecchia (questa è la modalità
- in cui opera normalmente il comando \texttt{mv} attraverso la funzione
- \texttt{rename}).
+ in cui opera normalmente il comando \cmd{mv} attraverso la funzione
+ \func{rename}).
\end{enumerate}
Infine è bene avere presente che essendo file pure loro, esiste un numero di
-riferimenti anche per le directories; per cui se ad esempio a partire dalla
-situazione mostrata in \curfig\ creiamo una nuova directory \texttt{textdir}
-nella directory corrente avremo una situazione come quella in \nfig, dove per
+riferimenti anche per le directory; per cui se ad esempio a partire dalla
+situazione mostrata in \curfig\ creiamo una nuova directory \file{img} nella
+directory \file{gapil}: avremo una situazione come quella in \nfig, dove per
chiarezza abbiamo aggiunto dei numeri di inode.
+\begin{figure}[htb]
+ \centering
+ \includegraphics[width=11cm]{img/dir_links}
+ \caption{Organizzazione dei link per le directory}
+ \label{fig:file_dirs_link}
+\end{figure}
+
La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
è referenziata dalla directory da cui si era partiti (in cui è inserita la
-nuova voce che fa riferimento a \texttt{textdir}) e dalla voce \texttt{.}
+nuova voce che fa riferimento a \file{img}) e dalla voce \file{.}
che è sempre inserita in ogni directory; questo vale sempre per ogni directory
-che non contenga a sua volta altre directories. Al contempo la directory da
+che non contenga a sua volta altre directory. Al contempo la directory da
cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto
-adesso sarà referenziata anche dalla voce \texttt{..} di \texttt{textdir}.
+adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
-\subsection{Il filesystem \texttt{ext2}}
-\label{sec:fileintro_ext2}
+\subsection{Il filesystem \textsl{ext2}}
+\label{sec:file_ext2}
-Il filesystem standard usato da Linux è il cosidetto \textit{second extended
- filesystem}, identificato dalla sigla \texttt{ext2}. Esso supporta tutte le
+Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
+ filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le
caratteristiche di un filesystem standard unix, è in grado di gestire
-filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
+filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
4~Tb.
-Oltre alle caratteristiche standard ext2 fornisce alcune estensioni che non
-sono presenti sugli altri filesystem unix. Caratteristiche particolari di ext2
-sono le seguenti''
-
+Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
+che non sono presenti sugli altri filesystem unix, le cui principali sono le
+seguenti:
\begin{itemize}
\item i \textit{file attributes} consentono di modificare il comportamento del
kernel quando agisce su gruppi di file. Possono essere settati su file e
directory e in quest'ultimo caso i nuovi file creati nella directory
ereditano i suoi attributi.
-\item sono supportate entrambe le semantiche di BSD e SysV come opzioni di
+\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di
montaggio. La semantica BSD comporta che i file in una directory sono creati
con lo stesso identificatore di gruppo della directory che li contiene. La
- semantica SysV comporta che i file vengono creati con l'identificatore del
+ semantica SVr4 comporta che i file vengono creati con l'identificatore del
gruppo primario del processo, eccetto il caso in cui la directory ha il bit
- di setgid settata (per una descrizione dettagliata del sigificato di questi
- termini si veda \secref{sec:filedir_access_control}), nel qual caso file e
- sottodirectory ereditano sia il group id che il setgid.
+ di \acr{sgid} settato (per una descrizione dettagliata del significato di
+ questi termini si veda \secref{sec:file_access_control}), nel qual caso file
+ e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
\item l'amministratore può scegliere la dimensione dei blocchi del filesystem
in fase di creazione, a seconda delle sue esigenze (blocchi più grandi
- peremttono un accesso più veloce, ma sprecano più spazio disco).
+ permettono un accesso più veloce, ma sprecano più spazio disco).
\item il filesystem implementa link simbolici veloci, in cui il nome del file
non è salvato su un blocco, ma tenuto all'interno dell'inode (evitando
letture multiple e spreco di spazio), non tutti i nomi però possono essere
log).
\end{itemize}
-La struttura di ext2 è stata ispirata a quella del filesystem di BSD, un
-filesystem è composto da un insieme di blocchi, la struttura generale è
-riportata in \nfig; su ciascun gruppo di blocchi contiene una copia delle
-informazioni essenziali del filesystem (superblock e descrittore del
-filesystem) per una maggiore affidabilità e possibilità di recupero in caso di
-corruzione del superblock principale.
+La struttura di \acr{ext2} è stata ispirata a quella del filesystem di BSD,
+un filesystem è composto da un insieme di blocchi, la struttura generale è
+quella riportata in \figref{fig:file_filesys_detail}, in cui la partizione
+è divisa in gruppi di blocchi.
+
+Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
+filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
+una maggiore affidabilità e possibilità di recupero in caso di corruzione del
+superblock principale.
\begin{figure}[htb]
\centering
-
- \caption{Organizzazione logica del \textit{second extented filesystem}.}
- \label{fig:fileintr_ext2_struct}
+ \includegraphics[width=9cm]{img/dir_struct}
+ \caption{Struttura delle directory nel \textit{second extented filesystem}.}
+ \label{fig:file_ext2_dirs}
\end{figure}
-L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
-performance dato che viene ridotta la distanza fra i dati e la tabella degli
-inodes.
-
-Le directory sono implementate come una linked list di entrate di dimensione
-variabile. Ciascuna entry contiene il numero di inode, la sua lunghezza, il
-nome del file e la sua lunghezza.
-
-
+L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle
+prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli
+inode.
+Le directory sono implementate come una linked list con voci di dimensione
+variabile. Ciascuna voce della lista contiene il numero di inode, la sua
+lunghezza, il nome del file e la sua lunghezza, secondo lo schema in \curfig;
+in questo modo è possibile implementare nomi per i file anche molto lunghi
+(fino a 1024 caratteri) senza sprecare spazio disco.
projects / gapil.git / blobdiff