X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=a7df9939b1089dcc33a5f2889978a390bfd5252f;hp=4f5282680fa349d7f88ecc1aa43656036e5eb740;hb=056bbc90c8a0710b57fa7b13f5f0dfdad1b3ff3f;hpb=de73e63610d4ec307329b26c64467f27b6316688 diff --git a/fileintro.tex b/fileintro.tex index 4f52826..a7df993 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -6,7 +6,7 @@ Uno dei concetti fondamentali della architettura di unix di input/output del computer viene effettuato attraverso un'interfaccia astratta che tratta le periferiche allo stesso modo degli usuali file di dati. -Questo significa che si può accedere cioè a qualunque periferica del computer, +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 speciali agendo sui quali i programmi possono leggere, scrivere e compiere @@ -16,25 +16,23 @@ 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 -comtempo tratteremo l'organizzazione dei file in un sistema unix-like, e le +contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le varie caratteristiche distintive. - - \section{L'organizzazione di files e directories} -\label{sec:filedir_org} +\label{sec:fileintr_organization} -Visto il ruolo fondamentale che i files vengono ad assumere in un sistema -unix-like, è anzitutto opportuno fornire un'introduzione dettagliata su come -essi vengono organizzati all'interno del sistema. +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 +di quale è la struttura che hanno all'interno del sistema. -\subsection{Una breve introduzione} -\label{sec:fileintr_org_intro} +\subsection{La struttura di files e directory} +\label{sec:fileintr_filedir_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 strutturare l'informazione tenuta sullo spazio grezzo disponibile sui +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}. @@ -70,17 +68,12 @@ 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}). - -\subsection{La struttura di file e directories} -\label{sec:fileintr_filedir_struct} - L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei -medesimi nell'albero descritto brevemente in \secref{sec:fileintr_org_intro}; -una directory comunque, come già specificato in \secref{sec:fileintr_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à una directory contiene solo delle etichette per fare -riferimento ai file stessi. +medesimi nell'albero descritto in precedenza; una directory comunque, come già +specificato in \secref{sec:fileintr_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à una directory +contiene solo delle etichette per fare riferimento ai file stessi. I manuale delle glibc chiama i nomi contenuti nelle directory \textsl{componenti} (in inglese \textit{file name components}), noi li @@ -112,7 +105,7 @@ Se il pathname comincia per \texttt{/} 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 equivale alla directory radice dell'albero (come descritto in -\secref{sec:fileintr_overview}): in questo caso si parla di un pathname +\secref{sec:fileintr_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 è detto \textsl{relativo}. @@ -134,7 +127,12 @@ questa sia la directory radice allora il riferimento Come detto in precedenza in unix esistono vari tipi di file, in Linux questi sono implementati come oggetti del \textit{Virtual File System} e sono presenti in tutti i filesystem unix-like utilizzabili con Linux. L'elenco dei -vari tipi di file definiti dal Virtual File System è il seguente: +vari tipi di file definiti dal Virtual File System è riportato in \ntab. + +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. + \begin{table}[htb] \begin{center} @@ -164,10 +162,6 @@ vari tipi di file definiti dal Virtual File System \end{center} \end{table} -Si tenga ben presente che tutto ciò 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. - 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 @@ -281,7 +275,7 @@ accesso 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:filedir_link}) aprire un file provvisorio per +in dettaglio in \secref{sec:fileintr_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. @@ -298,30 +292,34 @@ una convenzione. \section{L'architettura della gestione dei file} -\label{sec:filedir_file_handling} +\label{sec:fileintro_architecture} Per capire fino in fondo le proprietà di files e directories in un sistema unix ed il funzionamento delle relative funzioni di manipolazione occorre una breve introduzione sulla gestione dei medesimo e sugli oggetti su cui è basato -un filesystem unix; 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}. - -In particolare occorre tenere presente dov'è che si situa la divisione -fondamentale fra kernel space e user space che tracciavamo al +un filesystem 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 allora come viene implementato l'accesso ai +files in Linux, come il kernel gestisce i vari filesystem, descrivendo poi in +maniera un po' più dettagliata il filesystem standard di Linux, +l'\texttt{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}. \subsection{Il \textit{virtual filesystem} di Linux} \label{sec:fileintr_vfs} -Esamineremo adesso come viene implementato l'accesso ai files in Linux. Questa -sezione riporta informazioni sui dettagli di come il kernel gestisce i files. -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}. +% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i +% files. 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 filesystem} (da qui in avanti VFS) che è @@ -433,10 +431,10 @@ diversi filesystem (come quelli usati da Windows o MacOs) \subsection{Il funzionamento di un filesystem unix} -\label{sec:filedir_filesystem} +\label{sec:fileintr_filesystem} -Come già accennato in \secref{sec:fileintr_overview} Linux (ed ogni unix in -generale) organizza i dati che tiene su disco attraverso l'uso di un +Come già accennato in \secref{sec:fileintr_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 diversi, ognuno dei quali ha una sua particolare struttura e funzionalità @@ -453,7 +451,7 @@ disposizione per i dati e le directory. \centering \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} - \label{fig:filedir_disk_filesys} + \label{fig:fileintr_disk_filesys} \end{figure} Se si va ad esaminare come è strutturata l'informazione all'interno di un @@ -464,7 +462,7 @@ del tipo di quella esposta in \nfig. \centering \caption{Organizzazione di un filesystem} - \label{fig:filedir_filesys_detail} + \label{fig:fileintr_filesys_detail} \end{figure} da questa figura si evidenziano alcune caratteristiche su cui è bene porre attenzione in quanto sono fondamentali per capire il funzionamento delle @@ -522,7 +520,7 @@ adesso sar \subsection{Le funzioni \texttt{link} e \texttt{unlink}} -\label{sec:filedir_link} +\label{sec:fileintr_link} Una delle caratteristiche usate quando si opera con i file è quella di poter creare dei nomi fittizi (alias o collegamenti) per potersi riferire allo @@ -588,7 +586,7 @@ ma si limita ad aumentare di uno il numero di referenze al file aggiungendo il nuovo nome ai precedenti. Si noti che uno stesso file può essere così richiamato in diverse directory. -Per quanto dicevamo in \secref{sec:filedir_filesystem} la creazione del +Per quanto dicevamo in \secref{sec:fileintr_filesystem} la creazione del collegamento diretto è possibile solo se entrambi i pathname sono nello stesso filesystem; inoltre il filesystem deve supportare i collegamenti diretti (non è il caso ad esempio del filesystem \texttt{vfat} di windows). @@ -596,7 +594,7 @@ il caso ad esempio del filesystem \texttt{vfat} di windows). La funzione opera sui file ordinari, come sugli altri oggetti del filesystem, ma solo l'amministratore è in grado di creare un collegamento diretto ad un'altra directory, questo lo si fa perché in questo caso è possibile creare -dei circoli nel filesystem (vedi \secref{sec:filedir_symlink}) che molti +dei circoli nel filesystem (vedi \secref{sec:fileintr_symlink}) che molti programmi non sono in grado di gestire e la cui rimozione diventa estremamente complicata (in genere occorre far girare il programma \texttt{fsck} per riparare il filesystem); data la sua pericolosità in Linux questa @@ -666,7 +664,7 @@ crash dei programmi; la tecnica \texttt{unlink} subito dopo. \subsection{Le funzioni \texttt{remove} e \texttt{rename}} -\label{sec:filedir_cre_canc} +\label{sec:fileintr_remove} Al contrario di quanto avviene con altri unix in Linux non è possibile usare \texttt{unlink} sulle directory, per cancellare una directory si può usare la @@ -740,7 +738,7 @@ nuovo nome dopo che il vecchio \end{prototype} \subsection{I link simbolici} -\label{sec:filedir_sym_link} +\label{sec:fileintr_symlink} Siccome la funzione \texttt{link} crea riferimenti agli inodes, essa può funzionare soltanto per file che risiedono sullo stesso filesystem, dato che