X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=14e4f274eb7ef4ef6ce9fafb414f67f1900e97c3;hp=40d8e2575d262890ff440b6f165c95eb1f563537;hb=81ff87c3e2a6ecd3e33867798cba0d27576f44d0;hpb=6db03808a639644251507d0f90f953117f893866 diff --git a/fileintro.tex b/fileintro.tex index 40d8e25..14e4f27 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -25,13 +25,13 @@ delle modalit \section{L'architettura generale} \label{sec:file_access_arch} -Per poter accedere ai file il kernel deve mettere a disposizione dei programmi -le opportune interfacce che consentano di leggerne il contenuto; il sistema -cioè deve provvedere ad organizzare e rendere accessibile in maniera opportuna -l'informazione tenuta sullo spazio grezzo disponibile sui dischi. Questo viene -fatto strutturando l'informazione sul disco attraverso quello che si chiama un -\textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi viene resa -disponibile ai processi attraverso quello che viene chiamato il +Per poter accedere ai file, il kernel deve mettere a disposizione dei +programmi le opportune interfacce che consentano di leggerne il contenuto; il +sistema cioè deve provvedere ad organizzare e rendere accessibile in maniera +opportuna l'informazione tenuta sullo spazio grezzo disponibile sui dischi. +Questo viene fatto strutturando l'informazione sul disco attraverso quello che +si chiama un \textit{filesystem} (vedi \ref{sec:file_arch_func}), essa poi +viene resa disponibile ai processi attraverso quello che viene chiamato il \textsl{montaggio} del \textit{filesystem}. % (approfondiremo tutto ciò in \secref{sec:file_arch_func}). @@ -47,21 +47,24 @@ In Unix, a differenza di quanto avviene in altri sistemi operativi, tutti i 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{anche se il manuale della \acr{glibc} depreca - questa nomenclatura, poiché genererebbe confusione, dato che con - \textit{path} si indica anche un insieme di directory su cui effettuare una - ricerca (come quello in cui si cercano i comandi) 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, comletata la fase di inizializzazione il kernel riceve -dal boot loader l'indicazione di quale dispositivo contiene il filesystem da -usare come punto di partenza e questo viene montato come radice dell'albero -(cioè nella directory \file{/}); tutti gli ulteriori filesystem che possono -essere su altri dispositivi dovranno poi essere inseriti nell'albero -montandoli su opportune directory del filesystem montato come radice. +\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{/}. + +All'avvio del sistema, completata la fase di inizializzazione, il kernel +riceve dal boot loader l'indicazione di quale dispositivo contiene il +filesystem da usare come punto di partenza e questo viene montato come radice +dell'albero (cioè nella directory \file{/}); tutti gli ulteriori filesystem +che possono essere su altri dispositivi dovranno poi essere inseriti +nell'albero montandoli su opportune directory del filesystem montato come +radice. Alcuni filesystem speciali (come \file{/proc} che contiene un'interfaccia ad alcune strutture interne del kernel) sono generati automaticamente dal kernel @@ -90,10 +93,11 @@ risoluzione del nome (\textit{file name resolution} o \textit{pathname resolution}). La risoluzione viene fatta esaminando il \textit{pathname} da sinistra a destra e localizzando ogni nome nella directory indicata dal nome precedente usando \file{/} 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 + 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 -\secref{sec:file_access_control}) devono consentire l'accesso. +\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 @@ -105,16 +109,16 @@ parte dalla directory corrente (su cui torneremo in 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 +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. +questa sia la directory radice, allora il riferimento è a se stessa. \subsection{I tipi di file} \label{sec:file_file_types} -Come detto in precedenza in Unix esistono vari tipi di file, in Linux questi +Come detto in precedenza, in Unix esistono vari tipi di file; in Linux questi 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 @@ -140,13 +144,13 @@ dati) in base al loro contenuto, o tipo di accesso. \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 sequenziale \\ + un file che identifica una periferica ad accesso a caratteri \\ \textit{block device} & \textsl{dispositivo a blocchi} & - un file che identifica una periferica ad accesso diretto \\ - \textit{fifo} & \textsl{``tubo''} & + 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{``spina''} & + \textit{socket} & \textsl{``presa''} & un file speciale che identifica una linea di comunicazione software (bidirezionale) \\ \hline @@ -160,27 +164,29 @@ VMS o Windows) 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 una forma di accesso diretto ai dischi - (il \textit{raw access}) attraverso dei device file appositi, che però non - ha nulla a che fare con questo}. - -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. Questo può causare alcuni +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 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. 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ò non ostante molti programmi adottano delle convenzioni per +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. - \subsection{Le due interfacce ai file} \label{sec:file_io_api} @@ -190,7 +196,7 @@ accedere al loro contenuto. La prima è l'interfaccia standard di Unix, quella che il manuale delle \acr{glibc} chiama interfaccia dei descrittori di file (o \textit{file - descriptor}). È un'interfaccia specifica dei sistemi unix-like e provvede + descriptor}). È un'interfaccia specifica dei sistemi unix-like e fornisce un accesso non bufferizzato; la tratteremo in dettaglio in \capref{cha:file_unix_interface}. @@ -199,33 +205,34 @@ 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 -rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}). +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 provvede funzioni più evolute e un accesso +\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}. 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 \type{FILE *}. L'interfaccia è definita nell'header \type{stdio.h}. +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 (pipe, socket, device, sui quali torneremo in dettaglio -a tempo opportuno), ma per poter accedere alle operazioni di controllo su un -qualunque tipo di oggetto del VFS occorre usare l'interfaccia standard di Unix -coi \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, 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}). Gli \textit{stream} forniscono un'interfaccia di alto livello costruita sopra quella dei \textit{file descriptor}, che permette di poter scegliere tra diversi stili di bufferizzazione. Il maggior vantaggio degli \textit{stream} è che l'interfaccia per le operazioni di input/output è enormemente più ricca -di quella dei \textit{file descriptor}, che provvedono solo funzioni +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 @@ -325,24 +332,25 @@ Linux, l'\acr{ext2}. In Linux il concetto di \textit{everything is a file} è stato implementato attraverso il \textit{Virtual Filesystem} (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 provvede +mantenendo la stessa interfaccia per i programmi in user space. Esso fornisce un livello di indirezione che permette di collegare le operazioni di manipolazione sui file alle operazioni di I/O, e gestisce l'organizzazione di -queste ultime nei vari modi in cui diversi filesystem le effettuano, +queste ultime nei vari modi in cui i diversi filesystem le effettuano, permettendo la coesistenza di filesystem differenti all'interno dello stesso albero delle directory. -Quando un processo esegue una system call che opera su un file il kernel +Quando un processo esegue una system call che opera su un file, il kernel chiama sempre una funzione implementata nel VFS; la funzione eseguirà le -manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alla +manipolazioni sulle strutture generiche e utilizzerà poi la chiamata alle opportune routine del filesystem specifico a cui si fa riferimento. Saranno queste a chiamare le funzioni di più basso livello che eseguono le operazioni -di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. +di I/O sul dispositivo fisico, secondo lo schema riportato in +\figref{fig:file_VFS_scheme}. \begin{figure}[htb] \centering \includegraphics[width=7cm]{img/vfs} - \caption{Schema delle operazioni del VFS} + \caption{Schema delle operazioni del VFS.} \label{fig:file_VFS_scheme} \end{figure} @@ -468,12 +476,12 @@ operazioni previste dal kernel In questo modo per ciascun file diventano possibili una serie di operazioni (non è detto che tutte siano disponibili), che costituiscono l'interfaccia -astratta del VFS. Qualora se ne voglia eseguire una il kernel andrà ad -utilizzare la opportuna routine dichiarata in \var{f\_ops} appropriata al tipo +astratta del VFS. Qualora se ne voglia eseguire una, il kernel andrà ad +utilizzare l'opportuna routine dichiarata in \var{f\_ops} appropriata al tipo di file in questione. In questo modo è possibile scrivere allo stesso modo sulla porta seriale come -su un file di dati normale; ovviamente certe operazioni (nel caso della +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 @@ -486,9 +494,9 @@ programmatore. Come già accennato in \secref{sec:file_organization} Linux (ed ogni sistema unix-like) organizza i dati che tiene su disco attraverso l'uso di un filesystem. Una delle caratteristiche di Linux rispetto agli altri Unix è -quella di poter supportare grazie al VFS una enorme quantità di filesystem +quella di poter supportare, grazie al VFS, una enorme quantità di filesystem diversi, ognuno dei quali ha una sua particolare struttura e funzionalità -proprie. Per questo per il momento non entreremo nei dettagli di un +proprie. Per questo, per il momento non entreremo nei dettagli di un filesystem specifico, ma daremo una descrizione a grandi linee che si adatta alle caratteristiche comuni di qualunque filesystem di sistema unix-like. @@ -505,7 +513,8 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory. \begin{figure}[htb] \centering \includegraphics[width=12cm]{img/disk_struct} - \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} + \caption{Organizzazione dello spazio su un disco in partizioni e + filesystem.} \label{fig:file_disk_filesys} \end{figure} @@ -518,7 +527,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig. \begin{figure}[htb] \centering \includegraphics[width=12cm]{img/filesys_struct} - \caption{Strutturazione dei dati all'interno di un filesystem} + \caption{Strutturazione dei dati all'interno di un filesystem.} \label{fig:file_filesys_detail} \end{figure} @@ -546,7 +555,7 @@ ricordare sempre che: 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 a eliminare la relativa voce da una directory e + file, ma si limita ad eliminare la relativa voce da una directory e decrementare il numero di riferimenti nell'\textit{inode}. \item Il numero di \textit{inode} nella voce si riferisce ad un \textit{inode} @@ -554,25 +563,25 @@ ricordare sempre che: 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. - -\item Quando si cambia nome ad un file senza cambiare filesystem il contenuto - del file non deve essere spostato, 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}). + +\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}). \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 +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 +\file{gapil}, avremo una situazione come quella in \nfig, dove per chiarezza abbiamo aggiunto dei numeri di inode. \begin{figure}[htb] \centering \includegraphics[width=12cm]{img/dir_links} - \caption{Organizzazione dei link per le directory} + \caption{Organizzazione dei link per le directory.} \label{fig:file_dirs_link} \end{figure} @@ -580,8 +589,8 @@ La nuova directory avr è 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 riferiementi di almeno tre, in quanto +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}. @@ -591,11 +600,11 @@ adesso sar Il filesystem standard usato da Linux è il cosiddetto \textit{second extended filesystem}, identificato dalla sigla \acr{ext2}. Esso supporta tutte le caratteristiche di un filesystem standard Unix, è in grado di gestire nomi di -file lunghi (256 caratteri, estendibili a 1012), una dimensione fino a 4~Tb. +file lunghi (256 caratteri, estendibili a 1012) con una dimensione massima di +4~Tb. -Oltre alle caratteristiche standard \acr{ext2} fornisce alcune estensioni che -non sono presenti sugli altri filesystem Unix, le cui principali sono le -seguenti: +Oltre alle caratteristiche standard, \acr{ext2} fornisce alcune estensioni che +non sono presenti sugli altri filesystem 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 settati su file e