X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=794d61159b96fe74cb463c39be53c3697fbdc405;hp=479ff86bf653717444cc04653c5819336984ff5e;hb=65a5b6a82bdcfeefa6ebc270fe759f3a38560d33;hpb=4ad4523de32d786ae4c24ef157bd4b8fe4aac534 diff --git a/fileintro.tex b/fileintro.tex index 479ff86..794d611 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,10 +1,11 @@ -\chapter{I file: l'architettura} +\chapter{L'architettura dei file} \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 -di input/output del computer viene effettuato attraverso un'interfaccia -astratta che tratta le periferiche allo stesso modo degli usuali file di dati. +Uno dei concetti fondamentali dell'architettura di un sistema Unix è il +cosiddetto \textit{everything is a file}, cioè il fatto che l'accesso ai vari +dispositivi di input/output del computer viene effettuato attraverso +un'interfaccia astratta che tratta le periferiche allo stesso modo dei normali +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 @@ -13,125 +14,134 @@ 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. -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 -contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le -varie caratteristiche distintive. +In questo capitolo forniremo una descrizione dell'architettura dei file in +Linux, iniziando da una panoramica sulle caratteristiche principali delle +interfacce con cui i processi accedono ai file (che tratteremo in dettaglio +nei capitoli seguenti), per poi passare ad una descrizione più dettagliata +delle modalità con cui detto accesso viene realizzato dal sistema. -\section{L'organizzazione di file e directory} -\label{sec:file_organization} - -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 file e directory} -\label{sec:file_file_struct} +\section{L'architettura generale} +\label{sec:file_access_arch} -Partiamo allora da come viene strutturata nel sistema la disposizione dei -file: per potervi accedere il kernel usa una apposita interfaccia che permetta -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 descriveremo in dettaglio in \secref{sec:file_vfs}. +Per poter accedere ai file, il kernel deve mettere a disposizione dei +programmi le opportune interfacce che consentano di leggerne il contenuto; il +sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera +opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi. +Questo viene fatto strutturando l'informazione sul disco attraverso quello che +si chiama un \textit{filesystem} (vedi \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 \secref{sec:file_arch_func}). -Sarà attraverso quest'ultimo che il kernel andrà a gestire l'accesso ai dati -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 questa sezione faremo una panormamica generica su come il sistema presenta +i file ai processi, trattando l'organizzazione di file e directory, i tipi di +file ed introducendo le interfacce disponibili e le loro caratteristiche. -%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 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 -di \textit{root}) viene montata all'avvio. Pertanto un file viene identificato -dall'utente usando quello che viene chiamato \textit{pathname}, cioè il -percorso che si deve fare per accedere al file. +\subsection{L'organizzazione di file e directory} +\label{sec:file_organization} -Dopo la fase di inizializzazione il kernel riceve dal boot loader -l'indicazione di quale dispositivo contiene il filesystem da usare come punto -di partenza e questo viene montato come radice dell'albero (cioè nella -directory \file{/}); tutti gli ulteriori dischi devono poi essere inseriti -nell'albero utilizzando opportune subdirectory. +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}\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 boot loader l'indicazione di quale dispositivo contiene il +filesystem da usare come punto di partenza e questo viene montato come radice +dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem +che possono essere su altri dispositivi dovranno poi essere inseriti +nell'albero montandoli su opportune directory del filesystem montato come +radice. Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad alcune strutture interne del kernel) sono generati automaticamente dal kernel -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 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}). - -L'organizzazione dei nomi dei file deriva direttamente dall'organizzazione dei -medesimi nell'albero descritto in precedenza; una directory comunque, come già -specificato in \secref{sec:file_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 -chiameremo più semplicemente \textit{nomi}. Un file può essere indicato -rispetto alla directory corrente semplicemente specificando il nome da essa -contenuto. Una directory contiene semplicemente un elenco di questi nomi, che -possono corrispondere a un qualunque oggetto del filesystem, compresa un'altra -directory; l'albero viene appunto creato inserendo directory in altre -directory. - -Il nome completo di file generico è composto da una serie di nomi separati da -una \texttt{/} (in Linux più \texttt{/} consecutive sono considerate -equivalenti ad una sola). Il nome completo di un file viene usualmente -chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo -nome (poiché genererebbe confusione, dato che con \textit{path} si indica -anche un insieme di directory su cui effettuare una ricerca, come quello in -cui si cercano i comandi); non seguiremo questa scelta dato che l'uso della -parola \textit{pathname} è ormai così comune che è senz'altro più chiaro -dell'alternativa proposta. - -Il processo con cui si associa ad un pathname uno specifico file è chiamato +stesso, ma anche essi devono essere montati all'interno dell'albero dei file. + +Una directory, come vedremo in maggior dettaglio in +\secref{sec:file_vfs_work}, è anch'essa un file, solo che è un file +particolare che il kernel riconosce come tale. Il suo scopo è quello di +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 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 e gli stessi i 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 pathname da destra a -sinistra e localizzando ogni nome nella directory indicata dal nome -precedente: ovviamente perché il procedimento funzioni occorre che i nomi -indicati come directory esistano e siano effettivamente directory, inoltre i -permessi devono consentire l'accesso. - -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:file_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:file_work_dir}) ed il pathname è -detto \textsl{relativo}. + 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, +perché il procedimento funzioni, occorre che i nomi indicati come directory +esistano e siano effettivamente directory, inoltre i permessi (si veda +\secref{sec:file_access_control}) devono consentire l'accesso all'intero +\textit{pathname}. + +Se il \textit{pathname} comincia per \file{/} la ricerca parte dalla directory +radice del processo; questa, a meno di un \func{chroot} (su cui torneremo in +\secref{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 ricerca +parte dalla directory corrente (su cui torneremo in +\secref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname + relativo}\index{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 -secondo alla directory \textsl{genitrice} (\textit{parent directory}) cioè la -directory che contiene il riferimento alla directory corrente; nel caso questa -sia la directory radice allora il riferimento è a se stessa. +in ogni directory: il primo fa riferimento alla directory corrente e il +secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè +la directory che contiene il riferimento alla directory corrente; nel caso +questa sia la directory radice, allora il riferimento è a se stessa. \subsection{I tipi di file} \label{sec:file_file_types} -Come detto in precedenza in unix esistono vari tipi di file, in Linux questi +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}) e sono presenti in tutti i filesystem unix-like -utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal Virtual -File System è riportato in \ntab. +\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 +\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 @@ -141,20 +151,21 @@ dati) in base al loro contenuto, o tipo di accesso. \multicolumn{2}{|c|}{\textbf{Tipo di file}} & \textbf{Descrizione} \\ \hline \hline - \textit{regular file} & \textsl{file normale} & + \textit{regular file} & \textsl{file regolare} & un file che contiene dei dati (l'accezione normale di file) \\ \textit{directory} & \textsl{cartella o direttorio} & - un file che contiene una lista di nomi associati a degli inodes \\ + un file che contiene una lista di nomi associati a degli \textit{inodes} + (vedi \secref{sec:file_vfs}). \\ \textit{symbolic link} & \textsl{collegamento simbolico} & un file che contiene un riferimento ad un altro file/directory \\ \textit{char device} & \textsl{dispositivo a caratteri} & - un file che identifica una periferica ad accesso sequenziale \\ + un file che identifica una periferica ad accesso a caratteri \\ \textit{block device} & \textsl{dispositivo a blocchi} & - un file che identifica una periferica ad accesso diretto \\ - \textit{fifo} & \textsl{tubo} & + un file che identifica una periferica ad accesso a blocchi \\ + \textit{fifo} & \textsl{``coda''} & un file speciale che identifica una linea di comunicazione software (unidirezionale) \\ - \textit{socket} & \textsl{manicotto} & + \textit{socket} & \textsl{``presa''} & un file speciale che identifica una linea di comunicazione software (bidirezionale) \\ \hline @@ -163,160 +174,181 @@ 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 una forma di accesso diretto ai dischi - (il \textit{raw access}) attraverso dei device file appositi, che però non - 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 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 +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 è +il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|) +del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux + dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una + conversione fra questi due formati di testo.} Questo può causare alcuni problemi qualora nei programmi si facciano assunzioni sul terminatore della riga. +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} \label{sec:file_io_api} -In unix le modalità di accesso ai file e le relative interfacce di +In Linux le modalità di accesso ai file e le relative interfacce di programmazione sono due, basate su due diversi meccanismi con cui è possibile accedere al loro contenuto. -La prima è l'interfaccia standard di unix, quella che il manuale delle glibc -chiama interfaccia dei descrittori di file (o \textit{file descriptor}). È -un'interfaccia specifica di unix e provvede un accesso non bufferizzato, la -tratteremo in dettaglio in \capref{cha:file_unix_interface}. +La prima è l'interfaccia standard di Unix, quella che il manuale delle +\acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file + descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce +un accesso non bufferizzato; la tratteremo in dettaglio in +\capref{cha:file_unix_interface}. L'interfaccia è primitiva ed essenziale, l'accesso viene detto non bufferizzato in quanto la lettura e la scrittura vengono eseguite chiamando direttamente le system call del kernel (in realtà il kernel effettua al suo interno alcune bufferizzazioni per aumentare l'efficienza nell'accesso ai -dispositivi); i file descriptors sono rappresentati da numeri interi (cioè -semplici variabili di tipo \type{int}). L'interfaccia è definita -nell'header \file{unistd.h}. +dispositivi); i \textit{file descriptor}\index{file descriptor} sono +rappresentati da numeri interi (cioè semplici variabili di tipo \ctyp{int}). +L'interfaccia è definita nell'header \file{unistd.h}. -La seconda interfaccia è quella che il manuale della glibc chiama degli -\textit{stream}, essa provvede funzioni più evolute e un accesso bufferizzato -(controllato dalla implementazione fatta dalle librerie del C), la tratteremo -in dettaglio in \capref{cha:files_std_interface}. +La seconda interfaccia è quella che il manuale della \acr{glibc} chiama degli +\textit{stream}\index{stream}. Essa fornisce funzioni più evolute e un accesso +bufferizzato (controllato dalla implementazione fatta dalle \acr{glibc}), la +tratteremo in dettaglio nel \capref{cha:files_std_interface}. Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova -anche su tutti i sistemi non unix. Gli stream sono oggetti complessi e sono -rappresentati da puntatori ad un opportuna struttura definita dalle librerie -del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo -\type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}. +anche su tutti i sistemi non Unix. Gli \textit{stream} sono oggetti complessi +e sono rappresentati da puntatori ad un opportuna struttura definita dalle +librerie del C; si accede ad essi sempre in maniera indiretta utilizzando il +tipo \ctyp{FILE *}. L'interfaccia è definita nell'header \file{stdio.h}. Entrambe le interfacce possono essere usate per l'accesso ai file come agli -altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle -operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre -usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo -devono essere usati i file descriptor se si vuole ricorrere a modalità -speciali di I/O come il polling o il non-bloccante (vedi -\secref{sec:file_xxx}). - -Gli stream forniscono un'interfaccia di alto livello costruita sopra quella -dei file descriptor, che tratta tutti i file nello stesso modo, con -l'eccezione di poter scegliere tra diversi stili di bufferizzazione. Il -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 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 +altri oggetti del VFS (fifo, socket, device, sui quali torneremo in dettaglio +a tempo opportuno), ma per poter accedere alle operazioni di controllo +(descritte in \ref{sec:file_fcntl} e \ref{sec:file_ioctl}) su un qualunque +tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix con i +\textit{file descriptor}. Allo stesso modo devono essere usati i \textit{file + descriptor} se si vuole ricorrere a modalità speciali di I/O come il polling +o il non-bloccante (vedi \capref{cha:file_advanced}). + +Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra +quella dei \textit{file descriptor}, che permette di poter scegliere tra +diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream} +è che l'interfaccia per le operazioni di input/output è enormemente più ricca +di quella dei \textit{file descriptor}, che forniscono solo funzioni +elementari per la lettura/scrittura diretta di blocchi di byte. In +particolare gli \textit{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. In ogni caso, dato che gli stream sono implementati sopra l'interfaccia -standard di unix, è sempre possibile estrarre il file descriptor da uno stream -ed eseguirvi operazioni di basso livello, o associare in un secondo tempo uno -stream ad un file descriptor. +standard di Unix, è sempre possibile estrarre il \textit{file descriptor} da +uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo +tempo uno \textit{stream} ad un \textit{file descriptor}. In generale, se non necessitano specificatamente le funzionalità di basso -livello, è opportuno usare sempre gli stream per la loro maggiore portabilità -essendo questi ultimi definiti nello standard ANSI C; l'interfaccia con i file -descriptor invece segue solo lo standard POSIX.1 dei sistemi unix ed è -pertanto di 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 \secref{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, quando tratteremo l'input/output sui file, -esaminando in dettaglio come tutto ciò viene realizzato. - -Si ricordi infine che in ambiente unix non esistono i tipi di file e che non -c'è nessun supporto 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 .c, ma -questa è, appunto, solo una convenzione. +livello, è opportuno usare sempre gli \textit{stream} per la loro maggiore +portabilità, essendo questi ultimi definiti nello standard ANSI C; +l'interfaccia con i \textit{file descriptor} infatti segue solo lo standard +POSIX.1 dei sistemi Unix, ed è pertanto di 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 \secref{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 \secref{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_architecture} +\label{sec:file_arch_func} 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}. +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. 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 -poi in maniera un po' più dettagliata il filesystem standard di Linux, -l'\acr{ext2}, come esempio di un filesystem unix-like. +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 @@ -326,56 +358,58 @@ l'\acr{ext2}, come esempio di un filesystem unix-like. % \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 - -Quando un processo esegue una system call che opera su un file il kernel +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 fornisce +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 i 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 -manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alla +manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle 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. +di I/O sul dispositivo fisico, secondo lo schema riportato in +\figref{fig:file_VFS_scheme}. \begin{figure}[htb] \centering - \includegraphics[width=7cm]{img/vfs.eps} - \caption{Schema delle operazioni del VFS} + \includegraphics[width=7cm]{img/vfs} + \caption{Schema delle operazioni del VFS.} \label{fig:file_VFS_scheme} \end{figure} Il VFS definisce un insieme di funzioni che tutti i filesystem devono -implementare. L'interfaccia comprende tutte le funzioni che riguardano i -file; le operazioni sono suddivise su tre tipi di oggetti: filesystem, inode -e file, corrispondenti a tre apposite strutture definite nel kernel. +implementare. L'interfaccia comprende tutte le funzioni che riguardano i file; +le operazioni sono suddivise su tre tipi di oggetti: \textit{filesystem}, +\textit{inode} e \textit{file}, corrispondenti a tre apposite strutture +definite nel kernel. Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun filesystem supportato: quando si vuole inserire il supporto di un nuovo filesystem tutto quello che occorre è chiamare la funzione -\func{register\_filesystem} passandole un'apposita struttura +\code{register\_filesystem} passandole un'apposita struttura (\var{file\_system\_type}) che contiene i dettagli per il riferimento all'implementazione del medesimo, che sarà aggiunta alla citata tabella. - 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 decriptor 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 @@ -390,121 +424,130 @@ file gi \subsection{Il funzionamento del VFS} \label{sec:file_vfs_work} -La funzione più fondamentale implementata dal VFS è la system call -\texttt{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. - -Una singola 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, 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. - -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 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 -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. - -Questo procedimento viene eseguito dal metodo \func{lookup()} dell'inode +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 (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 \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 è +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 +corrispondente in memoria. + +Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode 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 una struttura di tipo \var{file} in cui viene inserito un puntatore alla -dentry e una struttura \verb|f_ops| che contiene i puntatori ai 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. +\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai +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 +\tabref{tab:file_file_operations}. \begin{table}[htb] \centering \footnotesize - \begin{tabular}[c]{|l|p{7cm}|} + \begin{tabular}[c]{|l|p{8cm}|} \hline \textbf{Funzione} & \textbf{Operazione} \\ \hline \hline - \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\\ - \textsl{\func{release}}& chiamata quando l'ultima referenza a un file - aperto è chiusa\\ - \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. \\ + \textsl{\code{open}} & apre il file (vedi \secref{sec:file_open}). \\ + \textsl{\code{read}} & legge dal file (vedi \secref{sec:file_read}).\\ + \textsl{\code{write}} & scrive sul file (vedi \secref{sec:file_write}).\\ + \textsl{\code{llseek}} & sposta la posizione corrente sul file (vedi + \secref{sec:file_lseek}). \\ + \textsl{\code{ioctl}} & accede alle operazioni di controllo + (vedi \secref{sec:file_ioctl}).\\ + \textsl{\code{readdir}}& legge il contenuto di una directory \\ + \textsl{\code{poll}} & usata nell'I/O multiplexing (vedi + \secref{sec:file_multiplexing}). \\ + \textsl{\code{mmap}} & mappa il file in memoria (vedi + \secref{sec:file_memory_map}). \\ + \textsl{\code{release}}& chiamata quando l'ultima referenza a un file + aperto è chiusa. \\ + \textsl{\code{fsync}} & sincronizza il contenuto del file (vedi + \secref{sec:file_sync}). \\ + \textsl{\code{fasync}} & abilita l'I/O asincrono (vedi + \secref{sec:file_asyncronous_io}) sul file. \\ \hline \end{tabular} \caption{Operazioni sui file definite nel VFS.} \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 -utilizzare la opportuna routine dichiarata in \verb|f_ops| appropriata al tipo -di file in questione. +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 l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo +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 -\textit{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 normale un 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. -\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 -filesystem. Una delle caratteristiche di Linux rispetto agli altri unix è -quella di poter supportare grazie al VFS una enorme quantità di filesystem +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. - -Dato un disco lo spazio fisico 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 ext2, che prevede una separazione dei dati in -\textit{blocks group} che replicano il superblock (ma sulle caratteristiche di -ext2 torneremo in \secref{sec:file_ext2}). È comunque caratteristica -comune di tutti i filesystem 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. +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. + +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 \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=9cm]{img/disk_struct.eps} - \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} + \includegraphics[width=14cm]{img/disk_struct} + \caption{Organizzazione dello spazio su un disco in partizioni e + filesystem.} \label{fig:file_disk_filesys} \end{figure} @@ -512,19 +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=11cm]{img/filesys_struct.eps} - \caption{Strutturazione dei dati all'interno di un filesystem} + \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 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 \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} @@ -533,44 +578,45 @@ torneremo in seguito; in particolare fisici che contengono i dati e così via; le informazioni che la funzione \func{stat} fornisce provengono dall'\textit{inode}; dentro una directory si 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{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 a eliminare la relativa voce da una directory e - decrementare il numero di riferimenti nell'\textit{inode}. + associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come + 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 \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 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à - in cui opera normalmente il comando \cmd{mv} attraverso la funzione - \func{rename}). +\item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto + del file non viene spostato fisicamente, viene semplicemente creata una + nuova voce per l'\textit{inode} in questione e rimossa la vecchia (questa è + la modalità in cui opera normalmente il comando \cmd{mv} attraverso la + funzione \func{rename}). \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 \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=11cm]{img/dir_links.eps} - \caption{Organizzazione dei link per le directory} + \includegraphics[width=14cm]{img/dir_links} + \caption{Organizzazione dei link per le directory.} \label{fig:file_dirs_link} \end{figure} @@ -578,35 +624,35 @@ La nuova directory avr è 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 directory. Al contempo la directory da -cui si era partiti avrà un numero di riferiementi di almeno tre, in quanto +che non contenga a sua volta altre directory. Al contempo, la directory da +cui si era partiti avrà un numero di riferimenti 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 cosiddetto \textit{second extended - filesystem}, identificato dalla sigla \textsl{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. - -Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni -che non sono presenti sugli altri filesystem unix, le cui principali sono le -seguenti: + filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le +caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di +file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di +4~Tb. + +Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che +non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti: \begin{itemize} \item i \textit{file attributes} consentono di modificare il comportamento del - kernel quando agisce su gruppi di file. Possono essere settati su file e + kernel quando agisce su gruppi di file. Possono essere impostati 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 SVr4 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 SVr4 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 - sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}. + di \acr{sgid} impostato (per una descrizione dettagliata del significato di + questi termini si veda \secref{sec:file_access_control}), nel qual caso file + e subdirectory 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). @@ -621,7 +667,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. @@ -631,25 +677,27 @@ filesystem (superblock e descrittore del filesystem sono quindi ridondati) per una maggiore affidabilità e possibilità di recupero in caso di corruzione del superblock principale. - \begin{figure}[htb] \centering - \includegraphics[width=9cm]{img/dir_struct.eps} + \includegraphics[width=9cm]{img/dir_struct} \caption{Struttura delle directory nel \textit{second extented filesystem}.} \label{fig:file_ext2_dirs} \end{figure} -L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle +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 -inodes. +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. +%%% Local Variables: +%%% mode: latex +%%% TeX-master: "gapil" +%%% End: