filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti
corrispondono una serie di apposite strutture definite dal kernel che
contengono come campi le funzioni di gestione e realizzano l'infrastruttura
-del VFS. L'interfaccia è estremamente complessa, ne faremo pertanto una
-trattazione estremamente semplificata che consenta di comprenderne i principi
+del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione
+estremamente semplificata che consenta di comprenderne i principi
difunzionamento.
Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun
La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni,
come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che
viene riportato in \procfile{/proc/filesystems} e che viene usato come
- parametro dell'opzione \texttt{-t} del comando \texttt{mount}.} contiene i
-riferimenti alle funzioni di base che consentono l'utilizzo di quel
-filesystem. In particolare la funzione \code{mount} del quarto campo è quella
-che verrà invocata tutte le volte che si dovrà effettuare il montaggio di un
-filesystem di quel tipo. Per ogni nuovo filesystem si dovrà allocare una di
-queste strutture ed inizializzare i relativi campi con i dati specifici diquel
-filesystem, ed in particolare si dovra creare anche la relativa versione della
-funzione \code{mount}.
+ valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che
+ indica il tipo di filesystem.} contiene i riferimenti alle funzioni di base
+che consentono l'utilizzo di quel filesystem. In particolare la funzione
+\code{mount} del quarto campo è quella che verrà invocata tutte le volte che
+si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo
+filesystem si dovrà allocare una di queste strutture ed inizializzare i
+relativi campi con i dati specifici di quel filesystem, ed in particolare si
+dovrà creare anche la relativa versione della funzione \code{mount}.
Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione
restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory
\textit{pathname} e contiene il riferimento ad un \textit{inode}, che come
vedremo a breve è l'oggetto usato dal kernel per identificare un un
file.\footnote{in questo caso si parla di file come di un qualunque oggetto
- generico che sta sul filesystem.} La \textit{dentry} ottenuta dalla chiamata
-alla funzione \code{mount} sarà inserita in corrispondenza al
-\textit{pathname} della directory in cui il filesystem è stato montato.
+ generico che sta sul filesystem e non dell'oggetto file del VFS cui
+ accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione
+\code{mount} sarà inserita in corrispondenza al \textit{pathname} della
+directory in cui il filesystem è stato montato.
% NOTA: struct dentry è dichiarata in include/linux/dcache.h
\textit{pathname} viene effettuata una ricerca nella \textit{dcache} per
ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon
funzionamento della \textit{dcache} è in effetti di una delle parti più
- critiche per le prestazioni del sistema.} che a sua ci darà, tramite
+ critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite
l'\textit{inode}, il riferimento al file.
Dato che normalmente non è possibile mantenere nella \textit{dcache} le
trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel.
Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè
-è un puntatore ad una funzione, e, come suggerisce il nome della struttura
-stessa, queste funzioni, le principali delle quali sono riportate in
-tab.~\ref{tab:file_inode_operations}) sono quelle che definiscono le
-operazioni che il VFS può compiere su un \textit{inode}.
+è un puntatore ad una funzione e, come suggerisce il nome della struttura
+stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS
+può compiere su un \textit{inode}. Si sono riportate in
+tab.~\ref{tab:file_inode_operations} le più rilevanti.
\begin{table}[htb]
\centering
Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente
identici alle varie \textit{system call} con le quali si gestiscono file e
-directory che tratteremo nel resto del capitolo. Quello che succede è che
+directory, che tratteremo nel resto del capitolo. Quello che succede è che
tutte le volte che deve essere eseguita una \textit{system call}, o una
qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS
andrà ad utilizzare la funzione corrispondente attraverso il puntatore
\var{i\_op}.
Sarà allora sufficiente che nella realizzazione di un filesystem si crei una
-opportuna istanza di \kstruct{inode\_operation} contenente i puntatori alla
-implementazione di queste funzioni per quel filesystem e quel punto le
-strutture \kstruct{inode} usate per gli oggetti di quel filesystem otterranno
-il puntatore a detta istanza di \kstruct{inode\_operation} e verranno
-automaticamente usate le funzioni corrette.
+implementazione di queste funzioni per quel filesystem e si allochi una
+opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette
+funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di
+quel filesystem otterranno il puntatore alla relativa istanza di
+\kstruct{inode\_operation} e verranno automaticamente usate le funzioni
+corrette.
Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la
funzione \texttt{open} che invece è citata in
invocata dato che nella struttura \kstruct{inode} è presente anche il
puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che
fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un
-file richiede comunque un'altra operazione: l'allocazione di una struttura di
-tipo \kstruct{file} che viene associata ad ogni file aperto nel sistema.
+file richiede comunque un'altra operazione che mette in gioco l'omonimo
+oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che
+viene associata ad ogni file aperto nel sistema.
I motivi per cui viene usata una struttura a parte sono diversi, anzitutto,
come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le
sui file allo stesso modo indipendentemente dal filesystem.
Il VFS realizza la quasi totalità delle operazioni relative ai file grazie
-alle funzioni presenti nelle due strutture \kstruct{inode\_operation}
+alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e
\kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni
possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek}
non è realizzabile per un dispositivo come la porta seriale o per una fifo,
daremo una descrizione a grandi linee che si adatta alle caratteristiche
comuni di qualunque filesystem di un sistema unix-like.
-Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
-partizione può contenere un filesystem. Una possibile strutturazione
-dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys},
-in essa per semplicità si è fatto riferimento alla struttura del filesystem
-\acr{ext2}, che prevede una separazione dei dati in \textit{block group} che
-replicano il cosiddetto \textit{superblock} (sulle caratteristiche di
-\acr{ext2} e derivati torneremo in sez.~\ref{sec:file_ext2}). È comunque
-caratteristica comune di tutti i filesystem per Unix, indipendentemente da
-come poi viene strutturata nei dettagli questa informazione, prevedere una
-divisione fra la lista degli \itindex{inode} \textit{inode} e lo spazio a
-disposizione per i dati e le directory.\footnote{questo non è del tutto vero
- per filesystem evoluti come \textsl{btrfs}, ma per il momento limitiamoci
- alla implementazione classica.}
+Una possibile strutturazione dell'informazione su un disco è riportata in
+fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre
+partizioni. In essa per semplicità si è fatto riferimento alla struttura del
+filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block
+ group}. All'interno di ciascun \textit{block group} viene anzitutto
+replicato il cosiddetto \textit{superblock}, (la struttura che contiene
+l'indice iniziale del filesystem e che consente di accedere a tutti i dati
+sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni
+per accedere agli stessi. Sulle caratteristiche di \acr{ext2} e derivati
+torneremo in sez.~\ref{sec:file_ext2}.
+
+È comunque caratteristica comune di tutti i filesystem per Unix,
+indipendentemente da come poi viene strutturata nei dettagli questa
+informazione, prevedere la presenza di due tipi di risorse: gli
+\itindex{inode} \textit{inode}, cui abbiamo già accennato in
+sez.~\ref{sec:file_vfs_work}, che sono le strutture che identificano i singoli
+oggetti sul filesystem, e i blocchi, che invece attengono allo spazio disco
+che viene messo a disposizione per i dati in essi contenuti.
\begin{figure}[!htb]
\centering
- \includegraphics[width=14cm]{img/disk_struct}
+ \includegraphics[width=12cm]{img/disk_struct}
\caption{Organizzazione dello spazio su un disco in partizioni e
filesystem.}
\label{fig:file_disk_filesys}
\end{figure}
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
-fig.~\ref{fig:file_filesys_detail}.
+dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i
+dettagli relativi al funzionamento del filesystem stesso come la
+strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di
+gestione possiamo esemplificare la situazione con uno schema come quello
+esposto in fig.~\ref{fig:file_filesys_detail}.
\begin{figure}[!htb]
\centering
\end{figure}
Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle
-caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
-visto che sono fondamentali per capire il funzionamento delle funzioni che
-manipolano i file e le directory che tratteremo nel prossimo capitolo; in
-particolare è opportuno ricordare sempre che:
+caratteristiche di base di un filesystem, che restano le stesse anche su
+filesystem la cui organizzazione dei dati è totalmente diversa da quella
+illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali
+per capire il funzionamento delle funzioni che manipolano i file e le
+directory che tratteremo nel prosieguo del capitolo. In particolare è
+opportuno tenere sempre presente che:
\begin{enumerate}
-\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i
- cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
+\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni, i
+ cosiddetti \textsl{metadati}, 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 \func{stat}
(vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}.
Dentro una directory si troverà solo il nome del file e il numero
\itindex{inode} dell'\textit{inode} ad esso associato, cioè quella che da
- qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
- \textit{directory entry}, che non useremo anche per evitare confusione con
- le \textit{dentry} del kernel di cui si parlava in
- sez.~\ref{sec:file_vfs_work}).
+ qui in poi chiameremo una \textsl{voce}, che abbiamo scelto come traduzione
+ dell'inglese \textit{directory entry}, che non useremo anche per evitare
+ confusione con le \textit{dentry} del kernel di cui si parlava in
+ sez.~\ref{sec:file_vfs_work}.
\item Come mostrato in fig.~\ref{fig:file_filesys_detail} si possono avere più
voci che puntano allo stesso \textit{inode}. Ogni \textit{inode} ha un
file, ma si limita ad eliminare la relativa voce da una directory e
decrementare il numero di riferimenti \itindex{inode} 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 \itindex{inode} \textit{inode} relativi ad altri filesystem.
- Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
- file esistente con la funzione \func{link}) al filesystem corrente.
+\item All'interno di ogni filesystem ogni \textit{inode} è identificato da un
+ numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un
+ \textit{inode} a questo numero e non ci può essere una directory che
+ contiene riferimenti ad \itindex{inode} \textit{inode} relativi ad altri
+ filesystem. Questo limita 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 viene spostato fisicamente, viene semplicemente creata una
projects / gapil.git / blobdiff