X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=baef2cac8831f25ca34fe84291dceefcf8889141;hp=eaea00299a2791c92f303b953894e8af1972b059;hb=ff76d56c6a2c280cbe4f153173488871d7b12336;hpb=3c347867e99daab5f2d89b04b5a1500ed6a3bcb8 diff --git a/fileintro.tex b/fileintro.tex index eaea002..baef2ca 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,6 +1,6 @@ %% fileintro.tex %% -%% Copyright (C) 2000-2004 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2007 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,10 +19,11 @@ 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 - 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. +cosiddetti \index{file!di~dispositivo} file di dispositivo (i cosiddetti +\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. In questo capitolo forniremo una descrizione dell'architettura dei file in Linux, iniziando da una panoramica sulle caratteristiche principali delle @@ -43,7 +44,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,7 +53,7 @@ file ed introducendo le interfacce disponibili e le loro caratteristiche. \subsection{L'organizzazione di file e directory} \label{sec:file_organization} -\index{\textit{pathname}|(} +\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 @@ -87,38 +87,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}). + 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 e gli stessi +\index{file!di~dispositivo} 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} 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{\textit{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{\textit{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 @@ -126,6 +126,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} @@ -135,7 +136,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{\textit{Virtual~File~System}} è riportato in +\itindex{Virtual~File~System} \textit{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 @@ -143,19 +144,19 @@ 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 -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 -\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.} +sez.~\ref{sec:ipc_named_pipe}) ed i \textit{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 +\index{file!di~dispositivo} \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 @@ -169,7 +170,7 @@ in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in 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 - \textit{inode}\index{inode} (vedi sez.~\ref{sec:file_vfs}). \\ + \index{inode} \textit{inode} (vedi sez.~\ref{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} & @@ -179,7 +180,7 @@ in cui il dispositivo sottostante effettua le operazioni di I/O.\footnote{in \textit{fifo} & ``\textsl{coda}'' & un file speciale che identifica una linea di comunicazione software unidirezionale (vedi sez.~\ref{sec:ipc_named_pipe}).\\ - \textit{socket}\index{socket} & ``\textsl{presa}''& + \textit{socket} & ``\textsl{presa}''& un file speciale che identifica una linea di comunicazione software bidirezionale (vedi cap.~\ref{cha:socket_intro}) \\ \hline @@ -198,10 +199,10 @@ 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\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).} + fare con tutto ciò, di effettuare, attraverso degli appositi + \index{file!di~dispositivo} 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 è @@ -246,31 +247,36 @@ L'interfaccia 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 \textit{file descriptor}\index{file!descriptor} sono +dispositivi); i \index{file!descriptor} \textit{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 \acr{glibc} chiama degli -\textit{stream}\index{file!stream}. Essa fornisce funzioni più evolute e un -accesso bufferizzato (controllato dalla implementazione fatta dalle -\acr{glibc}), la tratteremo in dettaglio nel +\index{file!stream} \textit{stream}.\footnote{in realtà una interfaccia con lo + stesso nome è stata introdotta a livello di kernel negli Unix derivati da + \textit{System V}, come strato di astrazione per file e socket; in Linux + questa interfaccia, che comunque ha avuto poco successo, non esiste, per cui + facendo riferimento agli \index{file!stream} \textit{stream} useremo il + significato adottato dal manuale delle \acr{glibc}.} Essa fornisce funzioni +più evolute e un accesso bufferizzato (controllato dalla implementazione fatta +dalle \acr{glibc}), la tratteremo in dettaglio nel cap.~\ref{cha:files_std_interface}. Questa è l'interfaccia standard specificata dall'ANSI C e perciò si trova -anche su tutti i sistemi non Unix. Gli \textit{stream}\index{file!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}. +anche su tutti i sistemi non Unix. Gli \index{file!stream} \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 (fifo, socket\index{socket}, device, sui quali torneremo -in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di +altri oggetti del VFS (fifo, socket, dispositivi, sui quali torneremo in +dettaglio a tempo opportuno), ma per poter accedere alle operazioni di controllo (descritte in sez.~\ref{sec:file_fcntl} e sez.~\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}\index{file!descriptor} se si vuole ricorrere a -modalità speciali di I/O come il \textit{file locking}\index{file!locking} o +\index{file!descriptor} \textit{file descriptor} se si vuole ricorrere a +modalità speciali di I/O come il \index{file!locking} \textit{file locking} o l'I/O non-bloccante (vedi cap.~\ref{cha:file_advanced}). Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra @@ -279,117 +285,54 @@ 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}\index{file!stream} dispongono di tutte le +particolare gli \index{file!stream} \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 \textit{file descriptor} da uno stream ed eseguirvi operazioni di basso livello, o associare in un secondo -tempo uno \textit{stream}\index{file!stream} ad un \textit{file - descriptor}\index{file!descriptor}. +tempo uno \index{file!stream} \textit{stream} ad un \index{file!descriptor} +\textit{file descriptor}. In generale, se non necessitano specificatamente le funzionalità di basso -livello, è opportuno usare sempre gli \textit{stream}\index{file!stream} per +livello, è opportuno usare sempre gli \index{file!stream} \textit{stream} per la loro maggiore portabilità, essendo questi ultimi definiti nello standard -ANSI C; l'interfaccia con i \textit{file descriptor}\index{file!descriptor} +ANSI C; l'interfaccia con i \index{file!descriptor} \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 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 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}. +Linux, l'\acr{ext2} (e derivati). \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}\index{\textit{Virtual~File~System}} -(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. +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 +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 alle -opportune routine del filesystem specifico a cui si fa riferimento. Saranno +opportune funzioni 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 fig.~\ref{fig:file_VFS_scheme}. @@ -404,7 +347,7 @@ fig.~\ref{fig:file_VFS_scheme}. 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: \textit{filesystem}, -\textit{inode}\index{inode} e \textit{file}, corrispondenti a tre apposite +\index{inode} \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 @@ -420,7 +363,7 @@ VFS pu nelle operazioni di montaggio. Quest'ultima è responsabile di leggere da disco il superblock (vedi sez.~\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 +attraverso quest'ultimo diventa possibile accedere alle funzioni specifiche per l'uso di quel filesystem. Il primo oggetto usato dal VFS è il descrittore di filesystem, un puntatore ad @@ -428,13 +371,13 @@ 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 \textit{filesystem descriptor} per accedere -alle routine specifiche di quel filesystem. +alle funzioni 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 relative al file in uso, insieme ai puntatori alle funzioni dello specifico filesystem usate per l'accesso dal VFS; in particolare il descrittore -dell'inode\index{inode} contiene i puntatori alle funzioni che possono essere +\index{inode} dell'inode contiene i puntatori alle funzioni che possono essere usate su qualunque file (come \func{link}, \func{stat} e \func{open}), mentre il descrittore di file contiene i puntatori alle funzioni che vengono usate sui file già aperti. @@ -443,19 +386,18 @@ sui file gi \subsection{Il funzionamento del \textit{Virtual File System}} \label{sec:file_vfs_work} -La funzione più importante implementata dal -VFS\index{\textit{Virtual~File~System}} è la system call \func{open} che -permette di aprire un file. Dato un \index{\textit{pathname}}\textit{pathname} +La funzione più importante implementata dal VFS è la system call \func{open} +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 +\index{inode} \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\index{file!di~dispositivo}, o una qualsiasi altra cosa che possa +\index{file!di~dispositivo} 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 @@ -463,28 +405,28 @@ 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}\index{inode} invece +vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento -viene copiato all'indietro sul disco, gli inode\index{inode} che stanno in -memoria sono inode\index{inode} del VFS ed è ad essi che puntano le singole +viene copiato all'indietro sul disco, gli \index{inode} inode che stanno in +memoria sono \index{inode} 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 -\index{\textit{pathname}}\textit{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 \index{inode} l'inode corrispondente in memoria. -Questo procedimento viene eseguito dal metodo \code{lookup()} -dell'inode\index{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. +Questo procedimento viene eseguito dal metodo \code{lookup()} \index{inode} +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 \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\index{inode} e passarli in user space. +\index{inode} dell'inode e passarli in user space. L'apertura di un file richiede comunque un'altra operazione, l'allocazione di una struttura di tipo \struct{file} in cui viene inserito un puntatore alla @@ -532,7 +474,7 @@ tab.~\ref{tab:file_file_operations}. 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 \struct{f\_ops} appropriata al +utilizzare l'opportuna funzione dichiarata in \struct{f\_ops} appropriata al tipo di file in questione. Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un @@ -540,6 +482,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} @@ -550,7 +493,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. @@ -563,7 +506,7 @@ 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 dettagli questa informazione, prevedere una divisione fra la lista degli -inode\index{inode} e lo spazio a disposizione per i dati e le directory. +\index{inode} inode e lo spazio a disposizione per i dati e le directory. \begin{figure}[htb] \centering @@ -595,13 +538,13 @@ particolare \begin{enumerate} -\item L'\textit{inode}\index{inode} contiene tutte le informazioni riguardanti - il file: il tipo di file, i permessi di accesso, le dimensioni, i puntatori - ai blocchi 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}\index{inode} ad esso associato, cioè quella che da qui - in poi chiameremo una \textsl{voce} (come traduzione dell'inglese +\item L'\textit{inode} \index{inode} contiene tutte le informazioni + riguardanti il file: il tipo di file, i permessi di accesso, le dimensioni, + i puntatori ai blocchi 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 \index{inode} dell'\textit{inode} ad esso 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 sez.~\ref{sec:file_vfs}). @@ -612,18 +555,18 @@ particolare 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}\index{inode}. + directory e decrementare il numero di riferimenti \index{inode} + 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{inode}\index{inode} relativi ad altri filesystem. + riferimenti ad \index{inode} \textit{inode} 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 viene spostato fisicamente, viene semplicemente creata una - nuova voce per l'\textit{inode}\index{inode} in questione e rimossa la + nuova voce per \index{inode} 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}). @@ -634,7 +577,7 @@ riferimenti anche per le directory; per cui, se a partire dalla situazione mostrata in fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img} nella directory \file{gapil}, avremo una situazione come quella in fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri -di inode\index{inode}. +di \index{inode} inode. \begin{figure}[htb] \centering @@ -680,7 +623,7 @@ non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti: in fase di creazione, a seconda delle sue esigenze (blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco). \item il filesystem implementa link simbolici veloci, in cui il nome del file - non è salvato su un blocco, ma tenuto all'interno dell'inode\index{inode} + non è salvato su un blocco, ma tenuto all'interno \index{inode} dell'inode (evitando letture multiple e spreco di spazio), non tutti i nomi però possono essere gestiti così per limiti di spazio (il limite è 60 caratteri). \item vengono supportati i file immutabili (che possono solo essere letti) per @@ -693,7 +636,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 @@ -713,18 +656,29 @@ superblock principale. \label{fig:file_ext2_dirs} \end{figure} -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. - - +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 \index{inode} inode. + +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. + + +% LocalWords: everything is device kernel filesystem sez pathname root glibc +% LocalWords: path filename bootloader proc name components fifo socket dev LF +% LocalWords: resolution chroot parent Virtual System like tab cap l'I regular +% LocalWords: inode symbolic char block VFS VMS Windows dell'I raw access Mac +% LocalWords: CR dos HFS l'XFS SGI magic number descriptor system call int ext +% LocalWords: nell'header unistd stream dall'ANSI stdio locking POSIX fig type +% LocalWords: register superblock dell'inode stat entry cache dcache dentry ln +% LocalWords: l'inode lookup ops read write llseek ioctl readdir poll nell'I +% LocalWords: multiplexing mmap fsync fasync seek MacOs group dall' dell' img +% LocalWords: count unlink nell' rename gapil second Tb attributes BSD SVr gid +% LocalWords: sgid append only log fs linux extented linked list %%% Local Variables: