X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=92efd2abf427b68a5802689583509c9697537cda;hp=a84918ac555e0bcebc94203e3c1734609cc0740d;hb=520fa6e7cd289a93a0955f3f91848ebd5b424250;hpb=d88ea986fbf6b84a802fd8a5665af4324a6c89b3 diff --git a/fileintro.tex b/fileintro.tex index a84918a..92efd2a 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,6 +1,6 @@ % fileintro.tex %% -%% Copyright (C) 2000-2002 Simone Piccardi. Permission is granted to +%% Copyright (C) 2000-2003 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,10 @@ 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 (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 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. In questo capitolo forniremo una descrizione dell'architettura dei file in Linux, iniziando da una panoramica sulle caratteristiche principali delle @@ -45,7 +45,7 @@ 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}). -In questa sezione faremo una panormamica generica su come il sistema presenta +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 file ed introducendo le interfacce disponibili e le loro caratteristiche. @@ -57,19 +57,19 @@ 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{/}. +\textit{pathname}\index{pathname}\footnote{il manuale della \acr{glibc} + depreca questa nomenclatura, che genererebbe confusione poiché \textit{path} + indica anche un insieme di directory su cui effettuare una ricerca (come + quello in cui si cercano i comandi). Al suo posto viene proposto l'uso di + \textit{filename} e di componente per il nome del file all'interno della + directory. Non seguiremo questa scelta dato che l'uso della parola + \textit{pathname} è ormai così comune che mantenerne l'uso è senz'altro più + chiaro dell'alternativa proposta.}, cioè il percorso che si deve fare per +accedere al file a partire dalla \textit{root directory}, che è composto da +una serie di nomi separati da una \file{/}. All'avvio del sistema, completata la fase di inizializzazione, il kernel -riceve dal boot loader l'indicazione di quale dispositivo contiene il +riceve dal bootloader 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 @@ -94,7 +94,8 @@ specificandone il nome\footnote{Il manuale delle \acr{glibc} chiama i nomi 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 file di dispositivo (questi +come le fifo, i link, i socket\index{socket} e gli stessi file di dispositivo +\index{file!di dispositivo} (questi ultimi, per convenzione, sono inseriti nella directory \file{/dev}). Il nome completo di un file viene chiamato \textit{pathname} ed il @@ -109,14 +110,14 @@ 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 +Se il \textit{pathname}\index{pathname} comincia per \file{/} la ricerca parte +dalla directory radice del processo; questa, a meno di un \func{chroot} (su +cui torneremo in \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}. + 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 @@ -141,18 +142,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 -\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.} +\secref{sec:ipc_named_pipe}) ed i \textit{socket}\index{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}\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.} \begin{table}[htb] \footnotesize @@ -165,20 +167,20 @@ effettua le operazioni di I/O.\footnote{in sostanza i dispositivi a blocchi \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 \textit{inodes} - (vedi \secref{sec:file_vfs}). \\ + un file che contiene una lista di nomi associati a degli + \textit{inode}\index{inode} (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 a caratteri \\ \textit{block device} & \textsl{dispositivo a blocchi} & un file che identifica una periferica ad accesso a blocchi \\ - \textit{fifo} & \textsl{``coda''} & + \textit{fifo} & ``\textsl{coda}'' & un file speciale che identifica una linea di comunicazione software - (unidirezionale) \\ - \textit{socket} & \textsl{``presa''} & + unidirezionale (vedi \secref{sec:ipc_named_pipe}).\\ + \textit{socket}\index{socket} & ``\textsl{presa}''& un file speciale che identifica una linea di comunicazione software - (bidirezionale) \\ + bidirezionale (vedi \capref{cha:socket_intro}) \\ \hline \end{tabular} \caption{Tipologia dei file definiti nel VFS} @@ -190,15 +192,15 @@ Windows) 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).} +il cosiddetto ``\textsl{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\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).} 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 è @@ -243,29 +245,31 @@ 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 \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 \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}. +\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 \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 \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}. +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}. Entrambe le interfacce possono essere usate per l'accesso ai file come agli -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}). +altri oggetti del VFS (fifo, socket\index{socket}, device, sui quali torneremo +in dettaglio a tempo opportuno), ma per poter accedere alle operazioni di +controllo (descritte in \secref{sec:file_fcntl} e \secref{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 +l'I/O 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 @@ -273,20 +277,22 @@ 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. +particolare gli \textit{stream}\index{file!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} ad un \textit{file descriptor}. +tempo uno \textit{stream}\index{file!stream} ad un \textit{file + descriptor}\index{file!descriptor}. In generale, se non necessitano specificatamente le funzionalità di basso -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. +livello, è opportuno usare sempre gli \textit{stream}\index{file!stream} per +la loro maggiore portabilità, essendo questi ultimi definiti nello standard +ANSI C; l'interfaccia con i \textit{file descriptor}\index{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} @@ -340,12 +346,12 @@ POSIX.1 dei sistemi Unix, ed \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 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}. +%% 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 \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 @@ -396,14 +402,14 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in 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} e \textit{file}, corrispondenti a tre apposite strutture -definite nel kernel. +\textit{inode}\index{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 \code{register\_filesystem} passandole un'apposita struttura -(\var{file\_system\_type}) che contiene i dettagli per il riferimento +\code{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 @@ -426,10 +432,10 @@ 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 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. +dell'inode\index{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. \subsection{Il funzionamento del VFS} @@ -443,41 +449,43 @@ tabella che contiene tutte le \textit{directory entry} (in breve 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. +\textit{inode}\index{inode}; quest'ultimo è la struttura base che sta sul +disco e che identifica un singolo oggetto del VFS sia esso un file ordinario, +una directory, un link simbolico, una FIFO, un file di +dispositivo\index{file!di dispositivo}, o una qualsiasi altra cosa che possa +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}. +vengono usate per motivi di velocità, gli \textit{inode}\index{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 +\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. +pathname il VFS deve creare una nuova \textit{dentry} e caricare +l'inode\index{inode} corrispondente in memoria. -Questo procedimento viene eseguito dal metodo \code{lookup()} dell'inode -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()} +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. 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. +dell'inode\index{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 -\textit{dentry} e una struttura \var{f\_ops} che contiene i puntatori ai +una struttura di tipo \struct{file} in cui viene inserito un puntatore alla +\textit{dentry} e una struttura \struct{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 @@ -520,12 +528,12 @@ operazioni previste dal kernel 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. +utilizzare l'opportuna routine dichiarata in \struct{f\_ops} appropriata al +tipo di file in questione. -Pertanto è 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 +Pertanto è possibile scrivere allo stesso modo sulla porta seriale come su un +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. @@ -551,7 +559,7 @@ 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. +inode\index{inode} e lo spazio a disposizione per i dati e le directory. \begin{figure}[htb] \centering @@ -583,15 +591,15 @@ particolare \begin{enumerate} -\item L'\textit{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} 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 - \secref{sec:file_vfs}). +\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 + \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 @@ -600,19 +608,20 @@ 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}. - + directory e decrementare il numero di riferimenti + nell'\textit{inode}\index{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. + riferimenti ad \textit{inode}\index{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} in questione e rimossa la vecchia (questa è - la modalità in cui opera normalmente il comando \cmd{mv} attraverso la - funzione \func{rename}). + nuova voce per l'\textit{inode}\index{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} @@ -621,7 +630,7 @@ 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. +inode\index{inode}. \begin{figure}[htb] \centering @@ -645,7 +654,7 @@ adesso sar Il filesystem standard usato da Linux è il cosiddetto \textit{second extended 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 +file lunghi (256 caratteri, estensibili a 1012) con una dimensione massima di 4~Tb. Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che @@ -667,9 +676,9 @@ 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 (evitando - letture multiple e spreco di spazio), non tutti i nomi però possono essere - gestiti così per limiti di spazio (il limite è 60 caratteri). + non è salvato su un blocco, ma tenuto all'interno dell'inode\index{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 la protezione di file di configurazione sensibili, o file \textit{append-only} che possono essere aperti in scrittura solo per @@ -696,11 +705,11 @@ superblock principale. 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. +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, la sua -lunghezza, il nome del file e la sua lunghezza, secondo lo schema in +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 \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.