-\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}
+\section{L'organizzazione di file e directory}
\label{sec:file_organization}
-Il primo passo nella trattazione dell'achitettura della gestione dei file in
+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}
+\subsection{La struttura di file e directory}
\label{sec:file_file_struct}
Partiamo allora da come viene strutturata nel sistema la disposizione dei
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:file_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
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 \file{/dev}).
sia la directory radice allora il riferimento è a se stessa.
-\subsection{I tipi di files}
+\subsection{I tipi di file}
\label{sec:file_file_types}
Come detto in precedenza in unix esistono vari tipi di file, in Linux questi
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) \\
\end{tabular}
\caption{Tipologia dei file definiti nel VFS}
\label{tab:file_file_types}
- \end{center}
\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.
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.
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
\section{L'architettura della gestione dei file}
\label{sec:file_architecture}
-Per capire fino in fondo le proprietà di files e directories in un sistema
+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'\acr{ext2}, come esempio di un filesystem unix-like.
\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 utilizzarà 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.
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
nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco
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
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
+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 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
+Le 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 inodes che stanno in memoria sono inodes del VFS
+all'indietro sul disco, gli inode che stanno in memoria sono inode 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
+file, 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.
\begin{table}[htb]
\centering
- \begin{tabular}[c]{|c|p{7cm}|}
+ \footnotesize
+ \begin{tabular}[c]{|l|p{7cm}|}
\hline
- \textbf{funzione} & \textbf{operazione} \\
+ \textbf{Funzione} & \textbf{Operazione} \\
\hline
\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}.
+ \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.}
\begin{figure}[htb]
\centering
\includegraphics[width=11cm]{img/filesys_struct.eps}
- \caption{Strutturazionne dei dati all'interno di un filesystem}
+ \caption{Strutturazione dei dati all'interno di un filesystem}
\label{fig:file_filesys_detail}
\end{figure}
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:
+torneremo in seguito; in particolare è opportuno ricordare sempre che:
\begin{enumerate}
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
+ 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
\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
+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.
è referenziata dalla directory da cui si era partiti (in cui è inserita la
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 \file{..} di \file{img}.
\subsection{Il filesystem \textsl{ext2}}
\label{sec:file_ext2}
-Il filesystem standard usato da Linux è il cosidetto \textit{second extended
+Il filesystem standard usato da Linux è il cosiddetto \textit{second extended
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
+filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a
4~Tb.
Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni
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 SYSV 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 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:file_access_control}), nel qual caso file e
- sottodirectory ereditano sia il \acr{gid} che lo \acr{sgid}.
+ sotto-directory 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).
projects / gapil.git / blobdiff