varie caratteristiche distintive.
\section{L'organizzazione di files e directories}
-\label{sec:fileintr_organization}
+\label{sec:file_organization}
Il primo passo nella trattazione dell'achitettura della gestione dei file in
un sistema unix-like, è quello dell'esame di come essi vengono organizzati e
\subsection{La struttura di files e directory}
-\label{sec:fileintr_filedir_struct}
+\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 descriviremo 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
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
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 \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); 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
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}
+\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:fileintr_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.
\hline
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
- \label{tab:fileintr_file_types}
+ \label{tab:file_file_types}
\end{center}
\end{table}
\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
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}.
+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
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
devono essere usati i file descriptor se si vuole ricorrere a modalità
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.
\section{L'architettura della gestione dei file}
-\label{sec:fileintr_architecture}
+\label{sec:file_architecture}
Per capire fino in fondo le proprietà di files e directories in un sistema
unix-like ed il funzionamento delle relative funzioni di manipolazione occorre
In questa sezione esamineremo come viene implementato l'accesso ai files 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
\centering
\includegraphics[width=7cm]{img/vfs.eps}
\caption{Schema delle operazioni del VFS}
- \label{fig:fileintr_VFS_scheme}
+ \label{fig:file_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:fileintr_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
specifiche per l'uso di quel filesystem.
\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
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
+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
+una struttura di tipo \var{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
+torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle operazioni
previste dal kernel è riportato in \ntab.
\begin{table}[htb]
\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
\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
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
+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.
\centering
\includegraphics[width=9cm]{img/disk_struct.eps}
\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 con maggiore dettaglio la strutturazione
\centering
\includegraphics[width=11cm]{img/filesys_struct.eps}
\caption{Strutturazionne dei dati all'interno di un filesystem}
- \label{fig:fileintr_filesys_detail}
+ \label{fig:file_filesys_detail}
\end{figure}
Da \curfig\ si evidenziano alcune caratteristiche base di ogni filesystem su
\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}).
+ 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
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{img} nella
+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.
\centering
\includegraphics[width=11cm]{img/dir_links.eps}
\caption{Organizzazione dei link per le directory}
- \label{fig:fileintr_dirs_link}
+ \label{fig:file_dirs_link}
\end{figure}
La nuova directory avrà allora un numero di riferimenti pari a due, in quanto
adesso sarà referenziata anche dalla voce \file{..} di \file{img}.
\subsection{Il filesystem \textsl{ext2}}
-\label{sec:fileintr_ext2}
+\label{sec:file_ext2}
Il filesystem standard usato da Linux è il cosidetto \textit{second extended
filesystem}, identificato dalla sigla \textsl{ext2}. Esso supporta tutte le
filenames lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
4~Tb.
-Oltre alle caratteristiche standard \textsl{ext2} fornisce alcune estensioni
+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}
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 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 sgid.
+ termini si veda \secref{sec:file_access_control}), nel qual caso file e
+ sottodirectory 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
permettono un accesso più veloce, ma sprecano più spazio disco).
log).
\end{itemize}
-La struttura di \textsl{ext2} è stata ispirata a quella del filesystem di BSD,
+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:fileintr_filesys_detail}, in cui la partizione
+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
\centering
\includegraphics[width=9cm]{img/dir_struct.eps}
\caption{Struttura delle directory nel \textit{second extented filesystem}.}
- \label{fig:fileintr_ext2_dirs}
+ \label{fig:file_ext2_dirs}
\end{figure}
L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle
projects / gapil.git / blobdiff