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}
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}
\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
+ i puntatori ai blocchi fisici che contengono i dati e così via, cioè quelli
+ che in genere vengono chiamati i \textsl{metadati} del file; 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}).
+ 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}.
-% 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)
-
\subsection{I filesystem di uso comune}
\label{sec:file_ext2}
Il filesystem standard più usato con Linux è il cosiddetto \textit{third
extended filesystem}, identificato dalla sigla \acr{ext3}. 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}.
-
+di cui eredita gran parte delle caratteristiche di base, per questo, per
+mantenere un minimo di semplicità, parleremo anzitutto di questo, dato che
+molto di quanto diremo si applica anche ad \acr{ext3}.
Il filesystem \acr{ext2} nasce come filesystem nativo di Linux a partire dalle
prime versioni del kernel e supporta tutte le caratteristiche di un
\texttt{ext2\_fs.h} nella directory \texttt{include/linux} dei sorgenti del
kernel.}
-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.
-
\begin{figure}[htb]
\centering
\includegraphics[width=9cm]{img/dir_struct}
\label{fig:file_ext2_dirs}
\end{figure}
+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.
+
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.
è possibile implementare nomi per i file anche molto lunghi (fino a 1024
caratteri) senza sprecare spazio disco.
+% 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 third
+% LocalWords: sgid append only log fs linux extented linked list third MacOS
%%% Local Variables:
projects / gapil.git / blobdiff