X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=6fea57d59babf2a0d8e9770e63ae1686b82486b4;hp=7d58c31ce8345942e4b0371fb3d86f48e04d1443;hb=6f8e0ca42d3d0b97b5e5747798a1eaffb44e8521;hpb=2a09a578f80e369673bd5ac24179c021e903358b diff --git a/fileintro.tex b/fileintro.tex index 7d58c31..6fea57d 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,6 +1,6 @@ -% fileintro.tex +%% fileintro.tex %% -%% Copyright (C) 2000-2003 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to %% copy, distribute and/or modify this document under the terms of the GNU Free %% Documentation License, Version 1.1 or any later version published by the %% Free Software Foundation; with the Invariant Sections being "Prefazione", @@ -19,7 +19,7 @@ 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 -cosiddetti file di dispositivo\index{file!di dispositivo} (i \textit{device +cosiddetti file di dispositivo\index{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. @@ -43,7 +43,6 @@ Questo viene fatto strutturando l'informazione sul disco attraverso quello che si chiama un \textit{filesystem} (vedi sez.~\ref{sec:file_arch_func}), essa poi viene resa disponibile ai processi attraverso quello che viene chiamato il \textsl{montaggio} del \textit{filesystem}. -% (approfondiremo tutto ciò in sez.~\ref{sec:file_arch_func}). In questa sezione faremo una panoramica generica su come il sistema presenta i file ai processi, trattando l'organizzazione di file e directory, i tipi di @@ -53,20 +52,21 @@ file ed introducendo le interfacce disponibili e le loro caratteristiche. \subsection{L'organizzazione di file e directory} \label{sec:file_organization} +\itindbeg{pathname} 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. Un file viene identificato dall'utente usando quello che viene chiamato -\textit{pathname}\index{pathname}\footnote{il manuale della \acr{glibc} - depreca questa nomenclatura, che genererebbe confusione poiché \textit{path} - indica anche un insieme di directory su cui effettuare una ricerca (come - quello in cui si cercano i comandi). Al suo posto viene proposto l'uso di - \textit{filename} e di componente per il nome del file all'interno della - directory. Non seguiremo questa scelta dato che l'uso della parola - \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più - chiaro dell'alternativa proposta.}, cioè il percorso che si deve fare per -accedere al file a partire dalla \textit{root directory}, che è composto da -una serie di nomi separati da una \file{/}. +\textit{pathname}\footnote{il manuale della \acr{glibc} depreca questa + nomenclatura, che genererebbe confusione poiché \textit{path} indica anche + un insieme di directory su cui effettuare una ricerca (come quello in cui si + cercano i comandi). Al suo posto viene proposto l'uso di \textit{filename} e + di componente per il nome del file all'interno della directory. Non + seguiremo questa scelta dato che l'uso della parola \textit{pathname} è + ormai così comune che mantenerne l'uso è senz'altro più chiaro + dell'alternativa proposta.}, cioè il percorso che si deve fare per accedere +al file a partire dalla \textit{root directory}, che è composto da una serie +di nomi separati da una \file{/}. All'avvio del sistema, completata la fase di inizializzazione, il kernel riceve dal bootloader l'indicazione di quale dispositivo contiene il @@ -86,38 +86,38 @@ particolare che il kernel riconosce come tale. Il suo scopo contenere una lista di nomi di file e le informazioni che associano ciascun nome al contenuto. Dato che questi nomi possono corrispondere ad un qualunque oggetto del filesystem, compresa un'altra directory, si ottiene naturalmente -un'organizzazione ad albero inserendo directory in altre directory. +un'organizzazione ad albero inserendo nomi di directory in altre directory. Un file può essere indicato rispetto alla directory corrente semplicemente specificandone il nome\footnote{Il 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}.} da essa -contenuto. All'interno dello stesso albero si potranno poi inserire anche -tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file -come le fifo, i link, i socket\index{socket} e gli stessi file di dispositivo -\index{file!di dispositivo} (questi -ultimi, per convenzione, sono inseriti nella directory \file{/dev}). +contenuti nelle directory \textsl{componenti} (in inglese \textit{file name +components}), noi li chiameremo più semplicemente \textsl{nomi} o +\textsl{voci}.} da essa contenuto. All'interno dello stesso albero si +potranno poi inserire anche tutti gli altri oggetti visti attraverso +l'interfaccia che manipola i file come le fifo, i link, i socket\index{socket} +e gli stessi file di dispositivo \index{file!di~dispositivo} (questi ultimi, +per convenzione, sono inseriti nella directory \file{/dev}). Il nome completo di un file viene chiamato \textit{pathname} ed il procedimento con cui si individua il file a cui esso fa riferimento è chiamato -risoluzione del nome (\textit{file name resolution} o \textit{pathname - resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da +risoluzione del nome (\textit{filename resolution} o \textit{pathname +resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da sinistra a destra e localizzando ogni nome nella directory indicata dal nome -precedente usando \file{/} come separatore\footnote{nel caso di nome vuoto, il - costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente, +precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto, +il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi indicati come directory esistano e siano effettivamente directory, inoltre i permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero \textit{pathname}. -Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte -dalla directory radice del processo; questa, a meno di un \func{chroot} (su -cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi -ed equivale alla directory radice dell'albero dei file: in questo caso si -parla di un \textsl{pathname assoluto}\index{pathname!assoluto}. Altrimenti la +Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla +directory radice del processo; questa, a meno di un \func{chroot} (su cui +torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed +equivale alla directory radice dell'albero dei file: in questo caso si parla +di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname - relativo}\index{pathname!relativo}. + relativo} \itindsub{pathname}{relativo}. I nomi \file{.} e \file{..} hanno un significato speciale e vengono inseriti in ogni directory: il primo fa riferimento alla directory corrente e il @@ -125,6 +125,7 @@ secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cio la directory che contiene il riferimento alla directory corrente; nel caso la directory corrente coincida con la directory radice, allora il riferimento è a se stessa. +\itindend{pathname} \subsection{I tipi di file} @@ -134,7 +135,7 @@ Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi sono implementati come oggetti del \textit{Virtual File System} (vedi sez.~\ref{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 +\textit{Virtual File System}\itindex{Virtual~File~System} è riportato in tab.~\ref{tab:file_file_types}. Si tenga ben presente che questa classificazione non ha nulla a che fare con @@ -145,7 +146,7 @@ Alcuni di essi, come le \textit{fifo} (che tratteremo in sez.~\ref{sec:ipc_named_pipe}) ed i \textit{socket}\index{socket} (che tratteremo in cap.~\ref{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}\index{file!di dispositivo} (o +altri sono i \textsl{file di dispositivo}\index{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à @@ -198,7 +199,7 @@ VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione 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\index{file!di dispositivo}, operazioni di I/O direttamente sui + dispositivo\index{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).} @@ -296,63 +297,10 @@ infatti segue solo lo standard POSIX.1 dei sistemi Unix, ed portabilità più limitata. -% \subsection{Caratteristiche specifiche dei file in Unix} -% \label{sec:fileint_unix_spec} - -% Essendo un sistema multitasking e multiutente esistono alcune caratteristiche -% specifiche di un sistema unix-like che devono essere tenute in conto -% nell'accesso ai file. È infatti normale che più processi o programmi possano -% accedere contemporaneamente allo stesso file e devono poter eseguire le loro -% operazioni indipendentemente da quello che fanno gli altri processi. - -% Per questo motivo le strutture usate per all'accesso ai file sono relative al -% processo che effettua l'accesso. All'apertura di ogni file infatti viene -% creata all'interno del processo una apposita struttura in cui sono memorizzati -% tutti gli attributi del medesimo, che viene utilizzata per tutte le -% operazioni. Questa è una struttura che resta locale al processo stesso; in -% questo modo processi diversi possono usare le proprie strutture locali per -% accedere ai file (che può essere sempre lo stesso) in maniera assolutamente -% indipendente. - -% Questo ha delle conseguenze di cui è bene tenere conto; ad esempio in tutti i -% 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 -% 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 -% ogni processo avrà la sua posizione corrente nel file, che non sarà -% influenzata da quello che altri processi possono fare. Anzi, aprire un file -% significa appunto creare ed inizializzare una tale struttura, per cui se si -% apre due volte lo stesso file all'interno dello stesso processo, si otterranno -% due file descriptor o due stream che avranno ancora una posizione corrente nel -% file assolutamente indipendente. - -% Si tenga conto inoltre che un'altro dei dati contenuti nella struttura di -% accesso è un riferimento all'inode del file, pertanto anche se il file viene -% 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 sez.~\ref{sec:file_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. - -% Ritorneremo su questo più avanti in sez.~\ref{sec:file_fd}, quando tratteremo -% l'input/output sui file, esaminando in dettaglio come tutto ciò viene -% realizzato. - \section{L'architettura della gestione dei file} \label{sec:file_arch_func} -%% 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 della gestione dei file da -%% parte del kernel 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 cap.~\ref{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 @@ -360,21 +308,11 @@ prima le caratteristiche generali di un filesystem di un sistema unix-like, per poi trattare in maniera un po' più dettagliata il filesystem più usato con 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 -% sez.~\ref{sec:file_vfs}. - \subsection{Il \textit{Virtual File System} di Linux} \label{sec:file_vfs} -% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i -% 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}. - +\itindbeg{Virtual~File~System} In Linux il concetto di \textit{everything is a file} è stato implementato attraverso il \textit{Virtual File System} (da qui in avanti VFS) che è uno strato intermedio che il kernel usa per accedere ai più svariati filesystem @@ -439,21 +377,21 @@ il descrittore di file contiene i puntatori alle funzioni che vengono usate sui file già aperti. -\subsection{Il funzionamento del VFS} +\subsection{Il funzionamento del \textit{Virtual File System}} \label{sec:file_vfs_work} 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}. +che permette di aprire un file. Dato un \itindex{pathname}\textit{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 \textit{pathname} a una specifica \textit{dentry}. Una singola \textit{dentry} contiene in genere il puntatore ad un \textit{inode}\index{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\index{file!di dispositivo}, o una qualsiasi altra cosa che possa +dispositivo\index{file!di~dispositivo}, o una qualsiasi altra cosa che possa essere rappresentata dal VFS (i tipi di file riportati in tab.~\ref{tab:file_file_types}). A ciascuno di essi è associata pure una struttura che sta in memoria, e che, oltre alle informazioni sullo specifico @@ -471,8 +409,8 @@ La \textit{dcache} costituisce perci l'albero dei file, ovviamente per non riempire tutta la memoria questa vista è parziale (la \textit{dcache} cioè contiene solo le \textit{dentry} per i file per i quali è stato richiesto l'accesso), quando si vuole risolvere un nuovo -pathname il VFS deve creare una nuova \textit{dentry} e caricare -l'inode\index{inode} corrispondente in memoria. +\itindex{pathname}\textit{pathname} il VFS deve creare una nuova +\textit{dentry} e caricare l'inode\index{inode} corrispondente in memoria. Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode\index{inode} della directory che contiene il file; questo viene @@ -538,6 +476,7 @@ normale file di dati; 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. +\itindend{Virtual~File~System} \subsection{Il funzionamento di un filesystem Unix} @@ -548,7 +487,7 @@ 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, per il momento non entreremo nei dettagli di un +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. @@ -556,7 +495,7 @@ 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 fig.~\ref{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 +prevede una separazione dei dati in \textit{block group} che replicano il superblock (ma sulle caratteristiche di \acr{ext2} torneremo in sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i filesystem per Unix, indipendentemente da come poi viene strutturata nei @@ -691,7 +630,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti: 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 fig.~\ref{fig:file_filesys_detail}, in cui la partizione è divisa -in gruppi di blocchi.\footnote{non si confonda la questa definizione con +in gruppi di blocchi.\footnote{non si confonda questa definizione con quella riportata in fig.~\ref{fig:file_dirent_struct}; in quel caso si fa riferimento alla struttura usata in user space per riportare i dati contenuti in una directory generica, questa fa riferimento alla struttura @@ -715,12 +654,12 @@ L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi nelle prestazioni dato che viene ridotta la distanza fra i dati e la tabella degli inode\index{inode}. -Le directory sono implementate come una linked list con voci di dimensione -variabile. Ciascuna voce della lista contiene il numero di inode\index{inode}, -la sua lunghezza, il nome del file e la sua lunghezza, secondo lo schema in -fig.~\ref{fig:file_ext2_dirs}; in questo modo è possibile implementare nomi -per i file anche molto lunghi (fino a 1024 caratteri) senza sprecare spazio -disco. +Le directory sono implementate come una \itindex{linked~list}\textit{linked + list} con voci di dimensione variabile. Ciascuna voce della lista contiene +il numero di inode\index{inode}, la sua lunghezza, il nome del file e la sua +lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo +è possibile implementare nomi per i file anche molto lunghi (fino a 1024 +caratteri) senza sprecare spazio disco.