X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=e001acb7d90bbd71042d8ea0987158e16d175c4c;hp=cee6e9a9f606b0d1153143edcc790e055879c9a1;hb=33a54e1bfa5e62cb90d84c2d5f2d0c53864f6bec;hpb=250b32a55733b307d2eae8afb50b64af1b7c0bc8 diff --git a/fileintro.tex b/fileintro.tex index cee6e9a..e001acb 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -1,6 +1,6 @@ %% 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", @@ -68,7 +68,7 @@ viene identificato dall'utente usando quello che viene chiamato 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 @@ -103,30 +103,31 @@ convenzione, sono inseriti nella directory \file{/dev}). 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 -sez.~\ref{sec:file_work_dir}) ed il pathname è detto \textsl{pathname - relativo} \itindsub{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 la -directory corrente coincida con la directory radice, allora il riferimento è a -se stessa. +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}. + +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 la directory corrente coincida con la directory radice, allora il +riferimento è a se stessa. + \itindend{pathname} @@ -202,33 +203,35 @@ VMS.\footnote{questo vale anche per i dispositivi a blocchi: la strutturazione \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} @@ -318,6 +321,9 @@ Linux, l'\acr{ext2} (e derivati). \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 @@ -408,8 +414,9 @@ 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 \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 @@ -455,7 +462,8 @@ tab.~\ref{tab:file_file_operations}. 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 @@ -481,7 +489,7 @@ tipo di file in questione. 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} @@ -503,7 +511,7 @@ partizione pu 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 @@ -539,74 +547,99 @@ particolare \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} La nuova directory avrà allora un numero di riferimenti pari a due, in quanto è referenziata dalla directory da cui si era partiti (in cui è inserita la -nuova voce che fa riferimento a \file{img}) e dalla voce \file{.} -che è sempre inserita in ogni directory; questo vale sempre per ogni directory -che non contenga a sua volta altre directory. Al contempo, la directory da -cui si era partiti avrà un numero di riferimenti di almeno tre, in quanto -adesso sarà referenziata anche dalla voce \file{..} di \file{img}. +nuova voce che fa riferimento a \texttt{img}) e dalla voce ``\texttt{.}'' che +è sempre inserita in ogni directory; questo vale sempre per ogni directory che +non contenga a sua volta altre directory. Al contempo, la directory da cui si +era partiti avrà un numero di riferimenti di almeno tre, in quanto adesso sarà +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 @@ -648,7 +681,9 @@ in gruppi di blocchi.\footnote{non si confonda questa definizione con 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 @@ -657,10 +692,6 @@ superblock principale. \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 @@ -668,6 +699,30 @@ lunghezza, secondo lo schema in fig.~\ref{fig:file_ext2_dirs}; in questo modo è 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 @@ -677,9 +732,9 @@ caratteri) senza sprecare spazio disco. % 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: