X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=794d61159b96fe74cb463c39be53c3697fbdc405;hp=a55e5ac9c313e546e36704882afdea65e496d04d;hb=7e77cdaacc8c84ecfeac4aa22977b7fa34741b5c;hpb=247c7ba624f39b283f9e85816c0616348f39c1b6 diff --git a/fileintro.tex b/fileintro.tex index a55e5ac..794d611 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -122,11 +122,26 @@ 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_work}) e sono presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal -\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab. +\textit{Virtual File System}\index{Virtual File System} è riportato in +\tabref{tab:file_file_types}. Si tenga ben presente che questa classificazione non ha nulla a che fare con -la classificazione sui tipi di file (che in questo caso sono sempre file di -dati) in base al loro contenuto, o tipo di accesso. +la classificazione dei file (che in questo caso sono sempre file di dati) in +base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di +oggetti; in particolare è da notare la presenza dei cosiddetti file speciali. +Alcuni di essi, come le \textit{fifo} (che tratteremo in +\secref{sec:ipc_named_pipe}) ed i \textit{socket} (che tratteremo in +\capref{cha:socket_intro}) non sono altro che dei riferimenti per utilizzare +delle funzionalità di comunicazione fornite dal kernel. Gli altri sono i +\textsl{file di dispositivo} (o \textit{device file}) che costituiscono una +interfaccia diretta per leggere e scrivere sui dispositivi fisici; essi +vengono suddivisi in due grandi categorie, \textsl{a blocchi} e \textsl{a + caratteri} a seconda delle modalità in cui il dispositivo sottostante +effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi + (ad esempio i dischi) corrispondono a periferiche per le quali è richiesto + che l'I/O venga effettuato per blocchi di dati di dimensioni fissate (ad + esempio le dimensioni di un settore), mentre nei dispositivi a caratteri + l'I/O viene effettuato senza nessuna particolare struttura.} \begin{table}[htb] \footnotesize @@ -159,16 +174,20 @@ dati) in base al loro contenuto, o tipo di accesso. \label{tab:file_file_types} \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 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 - kernel della serie 2.4 è disponibile, attraverso dei device file appositi, - una forma di accesso diretto ai dischi (il \textit{raw access}) che però non - ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza - passare attraverso un filesystem.} +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 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{questo vale + anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di + dimensione fissa avviene solo all'interno del kernel, ed è completamente + trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso + diretto} riferendosi alla capacità, che non ha niente a che fare con tutto + ciò, di effettuare, attraverso degli appositi file di dispositivo, + operazioni di I/O direttamente sui dischi senza passare attraverso un + filesystem (il cosiddetto \textit{raw access}, introdotto coi kernel della + serie 2.4.x).} Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è codificata in maniera diversa da Windows o Mac, in particolare il fine riga è @@ -179,12 +198,21 @@ del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux problemi qualora nei programmi si facciano assunzioni sul terminatore della riga. -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ò nonostante 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 è, per quanto usata ed accettata in maniera -universale, solo una convenzione. +Si ricordi infine che un kernel Unix non fornisce nessun supporto per la +tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le +estensioni come parte del filesystem.\footnote{non è così ad esempio nel + filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file, + che specificano fra l'altro il contenuto ed il programma da usare per + leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la + possibilità di associare delle risorse ai file, ma è una caratteristica + tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei + file in un sistema Unix.} Ciò nonostante 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}; un'altra tecnica molto usata è quella di +utilizzare i primi 4 byte del file per memorizzare un \textit{magic number} +che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed +accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è +demandato alle applicazioni stesse. \subsection{Le due interfacce ai file} @@ -443,7 +471,8 @@ 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:file_fd}). Un elenco delle -operazioni previste dal kernel è riportato in \ntab. +operazioni previste dal kernel è riportato in +\tabref{tab:file_file_operations}. \begin{table}[htb] \centering @@ -505,17 +534,18 @@ alle caratteristiche comuni di qualunque filesystem di sistema unix-like. 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 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. +dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys}; +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 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=12cm]{img/disk_struct} + \includegraphics[width=14cm]{img/disk_struct} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem.} \label{fig:file_disk_filesys} @@ -525,20 +555,21 @@ 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. +esemplificare la situazione con uno schema come quello esposto in +\figref{fig:file_filesys_detail}. \begin{figure}[htb] \centering - \includegraphics[width=12cm]{img/filesys_struct} + \includegraphics[width=14cm]{img/filesys_struct} \caption{Strutturazione dei dati all'interno di un filesystem.} \label{fig:file_filesys_detail} \end{figure} -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: +Da \figref{fig:file_filesys_detail} 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} @@ -551,15 +582,15 @@ ricordare sempre che: traduzione 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 - 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 - effettivamente rimossi dal disco. Per questo la funzione per cancellare un - file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del - file, ma si limita ad eliminare la relativa voce da una directory e - decrementare il numero di riferimenti nell'\textit{inode}. + +\item Come mostrato in \figref{fig:file_filesys_detail} 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 effettivamente rimossi dal disco. Per questo la funzione per + cancellare un file si chiama \func{unlink}, ed in realtà non cancella + affatto i dati del file, ma si limita ad 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 @@ -577,13 +608,14 @@ ricordare sempre che: 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. +mostrata in \figref{fig:file_filesys_detail} creiamo una nuova directory +\file{img} nella directory \file{gapil}, avremo una situazione come quella in +\figref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri di +inode. \begin{figure}[htb] \centering - \includegraphics[width=12cm]{img/dir_links} + \includegraphics[width=14cm]{img/dir_links} \caption{Organizzazione dei link per le directory.} \label{fig:file_dirs_link} \end{figure} @@ -658,9 +690,9 @@ inode. 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. +lunghezza, il nome del file e la sua lunghezza, secondo lo schema in +\figref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi per +i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio disco.