translate VFS slide

Author: Vladimir Kotal

files.tex

@@ -382,62 +382,63 @@
 
 %%%%%
 
-\pdfbookmark[1]{Virtual FIle System}{VFS}
+\pdfbookmark[1]{Virtual File System}{VFS}
 
 \begin{slide}
-\sltitle{Virtuální systém souborů (Virtual File System)}
+\sltitle{Virtual File System}
 \begin{center}
 \input{img/tex/vfs.pstex_t}
 \end{center}
 \end{slide}
 
 \begin{itemize}
-\item \emph{FFS} uvedený ve 4.2BSD byl historicky druhý unixový filesystém.
-Někteří dodavatelé unixových systémů ho začali preferovat vzhledem k jeho
-lepšímu výkonu a novým možnostem, jiný zůstávali dále u \emph{s5fs} z důvodu
-zpětné kompatibility. To dále prohlubovalo problém již tak nedostatečné
-interoperability mezi různými unixovými systémy. Některým aplikacím navíc plně
-nevyhovoval ani jeden z těchto filesystémů. Postupně se také objevovala
-potřeba pracovat s ne-unixovými filesystémy, např. \emph{FAT}. A s rostoucí
-popularitou počítačových sítí se zvyšovala poptávka po sdíl{}ení souborů mezi
-jednotlivými systémy, což mělo za následek vznik distribuovaných filesystémů
--- např. \emph{NFS} (Network File System).
-\item vzhledem k výše popsané situaci bylo jen otázkou času, kdy dojde k
-fundamentálním změnám v infrastruktuře systému souborů, aby současně
-podporoval více typů filesystémů. Vzniklo několik různých implementací od
-různých výrobců, až se nakonec de facto standardem stala \emph{VFS/vnode}
-architektura od firmy Sun Microsystems. V dnešní době prakticky všechny
-unixové a u{}nix-like systémy podporují VFS, i když často se vzájemně
-nekompatibilními úpravami. VFS se poprvé objevilo v roce 1985 v Solarisu 2.0;
-brzy bylo převzato BSD -- FFS s podporou VFS se začal nazývat UFS.
-\item hlavní myšlenka: každému otevřenému souboru v systému přísluší struktura
-\texttt{file}; to by vlastně byl jeden slot v námi již známé systémové tabulce
-otevřených souborů. Ta ukazuje na \emph{vnode} (\emph{virtual node}).  Vnode
-obsahuje část nezávislou na konkrétním systému souborů a část závislou, což
-může být například struktura \emph{inode}. Ta je specifická pro každý typ
-souborového systému. \emsl{Každý typ filesystému implementuje pevně danou
-sadu funkcí pro jednotlivé operace nad soubory}, na kterou se odkazují všechny
-virtuální uzly odpovídající danému typu filesystému. \emsl{Tato sada funkcí
-tedy definuje vnode interface.} Když tedy zavoláte například \texttt{open},
-jádro zavolá příslušnou implementaci v závislosti na typu filesystému (např. z
-modulu \emph{ext2fs}). Implementačně závislá část struktury vnode je přístupná
-pouze z funkcí příslušného typu filesystému; jádro do ní tedy ,,nevidí''
-přímo. Jak uvidíte na dalším slajdu, existuje ještě jedna sada funkcí, která
-se týka práce s filesystémy jako takovými. \emsl{Ta pak definuje VFS interface.}
-Tyto \emsl{dvě sady společně} tvoří vnode/VFS rozhraní, kterému se běžně říká
-jen VFS.
-\item (nebudu zkoušet) -- u speciálních souborů je situace složitější, v SVR4
-struktura \texttt{file} ukazuje na \emph{snode} (\emph{shadow-special-vnode}),
-který definuje operace se zařízením (pomocí souborového systému \emph{spec}) a
-prostřednictvím ukazatele \texttt{s\_realvp} se odkazuje na reálný vnode pro
-operace se speciálním souborem; ten je potřeba například pro kontrolu práv
-přístupu. Každému zařízení může odpovídat více speciálních souborů, a tedy více
-snodes a příslušných reálných vnodes. Všechny takové snodes pro jedno zařízení
-mají ukazatel \texttt{s\_commonvp} na jeden společný snode, to ale není na
-obrázku zachyceno.  Při otevření speciálního souboru se hledá v hash tabulce
-snodes otevřených zařízení po\-lož\-ka odpovídající speciálnímu souboru (podle
-major a minor čísla zařízení). Když snode není nalezen, vytvoří se nový. Tento
-snode se pak používá při operacích se zařízením. Více viz například [Vahalia].
+\item The \emph{FFS} filesystem introduced in 4.2BSD was historically the second
+unix filesystem. Some manufacturers of unix system started to prefer its
+considering its better performance and new features, others remained with 
+\emph{s5fs} from compatibility reasons. This deepened the problem with already
+insufficient interoperability between different unix systems. For some
+applications neither of these filesystems was enough. Gradually the need to work
+with non-unix systems started appearing, e.g. with \emph{FAT}. With growing
+popularity of computer networks the demand for file sharing between systems
+started to increase. This lead to the inception of distributed filesystems
+-- e.g. \emph{NFS} (Network File System).
+\item Given the above described situation it was just a matter of time when
+fundamental changes in the filesystem infrastructure will happen to support
+multiple filesystem types simultaneously. Several different implementations from
+multiple manufacturers were made; in the end the de facto standard became
+the \emph{VFS/vnode} architecture from Sun Microsystems. Today practically all
+unix u{}nix-like systems support VFS, even though with often non-compatible
+changes. VFS appeared for the first time in 1985 in Solaris 2.0;
+soon it was adopted by BSD -- FFS with VFS support started to be called UFS.
+\item the main idea: for each open file there is a \texttt{file} structure;
+it would be actually one slot in the already known system table of open files.
+This shows to \emph{vnode} (\emph{virtual node}). Vnode contains one part which
+is independent on given file system and one part dependent that could be e.g.
+the \emph{inode} structure. This is specific for each type of file system.
+\emsl{Each file system type implements concrete set of functions for individual
+file operations}. This set is referenced by each vnodes corresponding to given
+file system. \emsl{This set of functions define vnode interface.} When e.g.
+\texttt{open} is called, the kernel will call the corresponding implementation
+depending on file system type (e.g. from the \emph{ext2fs} module).
+Implementation dependent part of vnode structure is accessible only from
+functions of given filesystem; for kernel it is opaque. Next slide will shown
+another set of functions that works with filesystems themselves.
+\emsl{This set defines VFS interface.}
+These \emsl{two sets together} constitute the vnode/VFS interface, generally
+referred to as VFS.
+\item For special file types the situation is a bit more complicated, in SVR4
+the \texttt{file} structure points to \emph{snode}
+(\emph{shadow-special-vnode}), that defines operations with a device (using the
+\emph{spec} filesystem) and using the \texttt{s\_realvp} pointer it refers to
+real vnode for the operations with the special file; this file is necessary for
+example for checking file access rights. Each device can have multiple special
+files, hence more snodes and corresponding real vnodes. All such snodes for one
+device have the \texttt{s\_commonvp} pointer to one common snode, this is
+however not captured in the picture. When opening a special file, an item
+corresponding to the special file is searched in hash table of snodes of opened
+devices according to major and minor device number. If the snode is not found,
+new one is created. This snode will be then used for operations with the device.
+More in [Vahalia].
 \end{itemize}
 
 %%%%%