-
\chapter{I files: l'architettura}
\label{cha:files_intro}
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:fileintr_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.
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
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}.
\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
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:fileintr_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}.
+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
Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
\begin{figure}[htb]
\centering
-
+ \includegraphics[width=7cm]{img/vfs.eps}
\caption{Schema delle operazioni del VFS}
- \label{fig:fileintro_VFS_scheme}
+ \label{fig:fileintr_VFS_scheme}
\end{figure}
Il VFS definisce un insieme di funzioni che tutti i filesystem devono
(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:fileintr_ext2}), inizializzare tutte le
variabili interne e restituire uno speciale descrittore dei filesystem montati
al VFS; attraverso quest'ultimo diventa possible accedere alle routine
specifiche per l'uso di quel filesystem.
\begin{table}[htb]
\centering
- \begin{tabular}[c]{c p{7cm}}
+ \begin{tabular}[c]{|c|p{7cm}|}
+ \hline
\textbf{funzione} & \textbf{operazione} \\
\hline
+ \hline
\textit{open} & apre il file \\
\textit{read} & legge dal file \\
\textit{write} & scrive sul file \\
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 ext2, che prevede una separazione dei dati in
+\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di
+ext2 torneremo in \secref{sec:fileintr_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.eps}
\caption{Organizzazione dello spazio su un disco in partizioni e filesystem}
\label{fig:fileintr_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}
+ \includegraphics[width=11cm]{img/filesys_struct.eps}
+ \caption{Strutturazionne dei dati all'interno di un filesystem}
\label{fig:fileintr_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 seguitp; in particolare è opportuno ricordare sempre che:
\begin{enumerate}
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
+situazione mostrata in \curfig\ creiamo una nuova directory \texttt{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.eps}
+ \caption{Organizzazione dei link per le directory}
+ \label{fig:fileintr_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
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:fileintr_ext2}
Il filesystem standard usato da Linux è il cosidetto \textit{second extended
- filesystem}, identificato dalla sigla \texttt{ext2}. Esso supporta tutte le
+ filesystem}, identificato dalla sigla \textsl{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
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 \textsl{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
con lo stesso identificatore di gruppo della directory che li contiene. La
semantica SysV 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
+ di sgid settato (per una descrizione dettagliata del significato di questi
termini si veda \secref{sec:filedir_access_control}), nel qual caso file e
- sottodirectory ereditano sia il group id che il setgid.
+ sottodirectory ereditano sia il group id che il 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 \textsl{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:fileintr_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.eps}
+ \caption{Struttura delle directory nel \textit{second extented filesystem}.}
+ \label{fig:fileintr_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
+prestazioni 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.
-
+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