%% fileintro.tex
%%
-%% Copyright (C) 2000-2007 Simone Piccardi. Permission is granted to
+%% Copyright (C) 2000-2011 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",
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{/}.
+di nomi separati da una ``\file{/}''.
All'avvio del sistema, completata la fase di inizializzazione, il kernel
riceve dal bootloader l'indicazione di quale dispositivo contiene il
Il nome completo di un file viene chiamato \textit{pathname} ed il
procedimento con cui si individua il file a cui esso fa riferimento è chiamato
risoluzione del nome (\textit{filename resolution} o \textit{pathname
-resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
+ resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da
sinistra a destra e localizzando ogni nome nella directory indicata dal nome
-precedente usando \texttt{/} come separatore\footnote{nel caso di nome vuoto,
-il costrutto \file{//} viene considerato equivalente a \file{/}.}: ovviamente,
-perché il procedimento funzioni, occorre che i nomi indicati come directory
-esistano e siano effettivamente directory, inoltre i permessi (si veda
-sez.~\ref{sec:file_access_control}) devono consentire l'accesso all'intero
-\textit{pathname}.
-
-Se il \textit{pathname} comincia per \texttt{/} la ricerca parte dalla
-directory radice del processo; questa, a meno di un \func{chroot} (su cui
-torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i processi ed
-equivale alla directory radice dell'albero dei file: in questo caso si parla
-di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}. Altrimenti la
-ricerca parte dalla directory corrente (su cui torneremo in
+precedente usando il carattere ``\texttt{/}'' come separatore\footnote{nel
+ caso di nome vuoto, il costrutto \file{//} viene considerato equivalente a
+ \file{/}.}: ovviamente, perché il procedimento funzioni, occorre che i nomi
+indicati come directory esistano e siano effettivamente directory, inoltre i
+permessi (si veda sez.~\ref{sec:file_access_control}) devono consentire
+l'accesso all'intero \textit{pathname}.
+
+Se il \textit{pathname} comincia con il carattere ``\texttt{/}'' la ricerca
+parte dalla directory radice del processo; questa, a meno di un \func{chroot}
+(su cui torneremo in sez.~\ref{sec:file_chroot}) è la stessa per tutti i
+processi ed equivale alla directory radice dell'albero dei file: in questo
+caso si parla di un \textsl{pathname assoluto} \itindsub{pathname}{assoluto}.
+Altrimenti la ricerca parte dalla directory corrente (su cui torneremo in
sez.~\ref{sec:file_work_dir}) ed il pathname è detto
\itindsub{pathname}{relativo} \textsl{pathname relativo}.
il secondo alla directory \textsl{genitrice} (o \textit{parent directory})
cioè la directory che contiene il riferimento alla directory corrente; nel
caso la directory corrente coincida con la directory radice, allora il
-riferimento è a se stessa. \itindend{pathname}
+riferimento è a se stessa.
+
+\itindend{pathname}
\subsection{I tipi di file}
\textsl{accesso diretto} riferendosi alla capacità, che non ha niente a che
fare con tutto ciò, di effettuare, attraverso degli appositi
\index{file!di~dispositivo} file di dispositivo, operazioni di I/O
- direttamente sui dischi senza passare attraverso un filesystem (il
- cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x).}
-
-Una seconda differenza è nel formato dei file ASCII: in Unix la fine riga è
-codificata in maniera diversa da Windows o Mac, in particolare il fine riga è
-il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR} (\verb|\r|)
-del Mac e del \texttt{CR LF} di Windows.\footnote{per questo esistono in Linux
- dei programmi come \cmd{unix2dos} e \cmd{dos2unix} che effettuano una
- conversione fra questi due formati di testo.} Questo può causare alcuni
-problemi qualora nei programmi si facciano assunzioni sul terminatore della
-riga.
+ direttamente sui dischi senza passare attraverso un filesystem, il
+ cosiddetto \textit{raw access}, introdotto coi kernel della serie 2.4.x ed
+ in sostanziale disuso.}
+
+Una seconda differenza è nel formato dei file di testo: in Unix la fine riga è
+codificata in maniera diversa da Windows o dal vecchio MacOS, in particolare
+il fine riga è il carattere \texttt{LF} (o \verb|\n|) al posto del \texttt{CR}
+(\verb|\r|) del vecchio MacOS e del \texttt{CR LF} di Windows.\footnote{per
+ questo esistono in Linux dei programmi come \cmd{unix2dos} e \cmd{dos2unix}
+ che effettuano una conversione fra questi due formati di testo.} Questo può
+causare alcuni problemi qualora nei programmi si facciano assunzioni sul
+terminatore della riga.
Si ricordi infine che un kernel Unix non fornisce nessun supporto per la
tipizzazione dei file di dati e che non c'è nessun supporto del sistema per le
estensioni come parte del filesystem.\footnote{non è così ad esempio nel
filesystem HFS dei Mac, che supporta delle risorse associate ad ogni file,
che specificano fra l'altro il contenuto ed il programma da usare per
- leggerlo. In realtà per alcuni filesystem, come l'XFS della SGI, esiste la
- possibilità di associare delle risorse ai file, ma è una caratteristica
- tutt'ora poco utilizzata, dato che non corrisponde al modello classico dei
- file in un sistema Unix.} Ciò nonostante molti programmi adottano delle
-convenzioni per i nomi dei file, ad esempio il codice C normalmente si mette
-in file con l'estensione \file{.c}; un'altra tecnica molto usata è quella di
-utilizzare i primi 4 byte del file per memorizzare un \textit{magic number}
-che classifichi il contenuto; entrambe queste tecniche, per quanto usate ed
-accettate in maniera diffusa, restano solo delle convenzioni il cui rispetto è
-demandato alle applicazioni stesse.
+ leggerlo. In realtà per alcuni filesystem esiste la possibilità di
+ associare delle risorse ai file con gli \textit{extended attributes} (vedi
+ sez.~\ref{sec:file_xattr}), 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}
\subsection{Il \textit{Virtual File System} di Linux}
\label{sec:file_vfs}
+% articolo interessante:
+% http://www.ibm.com/developerworks/linux/library/l-virtual-filesystem-switch/index.html?ca=dgr-lnxw97Linux-VFSdth-LXdW&S_TACT=105AGX59&S_CMP=GRlnxw97
+
\itindbeg{Virtual~File~System}
In Linux il concetto di \textit{everything is a file} è stato implementato
Le \textit{dentry} ``vivono'' in memoria e non vengono mai salvate su disco,
vengono usate per motivi di velocità, gli \index{inode} \textit{inode} invece
stanno su disco e vengono copiati in memoria quando serve, ed ogni cambiamento
-viene copiato all'indietro sul disco, gli \index{inode} inode che stanno in
-memoria sono \index{inode} inode del VFS ed è ad essi che puntano le singole
+viene copiato all'indietro sul disco (aggiornando i cosiddetti
+\textsl{metadati} del file), gli \index{inode} inode che stanno in memoria
+sono \index{inode} inode del VFS ed è ad essi che puntano le singole
\textit{dentry}.
La \textit{dcache} costituisce perciò una sorta di vista completa di tutto
sez.~\ref{sec:file_lseek}).\\
\textsl{\code{ioctl}} & Accede alle operazioni di controllo
(vedi sez.~\ref{sec:file_ioctl}).\\
- \textsl{\code{readdir}}& Legge il contenuto di una directory.\\
+ \textsl{\code{readdir}}& Legge il contenuto di una directory (vedi
+ sez.~\ref{sec:file_dir_read}).\\
\textsl{\code{poll}} & Usata nell'I/O multiplexing (vedi
sez.~\ref{sec:file_multiplexing}).\\
\textsl{\code{mmap}} & Mappa il file in memoria (vedi
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) è
+l'utilizzo di diversi filesystem (come quelli usati da Windows o MacOS) è
immediato e (relativamente) trasparente per l'utente ed il programmatore.
\itindend{Virtual~File~System}
dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys};
in essa si fa riferimento alla struttura del filesystem \acr{ext2}, che
prevede una separazione dei dati in \textit{block group} che replicano il
-superblock (ma sulle caratteristiche di \acr{ext2} torneremo in
+superblock (ma sulle caratteristiche di \acr{ext2} e derivati torneremo in
sez.~\ref{sec:file_ext2}). È comunque caratteristica comune di tutti i
filesystem per Unix, indipendentemente da come poi viene strutturata nei
dettagli questa informazione, prevedere una divisione fra la lista degli
\begin{enumerate}
-\item L'\textit{inode} \index{inode} contiene tutte le informazioni
- riguardanti il file: il tipo di file, i permessi di accesso, le dimensioni,
- i puntatori ai blocchi fisici che contengono i dati e così via; le
- informazioni che la funzione \func{stat} fornisce provengono
- dall'\textit{inode}; dentro una directory si troverà solo il nome del file e
- il numero \index{inode} dell'\textit{inode} ad esso associato, cioè quella
- che da qui in poi chiameremo una \textsl{voce} (come traduzione dell'inglese
- \textit{directory entry}, che non useremo anche per evitare confusione con
- le \textit{dentry} del kernel di cui si parlava in sez.~\ref{sec:file_vfs}).
+\item L'\textit{inode} \index{inode} contiene tutte le informazioni (i
+ cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i
+ permessi di accesso, le dimensioni, i puntatori ai blocchi fisici che
+ contengono i dati e così via. Le informazioni che la funzione \func{stat}
+ fornisce provengono dall'\textit{inode}; dentro una directory si troverà
+ solo il nome del file e il numero \index{inode} dell'\textit{inode} ad esso
+ associato, cioè quella che da qui in poi chiameremo una \textsl{voce} (come
+ traduzione dell'inglese \textit{directory entry}, che non useremo anche per
+ evitare confusione con le \textit{dentry} del kernel di cui si parlava in
+ sez.~\ref{sec:file_vfs}).
\item Come mostrato in fig.~\ref{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 \index{inode}
+ contatore che contiene il numero di riferimenti che sono stati fatti ad esso
+ (il cosiddetto \textit{link count}); 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 \index{inode}
nell'\textit{inode}.
\item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode}
nello stesso filesystem e non ci può essere una directory che contiene
riferimenti ad \index{inode} \textit{inode} relativi ad altri filesystem.
Questo limita l'uso del comando \cmd{ln} (che crea una nuova voce per un
- file esistente, con la funzione \func{link}) al filesystem corrente.
+ 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 \index{inode} l'\textit{inode} in questione e rimossa la
vecchia (questa è la modalità in cui opera normalmente il comando \cmd{mv}
- attraverso la funzione \func{rename}).
+ attraverso la funzione \func{rename}). Questa operazione non modifica
+ minimamente neanche l'\textit{inode} del file dato che non si opera su
+ questo ma sulla directory che lo contiene.
+
+\item Gli \textit{inode} dei file, che contengono i \textsl{metadati} ed i
+ blocchi di spazio disco, che contengono i dati, sono risorse indipendenti ed
+ in genere vengono gestite come tali anche dai diversi filesystem; è pertanto
+ possibile sia esaurire lo spazio disco (caso più comune) che lo spazio per
+ gli \textit{inode}, nel primo caso non sarà possibile allocare ulteriore
+ spazio, ma si potranno creare file (vuoti), nel secondo non si potranno
+ creare nuovi file, ma si potranno estendere quelli che ci sono.
\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 fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory
-\file{img} nella directory \file{gapil}, avremo una situazione come quella in
+Infine si noti che, essendo file pure loro, il numero di riferimenti esiste
+anche per le directory; per cui, se a partire dalla situazione mostrata in
+fig.~\ref{fig:file_filesys_detail} creiamo una nuova directory \file{img}
+nella directory \file{gapil}, avremo una situazione come quella in
fig.~\ref{fig:file_dirs_link}, dove per chiarezza abbiamo aggiunto dei numeri
di \index{inode} inode.
\begin{figure}[htb]
\centering
\includegraphics[width=14cm]{img/dir_links}
- \caption{Organizzazione dei link per le directory.}
+ \caption{Organizzazione dei \textit{link} per le directory.}
\label{fig:file_dirs_link}
\end{figure}
referenziata anche dalla voce ``\texttt{..}'' di \texttt{img}.
-\subsection{Il filesystem \textsl{ext2}}
+\subsection{I filesystem di uso comune}
\label{sec:file_ext2}
-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, estensibili a 1012) con una dimensione massima di
-4~Tb.
+Il filesystem standard più usato con Linux è il cosiddetto \textit{third
+ extended filesystem}, identificato dalla sigla \acr{ext3}.\footnote{si fa
+ riferimento al momento della stesura di questo paragrafo, l'inizio del
+ 2010.} Esso nasce come evoluzione del precedente \textit{second extended
+ filesystem}, o \acr{ext2}, di cui eredita gran parte delle caratteristiche
+di base, per questo motivo parleremo anzitutto di questo, dato che molto di
+quanto diremo si applica anche ad \acr{ext3}. A partire dal kernel 2.6.XX è
+stato dichiarato stabile il nuovo filsesystem \textit{ext4}, ulteriore
+evoluzione di \textit{ext3} dotato di molte caratteristiche avanzate, che sta
+iniziando a sostituirlo gradualmente.
+
+Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
+prime versioni del kernel e supporta tutte le caratteristiche di un filesystem
+standard Unix: è in grado di gestire nomi di file lunghi (256 caratteri,
+estensibili a 1012) e supporta una dimensione massima dei file fino a 4~Tb. I
+successivi filesystem \acr{ext3} ed \acr{ext4} sono evoluzioni di questo
+filesystem, e sia pure con molti miglioramenti ed estensioni significative ne
+mantengono in sostanza le caratteristiche fondamentali.
Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che
-non sono presenti sugli altri filesystem Unix. Le principali sono le seguenti:
+non sono presenti su un classico filesystem di tipo Unix; le principali sono
+le seguenti:
\begin{itemize}
\item i \textit{file attributes} consentono di modificare il comportamento del
kernel quando agisce su gruppi di file. Possono essere impostati su file e
Ciascun gruppo di blocchi contiene una copia delle informazioni essenziali del
filesystem (superblock e descrittore del filesystem sono quindi ridondati) per
una maggiore affidabilità e possibilità di recupero in caso di corruzione del
-superblock principale.
+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 \index{inode} inode.
\begin{figure}[htb]
\centering
\label{fig:file_ext2_dirs}
\end{figure}
-L'utilizzo di raggruppamenti di blocchi ha inoltre degli effetti positivi
-nelle prestazioni dato che viene ridotta la distanza fra i dati e la tabella
-degli \index{inode} inode.
-
Le directory sono implementate come una \itindex{linked~list} \textit{linked
list} con voci di dimensione variabile. Ciascuna voce della lista contiene
il numero di inode \index{inode}, la sua lunghezza, il nome del file e la sua
è possibile implementare nomi per i file anche molto lunghi (fino a 1024
caratteri) senza sprecare spazio disco.
+Con l'introduzione del filesystem \textit{ext3} sono state introdotte anche
+alcune modifiche strutturali, la principale di queste è quella che
+\textit{ext3} è un filesystem \textit{jounrnaled}, è cioè in grado di eseguire
+una registrazione delle operazioni di scrittura su un giornale (uno speciale
+file interno) in modo da poter garantire il ripristino della coerenza dei dati
+del filesystem\footnote{si noti bene che si è parlato di dati \textsl{del}
+ filesystem, non di dati \textsl{nel} filesystem, quello di cui viene
+ garantito un veloce ripristino è relativo ai dati della struttura interna
+ del filesystem, non di eventuali dati contenuti nei file che potrebbero
+ essere stati persi.} in brevissimo tempo in caso di interruzione improvvisa
+della corrente o di crollo del sistema che abbia causato una interruzione
+della scrittura dei dati sul disco.
+
+Oltre a questo \textit{ext3} introduce ulteriori modifiche volte a migliorare
+sia le prestazioni che la semplicità di gestione del filesystem, in
+particolare per le directory si è passato all'uso di alberi binari con
+indicizzazione tramite hash al posto delle \textit{linked list}, ottenendo un
+forte guadagno di prestazioni in caso di directory contenenti un gran numero
+di file.
+
+% TODO portare a ext3, ext4 e btrfs ed illustrare le problematiche che si
+% possono incontrare (in particolare quelle relative alla perdita di contenuti
+% in caso di crash del sistema)
+
% LocalWords: everything is device kernel filesystem sez pathname root glibc
% LocalWords: path filename bootloader proc name components fifo socket dev LF
% LocalWords: nell'header unistd stream dall'ANSI stdio locking POSIX fig type
% LocalWords: register superblock dell'inode stat entry cache dcache dentry ln
% LocalWords: l'inode lookup ops read write llseek ioctl readdir poll nell'I
-% LocalWords: multiplexing mmap fsync fasync seek MacOs group dall' dell' img
+% LocalWords: multiplexing mmap fsync fasync seek group dall' dell' img
% LocalWords: count unlink nell' rename gapil second Tb attributes BSD SVr gid
-% LocalWords: sgid append only log fs linux extented linked list
+% LocalWords: sgid append only log fs linux extented linked list third MacOS
%%% Local Variables:
projects / gapil.git / blobdiff