X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=40d8e2575d262890ff440b6f165c95eb1f563537;hp=010add3be64c39094d05bed03863814924d91641;hb=6db03808a639644251507d0f90f953117f893866;hpb=470f15a82390d6120981e85202f45fc102f3e8a3 diff --git a/fileintro.tex b/fileintro.tex index 010add3..40d8e25 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -176,7 +176,8 @@ Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di dati e che non c'è nessun supporto del sistema 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 \file{.c}, ma questa è, appunto, solo una convenzione. +l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera +universale, solo una convenzione. @@ -296,23 +297,23 @@ POSIX.1 dei sistemi Unix, ed Per capire fino in fondo le proprietà di file e directory in un sistema unix-like ed il comportamento delle relative funzioni di manipolazione occorre una breve introduzione al funzionamento gestione dei file da parte del kernel -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}. +e sugli oggetti su cui è basato un filesystem. 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 file in Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo -prima le caratteristiche generali di un filesystem Unix, per poi trattare in -maniera un po' più dettagliata il filesystem standard di Linux, l'\acr{ext2}. +prima le caratteristiche generali di un filesystem di un sistema unix-like, +per poi trattare in maniera un po' più dettagliata il filesystem standard di +Linux, l'\acr{ext2}. +% 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:file_vfs}. -% 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:file_vfs}. - -\subsection{Il \textit{virtual filesystem} di Linux} +\subsection{Il \textit{Virtual Filesystem} di Linux} \label{sec:file_vfs} % Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i @@ -322,13 +323,14 @@ maniera un po' pi % \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 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 +attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno +strato intermedio che il kernel usa per accedere ai più svariati filesystem +mantenendo la stessa interfaccia per i programmi in user space. 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 +queste ultime nei vari modi in cui diversi filesystem le 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 @@ -361,17 +363,17 @@ 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 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 possibile accedere alle routine -specifiche per l'uso di quel filesystem. +il superblock (vedi \secref{sec:file_ext2}), inizializzare tutte le variabili +interne e restituire uno speciale descrittore dei filesystem montati 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 una apposita struttura che contiene vari dati come le informazioni comuni ad ogni filesystem, i dati privati relativi a quel filesystem specifico, e i puntatori alle funzioni del kernel relative al filesystem. Il VFS può così -usare le funzioni contenute nel filesystem descriptor per accedere alle routine -specifiche di quel filesystem. +usare le funzioni contenute nel \textit{filesystem descriptor} per accedere +alle routine specifiche di quel filesystem. Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti su cui è strutturata l'interfaccia. Ciascuno di essi contiene le informazioni @@ -386,28 +388,28 @@ file gi \subsection{Il funzionamento del VFS} \label{sec:file_vfs_work} -La funzione più fondamentale implementata dal VFS è la system call -\func{open} che permette di aprire un file. Dato un pathname viene eseguita -una ricerca dentro la \textit{directory entry cache} (in breve -\textit{dcache}), una tabella di hash che contiene tutte le \textit{directory - entry} (in breve \textit{dentry}) che permette di associare in maniera -rapida ed efficiente il pathname a una specifica dentry. +La funzione più importante implementata dal VFS è la system call \func{open} +che permette di aprire un file. Dato un pathname viene eseguita una ricerca +dentro la \textit{directory entry cache} (in breve \textit{dcache}), una +tabella che contiene tutte le \textit{directory entry} (in breve +\textit{dentry}) che permette di associare in maniera rapida ed efficiente il +pathname a una specifica \textit{dentry}. Una singola \textit{dentry} contiene in genere il puntatore ad un \textit{inode}; quest'ultimo è la struttura base che sta sul disco e che identifica un singolo oggetto del VFS sia esso un file ordinario, una directory, un link simbolico, una FIFO, un file di dispositivo, o una -qualsiasi altra cosa che possa essere rappresentata dal 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. +qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di +``file'' riportati in \tabref{tab:file_file_types}). A ciascuno di essi è +associata pure una struttura che sta in memoria, e che, oltre alle +informazioni sullo specifico file, contiene anche il riferimento alle funzioni +(i \textsl{metodi} del VFS) da usare per poterlo manipolare. Le \textit{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 inode che stanno in memoria sono inode del VFS ed -è ad essi che puntano le singole \textit{dentry}. +vengono usate per motivi di velocità, gli \textit{inode} invece stanno su +disco e vengono copiati in memoria quando serve, ed ogni cambiamento viene +copiato all'indietro sul disco, gli inode che stanno in memoria sono inode del +VFS ed è ad essi che puntano le singole \textit{dentry}. La \textit{dcache} costituisce perciò una sorta di vista completa di tutto l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è @@ -421,9 +423,9 @@ 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 -\func{open} per aprire il file o la \func{stat} per leggere i dati +Una volta che il VFS ha a disposizione la \textit{dentry} (ed il relativo +\textit{inode}) diventa possibile accedere alle varie operazioni sul file come +la \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 @@ -464,44 +466,45 @@ operazioni previste dal kernel \label{tab:file_file_operations} \end{table} -In questo modo per ciascun file diventano utilizzabili una serie di operazioni -(non è dette che tutte siano disponibili), che costituiscono l'interfaccia -astratta del VFS, e qualora se ne voglia eseguire una il kernel andrà ad +In questo modo per ciascun file diventano possibili una serie di operazioni +(non è detto che tutte siano disponibili), che costituiscono l'interfaccia +astratta del VFS. Qualora se ne voglia eseguire una il kernel andrà ad utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo -di file in questione. +di file in questione. -Così sarà possibile scrivere sulla porta seriale come su un file di dati -normale; ovviamente certe operazioni (nel caso della seriale ad esempio la -\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. +In questo modo è possibile scrivere allo stesso modo sulla porta seriale come +su un file di dati normale; ovviamente certe operazioni (nel caso della +seriale ad esempio la \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. -\subsection{Il funzionamento di un filesystem unix} +\subsection{Il funzionamento di un filesystem Unix} \label{sec:file_filesystem} -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 +Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema +unix-like) 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 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità -proprie; per questo non entreremo nei dettagli di un filesystem specifico, ma -daremo una descrizione a grandi linee che si adatta alle caratteristiche -comuni di un qualunque filesystem standard unix. +proprie. Per questo per il momento non entreremo nei dettagli di un +filesystem specifico, ma daremo una descrizione a grandi linee che si adatta +alle caratteristiche comuni di qualunque filesystem di sistema unix-like. -Dato un disco lo spazio fisico viene usualmente diviso in partizioni; ogni -partizione può contenere un filesystem; la strutturazione tipica +Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni +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 \acr{ext2}, che prevede una separazione dei dati in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica -comune di tutti i filesystem unix, indipendentemente da come poi viene +comune di tutti i filesystem per 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} + \includegraphics[width=12cm]{img/disk_struct} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} \label{fig:file_disk_filesys} \end{figure} @@ -514,15 +517,16 @@ esemplificare la situazione con uno schema come quello esposto in \nfig. \begin{figure}[htb] \centering - \includegraphics[width=11cm]{img/filesys_struct} + \includegraphics[width=12cm]{img/filesys_struct} \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 seguito; in particolare è opportuno ricordare sempre che: +Da \curfig\ 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: \begin{enumerate} @@ -535,8 +539,8 @@ torneremo in seguito; in particolare (traduzione approssimata dell'inglese \textit{directory entry}, che non 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 + +\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 numero di riferimenti (\textit{link count}) che sono stati fatti ad esso; solo quando questo contatore si annulla i dati del file vengono @@ -544,13 +548,13 @@ torneremo in seguito; in particolare 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 \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à @@ -559,15 +563,15 @@ torneremo in seguito; in particolare \end{enumerate} -Infine è bene avere presente che essendo file pure loro, esiste un numero di -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. +Infine è bene avere presente che, essendo file pure loro, esiste un numero di +riferimenti anche per le directory; per cui se 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. \begin{figure}[htb] \centering - \includegraphics[width=11cm]{img/dir_links} + \includegraphics[width=12cm]{img/dir_links} \caption{Organizzazione dei link per le directory} \label{fig:file_dirs_link} \end{figure} @@ -586,12 +590,11 @@ adesso sar Il filesystem standard usato da Linux è il cosiddetto \textit{second extended filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le -caratteristiche di un filesystem standard unix, è in grado di gestire -filename lunghi (256 caratteri, estendibili a 1012), una dimensione fino a -4~Tb. +caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di +file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb. -Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni -che non sono presenti sugli altri filesystem unix, le cui principali sono le +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} \item i \textit{file attributes} consentono di modificare il comportamento del @@ -620,7 +623,7 @@ seguenti: log). \end{itemize} -La struttura di \acr{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:file_filesys_detail}, in cui la partizione è divisa in gruppi di blocchi.