From: Simone Piccardi Date: Mon, 9 Jan 2012 19:31:32 +0000 (+0000) Subject: Correzioni varie X-Git-Url: https://gapil.gnulinux.it/gitweb/?a=commitdiff_plain;h=0f6ee8a8f46d13019502c311ee782ef07b7f45d8;p=gapil.git Correzioni varie --- diff --git a/filedir.tex b/filedir.tex index 514705b..1964e7d 100644 --- a/filedir.tex +++ b/filedir.tex @@ -61,8 +61,8 @@ astrazione che prevede quattro tipi di oggetti strettamente correlati: i filesystem, le \textit{dentry}, gli \textit{inode} ed i file. A questi oggetti corrispondono una serie di apposite strutture definite dal kernel che contengono come campi le funzioni di gestione e realizzano l'infrastruttura -del VFS. L'interfaccia è estremamente complessa, ne faremo pertanto una -trattazione estremamente semplificata che consenta di comprenderne i principi +del VFS. L'interfaccia è molto complessa, ne faremo pertanto una trattazione +estremamente semplificata che consenta di comprenderne i principi difunzionamento. Il VFS usa una tabella mantenuta dal kernel che contiene il nome di ciascun @@ -88,14 +88,14 @@ verrà inserita nella tabella, ed il nuovo filesystem comparirà in La struttura \kstruct{file\_system\_type}, oltre ad una serie di dati interni, come il nome del tipo di filesystem nel campo \var{name},\footnote{quello che viene riportato in \procfile{/proc/filesystems} e che viene usato come - parametro dell'opzione \texttt{-t} del comando \texttt{mount}.} contiene i -riferimenti alle funzioni di base che consentono l'utilizzo di quel -filesystem. In particolare la funzione \code{mount} del quarto campo è quella -che verrà invocata tutte le volte che si dovrà effettuare il montaggio di un -filesystem di quel tipo. Per ogni nuovo filesystem si dovrà allocare una di -queste strutture ed inizializzare i relativi campi con i dati specifici diquel -filesystem, ed in particolare si dovra creare anche la relativa versione della -funzione \code{mount}. + valore del parametro dell'opzione \texttt{-t} del comando \texttt{mount} che + indica il tipo di filesystem.} contiene i riferimenti alle funzioni di base +che consentono l'utilizzo di quel filesystem. In particolare la funzione +\code{mount} del quarto campo è quella che verrà invocata tutte le volte che +si dovrà effettuare il montaggio di un filesystem di quel tipo. Per ogni nuovo +filesystem si dovrà allocare una di queste strutture ed inizializzare i +relativi campi con i dati specifici di quel filesystem, ed in particolare si +dovrà creare anche la relativa versione della funzione \code{mount}. Come illustrato in fig.~\ref{fig:kstruct_file_system_type} questa funzione restituisce una \textit{dentry}, abbreviazione che sta per \textit{directory @@ -104,9 +104,10 @@ la \textit{pathname resolution}, ciascuna di esse corrisponde ad un \textit{pathname} e contiene il riferimento ad un \textit{inode}, che come vedremo a breve è l'oggetto usato dal kernel per identificare un un file.\footnote{in questo caso si parla di file come di un qualunque oggetto - generico che sta sul filesystem.} La \textit{dentry} ottenuta dalla chiamata -alla funzione \code{mount} sarà inserita in corrispondenza al -\textit{pathname} della directory in cui il filesystem è stato montato. + generico che sta sul filesystem e non dell'oggetto file del VFS cui + accennavamo prima.} La \textit{dentry} ottenuta dalla chiamata alla funzione +\code{mount} sarà inserita in corrispondenza al \textit{pathname} della +directory in cui il filesystem è stato montato. % NOTA: struct dentry è dichiarata in include/linux/dcache.h @@ -116,7 +117,7 @@ nella cosiddetta \textit{directory entry cache} (spesso chiamata in breve \textit{pathname} viene effettuata una ricerca nella \textit{dcache} per ottenere immediatamente la \textit{dentry} corrispondente,\footnote{il buon funzionamento della \textit{dcache} è in effetti di una delle parti più - critiche per le prestazioni del sistema.} che a sua ci darà, tramite + critiche per le prestazioni del sistema.} che a sua volta ci darà, tramite l'\textit{inode}, il riferimento al file. Dato che normalmente non è possibile mantenere nella \textit{dcache} le @@ -190,10 +191,10 @@ una struttura di tipo \kstruct{inode\_operation}, la cui definizione si può trovare nel file \texttt{include/kernel/fs.h} dei sorgenti del kernel. Questa struttura non è altro che una tabella di funzioni, ogni suo membro cioè -è un puntatore ad una funzione, e, come suggerisce il nome della struttura -stessa, queste funzioni, le principali delle quali sono riportate in -tab.~\ref{tab:file_inode_operations}) sono quelle che definiscono le -operazioni che il VFS può compiere su un \textit{inode}. +è un puntatore ad una funzione e, come suggerisce il nome della struttura +stessa, queste funzioni sono quelle che definiscono le operazioni che il VFS +può compiere su un \textit{inode}. Si sono riportate in +tab.~\ref{tab:file_inode_operations} le più rilevanti. \begin{table}[htb] \centering @@ -229,18 +230,19 @@ operazioni che il VFS può compiere su un \textit{inode}. Possiamo notare come molte di queste funzioni abbiano nomi sostanzialmente identici alle varie \textit{system call} con le quali si gestiscono file e -directory che tratteremo nel resto del capitolo. Quello che succede è che +directory, che tratteremo nel resto del capitolo. Quello che succede è che tutte le volte che deve essere eseguita una \textit{system call}, o una qualunque altra operazione su un \textit{inode} (come \texttt{lookup}) il VFS andrà ad utilizzare la funzione corrispondente attraverso il puntatore \var{i\_op}. Sarà allora sufficiente che nella realizzazione di un filesystem si crei una -opportuna istanza di \kstruct{inode\_operation} contenente i puntatori alla -implementazione di queste funzioni per quel filesystem e quel punto le -strutture \kstruct{inode} usate per gli oggetti di quel filesystem otterranno -il puntatore a detta istanza di \kstruct{inode\_operation} e verranno -automaticamente usate le funzioni corrette. +implementazione di queste funzioni per quel filesystem e si allochi una +opportuna istanza di \kstruct{inode\_operation} contenente i puntatori a dette +funzioni. A quel punto le strutture \kstruct{inode} usate per gli oggetti di +quel filesystem otterranno il puntatore alla relativa istanza di +\kstruct{inode\_operation} e verranno automaticamente usate le funzioni +corrette. Si noti però come in tab.~\ref{tab:file_inode_operations} non sia presente la funzione \texttt{open} che invece è citata in @@ -248,8 +250,9 @@ tab.~\ref{tab:file_file_operations}.\footnote{essa può essere comunque invocata dato che nella struttura \kstruct{inode} è presente anche il puntatore \func{i\_fop} alla struttura \kstruct{file\_operation} che fornisce detta funzione.} Questo avviene perché su Linux l'apertura di un -file richiede comunque un'altra operazione: l'allocazione di una struttura di -tipo \kstruct{file} che viene associata ad ogni file aperto nel sistema. +file richiede comunque un'altra operazione che mette in gioco l'omonimo +oggetto del VFS: l'allocazione di una struttura di tipo \kstruct{file} che +viene associata ad ogni file aperto nel sistema. I motivi per cui viene usata una struttura a parte sono diversi, anzitutto, come illustrato in sez.~\ref{sec:file_fd}, questa è necessaria per le @@ -327,7 +330,7 @@ stesso modo sulla porta seriale come su un normale file di dati, e lavorare sui file allo stesso modo indipendentemente dal filesystem. Il VFS realizza la quasi totalità delle operazioni relative ai file grazie -alle funzioni presenti nelle due strutture \kstruct{inode\_operation} +alle funzioni presenti nelle due strutture \kstruct{inode\_operation} e \kstruct{file\_operation}. Ovviamente non è detto che tutte le operazioni possibili siano poi disponibili in tutti i casi, ad esempio una \code{seek} non è realizzabile per un dispositivo come la porta seriale o per una fifo, @@ -352,34 +355,39 @@ proprie. Per questo 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 un sistema unix-like. -Lo spazio fisico di un disco viene usualmente diviso in partizioni; ogni -partizione può contenere un filesystem. Una possibile strutturazione -dell'informazione su un disco è riportata in fig.~\ref{fig:file_disk_filesys}, -in essa per semplicità si è fatto riferimento alla struttura del filesystem -\acr{ext2}, che prevede una separazione dei dati in \textit{block group} che -replicano il cosiddetto \textit{superblock} (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 \itindex{inode} \textit{inode} e lo spazio a -disposizione per i dati e le directory.\footnote{questo non è del tutto vero - per filesystem evoluti come \textsl{btrfs}, ma per il momento limitiamoci - alla implementazione classica.} +Una possibile strutturazione dell'informazione su un disco è riportata in +fig.~\ref{fig:file_disk_filesys}, dove si hanno tre filesystem su tre +partizioni. In essa per semplicità si è fatto riferimento alla struttura del +filesystem \acr{ext2}, che prevede una suddivisione dei dati in \textit{block + group}. All'interno di ciascun \textit{block group} viene anzitutto +replicato il cosiddetto \textit{superblock}, (la struttura che contiene +l'indice iniziale del filesystem e che consente di accedere a tutti i dati +sottostanti) e creata una opportuna suddivisione dei dati e delle informazioni +per accedere agli stessi. 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 la presenza di due tipi di risorse: gli +\itindex{inode} \textit{inode}, cui abbiamo già accennato in +sez.~\ref{sec:file_vfs_work}, che sono le strutture che identificano i singoli +oggetti sul filesystem, e i blocchi, che invece attengono allo spazio disco +che viene messo a disposizione per i dati in essi contenuti. \begin{figure}[!htb] \centering - \includegraphics[width=14cm]{img/disk_struct} + \includegraphics[width=12cm]{img/disk_struct} \caption{Organizzazione dello spazio su un disco in partizioni e filesystem.} \label{fig:file_disk_filesys} \end{figure} Se si va ad esaminare con maggiore dettaglio la strutturazione -dell'informazione all'interno del singolo filesystem, tralasciando i dettagli -relativi al funzionamento del filesystem stesso come la strutturazione in -gruppi dei blocchi, il superblock e tutti i dati di gestione possiamo -esemplificare la situazione con uno schema come quello esposto in -fig.~\ref{fig:file_filesys_detail}. +dell'informazione all'interno del filesystem \textsl{ext2}, tralasciando i +dettagli relativi al funzionamento del filesystem stesso come la +strutturazione in gruppi dei blocchi, il \textit{superblock} e tutti i dati di +gestione possiamo esemplificare la situazione con uno schema come quello +esposto in fig.~\ref{fig:file_filesys_detail}. \begin{figure}[!htb] \centering @@ -389,24 +397,26 @@ fig.~\ref{fig:file_filesys_detail}. \end{figure} Da fig.~\ref{fig:file_filesys_detail} si evidenziano alcune delle -caratteristiche di base di un filesystem, sulle quali è bene porre attenzione -visto che sono fondamentali per capire il funzionamento delle funzioni che -manipolano i file e le directory che tratteremo nel prossimo capitolo; in -particolare è opportuno ricordare sempre che: +caratteristiche di base di un filesystem, che restano le stesse anche su +filesystem la cui organizzazione dei dati è totalmente diversa da quella +illustrata, e sulle quali è bene porre attenzione visto che sono fondamentali +per capire il funzionamento delle funzioni che manipolano i file e le +directory che tratteremo nel prosieguo del capitolo. In particolare è +opportuno tenere sempre presente che: \begin{enumerate} -\item L'\textit{inode} \itindex{inode} contiene tutte le informazioni (i - cosiddetti \textsl{metadati}) riguardanti il file: il tipo di file, i +\item L'\textit{inode} \itindex{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} (vedi sez.~\ref{sec:file_stat}) fornisce provengono dall'\textit{inode}. Dentro una directory si troverà solo il nome del file e il numero \itindex{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_work}). + qui in poi chiameremo una \textsl{voce}, che abbiamo scelto 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_work}. \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 @@ -418,11 +428,13 @@ particolare è opportuno ricordare sempre che: file, ma si limita ad eliminare la relativa voce da una directory e decrementare il numero di riferimenti \itindex{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 \itindex{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. +\item All'interno di ogni filesystem ogni \textit{inode} è identificato da un + numero univoco. Il numero di \textit{inode} nella voce si riferisce ad un + \textit{inode} a questo numero e non ci può essere una directory che + contiene riferimenti ad \itindex{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. \item Quando si cambia nome ad un file senza cambiare filesystem, il contenuto del file non viene spostato fisicamente, viene semplicemente creata una diff --git a/img/dir_links.dia b/img/dir_links.dia index 82ac44f..7b0faf1 100644 Binary files a/img/dir_links.dia and b/img/dir_links.dia differ diff --git a/img/filesys_struct.dia b/img/filesys_struct.dia index f956256..c08ed10 100644 Binary files a/img/filesys_struct.dia and b/img/filesys_struct.dia differ diff --git a/listati/file_system_type.h b/listati/file_system_type.h index 4f4ceb9..dabe309 100644 --- a/listati/file_system_type.h +++ b/listati/file_system_type.h @@ -9,7 +9,5 @@ struct file_system_type { struct module *owner; struct file_system_type * next; struct list_head fs_supers; - - struct lock_class_key s_lock_key; ... };