-%% fileintro.tex
+% 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",
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
\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.
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
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
\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
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
\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}
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 è
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
è 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}
\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
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
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}
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
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.
\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
\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
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}
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
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
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
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.
projects / gapil.git / blobdiff