+% fileintro.tex
+%%
+%% Copyright (C) 2000-2002 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",
+%% with no Front-Cover Texts, and with no Back-Cover Texts. A copy of the
+%% license is included in the section entitled "GNU Free Documentation
+%% License".
+%%
\chapter{L'architettura dei file}
\label{cha:file_intro}
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
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
components}), noi li chiameremo più semplicemente \textit{nomi}.} da essa
contenuto. All'interno dello stesso albero si potranno poi inserire anche
tutti gli altri oggetti visti attraverso l'interfaccia che manipola i file
-come le fifo, i link, i socket e gli stessi i file di dispositivo (questi
+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
secondo alla directory \textsl{genitrice} (o \textit{parent directory}) cioè
-la directory che contiene il riferimento alla directory corrente; nel caso
-questa sia la directory radice, allora il riferimento è a se stessa.
+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.
\subsection{I tipi di file}
sono implementati come oggetti del \textit{Virtual File System} (vedi
\secref{sec:file_vfs_work}) e sono presenti in tutti i filesystem unix-like
utilizzabili con Linux. L'elenco dei vari tipi di file definiti dal
-\textit{Virtual File System}\index{Virtual File System} è riportato in \ntab.
+\textit{Virtual File System}\index{Virtual File System} è riportato in
+\tabref{tab:file_file_types}.
Si tenga ben presente che questa classificazione non ha nulla a che fare con
-la classificazione sui tipi di file (che in questo caso sono sempre file di
-dati) in base al loro contenuto, o tipo di accesso.
+la classificazione dei file (che in questo caso sono sempre file di dati) in
+base al loro contenuto, o tipo di accesso. Essa riguarda invece il tipo di
+oggetti; in particolare è da notare la presenza dei cosiddetti file speciali.
+Alcuni di essi, come le \textit{fifo} (che tratteremo in
+\secref{sec:ipc_named_pipe}) ed i \textit{socket}\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 blocchi \\
\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}
\label{tab:file_file_types}
\end{table}
-Infatti una delle differenze principali con altri sistemi operativi (come il
-VMS o Windows) è che per Unix tutti i file di dati sono identici e contengono
-un flusso continuo di byte. Non esiste cioè differenza per come vengono visti
-dal sistema file di diverso contenuto o formato (come nel caso di quella fra
-file di testo e binari che c'è in Windows) né c'è una strutturazione a record
-per il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{con i
- kernel della serie 2.4 è disponibile, attraverso dei device file appositi,
- una forma di accesso diretto ai dischi (il \textit{raw access}) che però non
- ha nulla a che fare con questo, trattandosi solo di operazioni fatte senza
- passare attraverso un filesystem.}
+Una delle differenze principali con altri sistemi operativi (come il VMS o
+Windows) è che per Unix tutti i file di dati sono identici e contengono un
+flusso continuo di byte. Non esiste cioè differenza per come vengono visti dal
+sistema file di diverso contenuto o formato (come nel caso di quella fra file
+di testo e binari che c'è in Windows) né c'è una strutturazione a record per
+il cosiddetto ``accesso diretto'' come nel caso del VMS.\footnote{questo vale
+ anche per i dispositivi a blocchi: la strutturazione dell'I/O in blocchi di
+ dimensione fissa avviene solo all'interno del kernel, ed è completamente
+ trasparente all'utente. Inoltre talvolta si parla di \textsl{accesso
+ diretto} riferendosi alla capacità, che non ha niente a che fare con tutto
+ ciò, di effettuare, attraverso degli appositi file di
+ dispositivo\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 è
problemi qualora nei programmi si facciano assunzioni sul terminatore della
riga.
-Si ricordi infine che in ambiente Unix non esistono tipizzazioni dei file di
-dati e che non c'è nessun supporto del sistema per le estensioni come parte
-del filesystem. Ciò nonostante molti programmi adottano delle convenzioni per
-i nomi dei file, ad esempio il codice C normalmente si mette in file con
-l'estensione \file{.c}, ma questa è, per quanto usata ed accettata in maniera
-universale, solo una convenzione.
+Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
+tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
+estensioni come parte del filesystem.\footnote{non è così ad esempio nel
+ filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
+ che specificano fra l'altro il contenuto ed il programma da usare per
+ leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
+ possibilità di associare delle risorse ai file, ma è una caratteristica
+ tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
+ file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
+convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
+in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
+utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
+che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
+accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
+demandato alle applicazioni stesse.
\subsection{Le due interfacce ai file}
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}
\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}.
+unix-like ed il comportamento delle relative funzioni di manipolazione,
+occorre una breve introduzione al funzionamento gestione dei file da parte del
+kernel e sugli oggetti su cui è basato un filesystem. In particolare occorre
+tenere presente dov'è che si situa la divisione fondamentale fra kernel space
+e user space che tracciavamo al \capref{cha:intro_unix}.
In questa sezione esamineremo come viene implementato l'accesso ai file in
Linux, come il kernel può gestire diversi tipi di filesystem, descrivendo
prima le caratteristiche generali di un filesystem di un sistema unix-like,
-per poi trattare in maniera un po' più dettagliata il filesystem standard di
+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
% \secref{sec:file_vfs}.
-\subsection{Il \textit{Virtual Filesystem} di Linux}
+\subsection{Il \textit{Virtual File System} di Linux}
\label{sec:file_vfs}
% Questa sezione riporta informazioni sui dettagli di come il kernel gestisce i
% \textit{inode}, \textit{dentry}, \textit{dcache}.
In Linux il concetto di \textit{everything is a file} è stato implementato
-attraverso il \textit{Virtual Filesystem} (da qui in avanti VFS) che è uno
+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
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
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
processi in user space possono accedere alle operazioni attraverso detti
metodi, che saranno diversi a seconda del tipo di file (o dispositivo) aperto
(su questo torneremo in dettaglio in \secref{sec:file_fd}). Un elenco delle
-operazioni previste dal kernel è riportato in \ntab.
+operazioni previste dal kernel è riportato in
+\tabref{tab:file_file_operations}.
\begin{table}[htb]
\centering
\secref{sec:file_multiplexing}). \\
\textsl{\code{mmap}} & mappa il file in memoria (vedi
\secref{sec:file_memory_map}). \\
- \textsl{\code{release}}& chiamata quando l'ultima referenza a un file
- aperto è chiusa. \\
+ \textsl{\code{release}}& chiamata quando l'ultimo riferimento a un file
+ aperto è chiuso. \\
\textsl{\code{fsync}} & sincronizza il contenuto del file (vedi
\secref{sec:file_sync}). \\
\textsl{\code{fasync}} & abilita l'I/O asincrono (vedi
utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo
di file in questione.
-In questo modo è possibile scrivere allo stesso modo sulla porta seriale come
-su normale un file di dati; ovviamente certe operazioni (nel caso della
-seriale ad esempio la \code{seek}) non saranno disponibili, però con questo
-sistema l'utilizzo di diversi filesystem (come quelli usati da Windows o
-MacOs) è immediato e (relativamente) trasparente per l'utente ed il
-programmatore.
+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
+l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOs) è
+immediato e (relativamente) trasparente per l'utente ed il programmatore.
\subsection{Il funzionamento di un filesystem Unix}
Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni
partizione può contenere un filesystem. La strutturazione tipica
-dell'informazione su un disco è riportata in \nfig; in essa si fa riferimento
-alla struttura del filesystem \acr{ext2}, che prevede una separazione dei dati
-in \textit{blocks group} che replicano il superblock (ma sulle caratteristiche
-di \acr{ext2} torneremo in \secref{sec:file_ext2}). È comunque caratteristica
-comune di tutti i filesystem per Unix, indipendentemente da come poi viene
-strutturata nei dettagli questa informazione, prevedere una divisione fra la
-lista degli inodes e lo spazio a disposizione per i dati e le directory.
+dell'informazione su un disco è riportata in \figref{fig:file_disk_filesys};
+in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
+prevede una separazione dei dati in \textit{blocks group} che replicano il
+superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
+\secref{sec:file_ext2}). È comunque caratteristica comune di tutti i
+filesystem per Unix, indipendentemente da come poi viene strutturata nei
+dettagli questa informazione, prevedere una divisione fra la lista degli
+inode\index{inode} e lo spazio a disposizione per i dati e le directory.
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/disk_struct}
+ \includegraphics[width=14cm]{img/disk_struct}
\caption{Organizzazione dello spazio su un disco in partizioni e
filesystem.}
\label{fig:file_disk_filesys}
dell'informazione all'interno del singolo filesystem (tralasciando i dettagli
relativi al funzionamento del filesystem stesso come la strutturazione in
gruppi dei blocchi, il superblock e tutti i dati di gestione) possiamo
-esemplificare la situazione con uno schema come quello esposto in \nfig.
+esemplificare la situazione con uno schema come quello esposto in
+\figref{fig:file_filesys_detail}.
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/filesys_struct}
+ \includegraphics[width=14cm]{img/filesys_struct}
\caption{Strutturazione dei dati all'interno di un filesystem.}
\label{fig:file_filesys_detail}
\end{figure}
-Da \curfig\ si evidenziano alcune delle caratteristiche di base di un
-filesystem, sulle quali è bene porre attenzione visto che sono fondamentali
-per capire il funzionamento delle funzioni che manipolano i file e le
-directory che tratteremo nel prossimo capitolo; in particolare è opportuno
-ricordare sempre che:
+Da \figref{fig:file_filesys_detail} si evidenziano alcune delle
+caratteristiche di base di un filesystem, sulle quali è bene porre attenzione
+visto che sono fondamentali per capire il funzionamento delle funzioni che
+manipolano i file e le directory che tratteremo nel prossimo capitolo; in
+particolare è opportuno ricordare sempre che:
\begin{enumerate}
-\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 Come mostrato in \curfig\ si possono avere più voci che puntano allo
- stesso \textit{inode}. Ogni \textit{inode} ha un contatore che contiene il
- numero di riferimenti (\textit{link count}) che sono stati fatti ad esso;
- solo quando questo contatore si annulla i dati del file vengono
- effettivamente rimossi dal disco. Per questo la funzione per cancellare un
- file si chiama \func{unlink}, ed in realtà non cancella affatto i dati del
- file, ma si limita ad eliminare la relativa voce da una directory e
- decrementare il numero di riferimenti nell'\textit{inode}.
-
+\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
+ contatore che contiene il numero di riferimenti (\textit{link count}) che
+ sono stati fatti ad esso; solo quando questo contatore si annulla i dati del
+ file vengono effettivamente rimossi dal disco. Per questo la funzione per
+ cancellare un file si chiama \func{unlink}, ed in realtà non cancella
+ affatto i dati del file, ma si limita ad eliminare la relativa voce da una
+ directory e decrementare il numero di riferimenti
+ nell'\textit{inode}\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}
Infine è bene avere presente che, essendo file pure loro, esiste un numero di
riferimenti anche per le directory; per cui, se a partire dalla situazione
-mostrata in \curfig\ creiamo una nuova directory \file{img} nella directory
-\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza
-abbiamo aggiunto dei numeri di inode.
+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\index{inode}.
\begin{figure}[htb]
\centering
- \includegraphics[width=12cm]{img/dir_links}
+ \includegraphics[width=14cm]{img/dir_links}
\caption{Organizzazione dei link per le directory.}
\label{fig:file_dirs_link}
\end{figure}
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 \curfig;
-in questo modo è possibile implementare nomi per i file anche molto lunghi
-(fino a 1024 caratteri) senza sprecare spazio disco.
+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