X-Git-Url: https://gapil.gnulinux.it/gitweb/?p=gapil.git;a=blobdiff_plain;f=fileintro.tex;h=640affb29676aaa9ec686287eb6178ac96da241e;hp=330f812b8a2a02dab3ebcc9bd94cbf10e93b93f9;hb=e20a546af590a50e7ac47f68f6c7d4648bb4f31a;hpb=00c2fb226b0ad73a87d5d86a25a149b61c5f9a53 diff --git a/fileintro.tex b/fileintro.tex index 330f812..640affb 100644 --- a/fileintro.tex +++ b/fileintro.tex @@ -19,6 +19,8 @@ nelle particolarit contempo tratteremo l'organizzazione dei file in un sistema unix-like, e le varie caratteristiche distintive. + + \section{L'organizzazione di file e directory} \label{sec:file_organization} @@ -87,7 +89,7 @@ directory; l'albero viene appunto creato inserendo directory in altre directory. Il nome completo di file generico è composto da una serie di nomi separati da -una \texttt{/} (in Linux più \texttt{/} consecutive sono considerate +una \file{/} (in Linux più \file{/} consecutive sono considerate equivalenti ad una sola). Il nome completo di un file viene usualmente chiamato \textit{pathname}, e anche se il manuale della glibc depreca questo nome (poiché genererebbe confusione, dato che con \textit{path} si indica @@ -104,7 +106,7 @@ precedente: ovviamente perch indicati come directory esistano e siano effettivamente directory, inoltre i permessi devono consentire l'accesso. -Se il pathname comincia per \texttt{/} la ricerca parte dalla directory radice +Se il pathname comincia per \file{/} la ricerca parte dalla directory radice del processo; questa, a meno di un \textit{chroot} (su cui torneremo in seguito, vedi \secref{sec:xxx_chroot}) è la stessa per tutti i processi ed equivale alla directory radice dell'albero (come descritto in @@ -197,7 +199,7 @@ L'interfaccia 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 file descriptors sono rappresentati da numeri interi (cioè +dispositivi); i file descriptor sono rappresentati da numeri interi (cioè semplici variabili di tipo \type{int}). L'interfaccia è definita nell'header \file{unistd.h}. @@ -215,10 +217,10 @@ del C, si accede ad essi sempre in maniera indiretta utilizzando il tipo Entrambe le interfacce possono essere usate per l'accesso ai file come agli altri oggetti del VFS (pipe, socket, device), ma per poter accedere alle operazioni di controllo sul particolare tipo di oggetto del VFS scelto occorre -usare l'interfaccia standard di unix coi file descriptors. Allo stesso modo +usare l'interfaccia standard di unix coi file descriptor. Allo stesso modo devono essere usati i file descriptor se si vuole ricorrere a modalità speciali di I/O come il polling o il non-bloccante (vedi -\secref{sec:file_xxx}). +\secref{sec:file_noblocking}). Gli stream forniscono un'interfaccia di alto livello costruita sopra quella dei file descriptor, che tratta tutti i file nello stesso modo, con @@ -316,6 +318,7 @@ l'\acr{ext2}, come esempio di un filesystem unix-like. % abbiamo brevemente accennato le caratteristiche (dal lato dell'implementazione % nel kernel) in \secref{sec:file_vfs}. + \subsection{Il \textit{virtual filesystem} di Linux} \label{sec:file_vfs} @@ -343,7 +346,7 @@ di I/O sul dispositivo fisico, secondo lo schema riportato in \nfig. \begin{figure}[htb] \centering - \includegraphics[width=7cm]{img/vfs.eps} + \includegraphics[width=7cm]{img/vfs} \caption{Schema delle operazioni del VFS} \label{fig:file_VFS_scheme} \end{figure} @@ -374,7 +377,7 @@ Il primo oggetto usato dal VFS una apposita struttura che contiene vari dati come le informazioni comuni ad ogni filesystem, i dati privati relativi a quel filesystem specifico, e i puntatori alle funzioni del kernel relative al filesystem. Il VFS può così -usare le funzioni contenute nel filesystem decriptor per accedere alle routine +usare le funzioni contenute nel filesystem descriptor per accedere alle routine specifiche di quel filesystem. Gli altri due descrittori usati dal VFS sono relativi agli altri due oggetti @@ -505,7 +508,7 @@ lista degli inodes e lo spazio a disposizione per i dati e le directory. \begin{figure}[htb] \centering - \includegraphics[width=9cm]{img/disk_struct.eps} + \includegraphics[width=9cm]{img/disk_struct} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem} \label{fig:file_disk_filesys} \end{figure} @@ -518,7 +521,7 @@ esemplificare la situazione con uno schema come quello esposto in \nfig. \begin{figure}[htb] \centering - \includegraphics[width=11cm]{img/filesys_struct.eps} + \includegraphics[width=11cm]{img/filesys_struct} \caption{Strutturazione dei dati all'interno di un filesystem} \label{fig:file_filesys_detail} \end{figure} @@ -571,7 +574,7 @@ chiarezza abbiamo aggiunto dei numeri di inode. \begin{figure}[htb] \centering - \includegraphics[width=11cm]{img/dir_links.eps} + \includegraphics[width=11cm]{img/dir_links} \caption{Organizzazione dei link per le directory} \label{fig:file_dirs_link} \end{figure} @@ -584,6 +587,7 @@ 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 adesso sarà referenziata anche dalla voce \file{..} di \file{img}. + \subsection{Il filesystem \textsl{ext2}} \label{sec:file_ext2} @@ -601,14 +605,14 @@ seguenti: kernel quando agisce su gruppi di file. Possono essere settati su file e directory e in quest'ultimo caso i nuovi file creati nella directory ereditano i suoi attributi. -\item sono supportate entrambe le semantiche di BSD e SYSV come opzioni di +\item sono supportate entrambe le semantiche di BSD e SVr4 come opzioni di montaggio. La semantica BSD comporta che i file in una directory sono creati con lo stesso identificatore di gruppo della directory che li contiene. La - semantica SYSV comporta che i file vengono creati con l'identificatore del + semantica SVr4 comporta che i file vengono creati con l'identificatore del gruppo primario del processo, eccetto il caso in cui la directory ha il bit di \acr{sgid} settato (per una descrizione dettagliata del significato di questi termini si veda \secref{sec:file_access_control}), nel qual caso file - e sotto-directory ereditano sia il \acr{gid} che lo \acr{sgid}. + e subdirectory ereditano sia il \acr{gid} che lo \acr{sgid}. \item l'amministratore può scegliere la dimensione dei blocchi del filesystem in fase di creazione, a seconda delle sue esigenze (blocchi più grandi permettono un accesso più veloce, ma sprecano più spazio disco). @@ -635,14 +639,14 @@ superblock principale. \begin{figure}[htb] \centering - \includegraphics[width=9cm]{img/dir_struct.eps} + \includegraphics[width=9cm]{img/dir_struct} \caption{Struttura delle directory nel \textit{second extented filesystem}.} \label{fig:file_ext2_dirs} \end{figure} -L'utilizzo di raggrupamenti di blocchi ha inoltre degli effetti positivi nelle +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 -inodes. +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 @@ -652,5 +656,3 @@ in questo modo - -