-\chapter{I file: l'architettura}
+\chapter{L'architettura dei file}
\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
-di input/output del computer viene effettuato attraverso un'interfaccia
-astratta che tratta le periferiche allo stesso modo degli usuali file di dati.
+Uno dei concetti fondamentali dell'architettura di un sistema Unix è il
+cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari
+dispositivi di input/output del computer viene effettuato attraverso
+un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali
+file di dati.
Questo significa che si può accedere a qualunque periferica del computer,
dalla seriale, alla parallela, alla console, e agli stessi dischi attraverso i
operazioni direttamente sulle periferiche, usando le stesse funzioni che si
usano per i normali file di dati.
-In questo capitolo forniremo un'introduzione all'architettura della gestione
-dei file, sia nelle sue caratteristiche generiche comuni a tutti gli unix, che
-nelle particolarità che ha la specifica implementazione usata da Linux. Al
-contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le
-varie caratteristiche distintive.
+In questo capitolo forniremo una panoramica dell'architettura dei file, sia
+nelle sue caratteristiche generali, comuni a tutti gli Unix, che nelle
+particolarità che ha la specifica implementazione usata da Linux.
-\section{L'organizzazione di file e directory}
-\label{sec:file_organization}
+\section{L'architettura dell'accesso ai file}
+\label{sec:file_access_arch}
-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.
+Per poter accedere ai file il kernel deve mettere a disposizione dei programmi
+le opportune interfacce che consentano di leggerne il contenuto; il sistema
+cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna
+l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene
+fatto strutturando l'informazione sul disco attraverso quello che si chiama un
+\textit{filesystem}, essa poi viene resa disponibile attraverso quello che
+viene chiamato il \textsl{montaggio} del filesystem.
+% (approfondiremo tutto ciò in \secref{sec:file_arch_func}).
+In questa sezione faremo una panormamica generica su come il sistema presenta
+i file ai processi, trattando l'organizzazione di file e directory, i tipi di
+file ed introducendo le interfacce disponibili, che saranno approfondite nei
+capitoli seguenti.
-\subsection{La struttura di file e directory}
+
+\subsection{L'organizzazione 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 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 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 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
-di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato
-dall'utente usando quello che viene chiamato \textit{pathname}, cioè il
-percorso che si deve fare per accedere al file.
+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 (quella che
+viene chiamata \textit{root directory}) viene montata all'avvio. Pertanto
+un file viene identificato dall'utente usando quello che viene chiamato
+\textit{pathname}, cioè il percorso che si deve fare per accedere al file.
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 \file{/}); tutti gli ulteriori dischi devono poi essere inseriti
-nell'albero utilizzando opportune subdirectory.
+directory \file{/}); tutti gli ulteriori filesystem che possono essere su
+altri dispositivi devono poi essere inseriti nell'albero utilizzando opportune
+subdirectory.
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 file 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 \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:file_vfs}, è solo un particolare tipo di file
-che contiene le informazioni che associano un nome al contenuto.
+medesimi nell'albero descritto in precedenza; una directory comunque, come
+vedremo in \secref{sec:file_vfs_work}, è 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à
% una directory contiene solo delle etichette per fare riferimento ai file
% stessi.
-I manuale delle glibc chiama i nomi contenuti nelle directory
+I manuale delle \acr{glibc} chiama i nomi contenuti nelle directory
\textsl{componenti} (in inglese \textit{file name components}), noi li
chiameremo più semplicemente \textit{nomi}. Un file può essere indicato
rispetto alla directory corrente semplicemente specificando il nome da essa
directory.
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
- resolution}). La risoluzione viene fatta esaminando il pathname da destra a
-sinistra e localizzando ogni nome nella directory indicata dal nome
-precedente: ovviamente perché il procedimento funzioni occorre che i nomi
-indicati come directory esistano e siano effettivamente directory, inoltre i
-permessi devono consentire l'accesso.
+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 \acr{glibc} depreca questa
+nomenclatura\footnote{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 procedimento con cui si associa ad un pathname uno specifico file è
+chiamato risoluzione del nome (\textit{file name resolution} o
+\textit{pathname resolution}). La risoluzione viene fatta esaminando il
+pathname da destra a sinistra e localizzando ogni nome nella directory
+indicata dal nome precedente: ovviamente perché il procedimento funzioni
+occorre che i nomi indicati come directory esistano e siano effettivamente
+directory, inoltre i permessi devono consentire l'accesso.
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
+seguito, vedi \secref{sec:file_chroot}) è la stessa per tutti i processi ed
equivale alla directory radice dell'albero (come descritto in
\secref{sec:file_organization}): in questo caso si parla di un pathname
\textsl{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su
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:file_vfs}) e sono presenti in tutti i filesystem unix-like
+\secref{sec:file_vfs_work}) 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.
\textit{regular file} & \textsl{file normale} &
un file che contiene dei dati (l'accezione normale di file) \\
\textit{directory} & \textsl{cartella o direttorio} &
- un file che contiene una lista di nomi associati a degli inodes \\
+ un file che contiene una lista di nomi associati a degli \textit{inodes}
+ (vedi \secref{sec:file_vfs}). \\
\textit{symbolic link} & \textsl{collegamento simbolico} &
un file che contiene un riferimento ad un altro file/directory \\
\textit{char device} & \textsl{dispositivo a caratteri} &
\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 (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 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_noblocking}).
+altri oggetti del VFS (pipe, socket, device, sui quali torneremo in dettaglio
+a tempo opportuno), 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 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_noblocking}).
Gli stream forniscono un'interfaccia di alto livello costruita sopra quella
dei file descriptor, che tratta tutti i file nello stesso modo, con
\section{L'architettura della gestione dei file}
-\label{sec:file_architecture}
+\label{sec:file_arch_func}
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
\end{figure}
Il VFS definisce un insieme di funzioni che tutti i filesystem devono
-implementare. L'interfaccia comprende tutte le funzioni che riguardano i
-file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode
-e file, corrispondenti a tre apposite strutture definite nel kernel.
+implementare. L'interfaccia comprende tutte le funzioni che riguardano i file;
+le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem},
+\textit{inode} e \textit{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 è chiamare la funzione
-\func{register\_filesystem} passandole un'apposita struttura
+\code{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
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
+Questo procedimento viene eseguito dal metodo \code{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.
\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
+ \textsl{\code{open}} & apre il file \\
+ \textsl{\code{read}} & legge dal file \\
+ \textsl{\code{write}} & scrive sul file \\
+ \textsl{\code{llseek}} & sposta la posizione corrente sul file \\
+ \textsl{\code{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}.
+ \textsl{\code{readdir}}& per leggere il contenuto di una directory \\
+ \textsl{\code{poll}} & \\
+ \textsl{\code{mmap}} & chiamata dalla system call \func{mmap}.
mappa il file in memoria\\
- \textsl{\func{release}}& chiamata quando l'ultima referenza a un file
+ \textsl{\code{release}}& chiamata quando l'ultima referenza a un file
aperto è chiusa\\
- \textsl{\func{fsync}} & chiamata dalla system call \func{fsync} \\
- \textsl{\func{fasync}} & chiamate da \func{fcntl} quando è abilitato
+ \textsl{\code{fsync}} & chiamata dalla system call \func{fsync} \\
+ \textsl{\code{fasync}} & chiamate da \func{fcntl} quando è abilitato
il modo asincrono per l'I/O su file. \\
\hline
\end{tabular}
Così sarà possibile scrivere sulla porta seriale come su un file di dati
normale; ovviamente certe operazioni (nel caso della seriale ad esempio la
-\func{seek}) non saranno disponibili, però con questo sistema l'utilizzo di
+\code{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.
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 è
+filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è
quella di poter supportare grazie al VFS una enorme quantità di filesystem
diversi, ognuno dei quali ha una sua particolare struttura e funzionalità
proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma
+
+%%% Local Variables:
+%%% mode: latex
+%%% TeX-master: "gapil"
+%%% End:
projects / gapil.git / blobdiff