Mercurial > lilug > xfs
view slideshow.tex @ 8:60852a38c763 washlug
more stuff
author | Josef 'Jeff' Sipek <jeffpc@josefsipek.net> |
---|---|
date | Thu, 19 Mar 2009 16:41:53 -0400 |
parents | 6410a0499945 |
children | 7a09d49f78ab |
line wrap: on
line source
\documentclass{beamer} \usepackage{beamerthemeshadow} \title{XFS --- The Black Leather Jacket of filesystems} \author{Josef ``Jeff'' Sipek\\ $<$jeffpc@josefsipek.net$>$} \date{March 19, 2009} \begin{document} \frame{\titlepage} %\AtBeginSection[] %{ %\begin{frame} % \frametitle{Outline} % \tableofcontents[currentsection] %\end{frame} %} \section{History} \begin{frame} \frametitle{History: Stoneage (1992)} \begin{itemize} \item<2-> Berkeley's FFS was state of the art \item<3-> SGI's IRIX had EFS (FFS with extents) \item<4-> Many limitations \begin{itemize} \item<5-> Small file sizes (2 GB) \item<6-> Small filesystem sizes (8GB) \item<7-> Statically allocated metadata \item<8-> Long recovery times \item<9-> Slow operations on large directories \item<10-> No extended attributes \item<11-> No access control lists \end{itemize} \end{itemize} \end{frame} \begin{frame} \frametitle{History: Enlightenment (1993)} \begin{itemize} \item<2-> SGI makes XFS \begin{itemize} \item<3-> 'X' being a variable \item<4-> To be replaced later \item<5-> Name stuck \end{itemize} \item<6-> Radically departs from traditional filesystems \end{itemize} \end{frame} % % Features % \section{Features} \begin{frame} \frametitle{Features: Allocation} \begin{itemize} \item<2-> Delayed allocation \begin{itemize} \item<3-> Allocate on flush \item<3-> Write reserves disk space, decide where later \end{itemize} \item<4-> Pre-allocation \begin{itemize} \item<5-> Reserve space before it is written \item<5-> Minimizes fragmentation \end{itemize} \item<6-> Direct I/O support \begin{itemize} \item<6-> Currently only Linux fs with parallel direct I/O \end{itemize} \item<7-> Stripe aware allocator \end{itemize} \end{frame} \begin{frame} \frametitle{Features: Inodes} \begin{itemize} \item<2-> Dynamically allocated in clusters \item<3-> Inode size is mkfs option \begin{itemize} \item<3-> 256 Byte (default) -- 2 kByte (max) \end{itemize} \item<4-> Extended Attributes \begin{itemize} \item<5-> $<$name, value$>$ pairs \item<6-> Used by ACLs, Capabilities, SELinux, DMAPI \end{itemize} \end{itemize} \end{frame} \begin{frame} \frametitle{Features: Other} \begin{itemize} \item<2-> B+Trees \item<3-> 64-bit \item<4-> Variable block size (512 Bytes -- 64 kB) \begin{itemize} \item 512 Bytes -- \texttt{\textbf{PAGE\_SIZE}} \end{itemize} \item<5-> Allocation Groups \item<6-> Lots of utilities \item<7-> Direct I/O \item<8-> DMAPI \item<9-> Extended Attributes/ACL \item<10-> Online fs growth \item<11-> Very fast repair time \item<12-> Amazingly fast \end{itemize} \end{frame} \begin{frame} \frametitle{Why not use ext2?} \begin{itemize} \item<2-> Does not keep a journal \begin{itemize} \item<3-> fsck mandatory to recover after a crash \item<4-> fsck is dog slow \end{itemize} \end{itemize} \end{frame} \begin{frame} \frametitle{Why not use ext3?} \begin{itemize} \item<2-> 16TB filesystem limit \begin{itemize} \item<3-> Used to be 8TB until about 2 years ago \end{itemize} \item<4-> fsck is dog slow, although not as frequently needed as with ext2 \end{itemize} \end{frame} \begin{frame}[fragile] \frametitle{Why not use ext4?} \begin{itemize} \item<2-> Not considered mature/stable \item<3-> \emph{Many} cases still not properly handled \item<4-> fsck is dog slow, although not as frequently needed as with ext2 \item<5-> User-space still limited to 16TB \end{itemize} \uncover<6->{\begin{exampleblock}{} This is the next generation of the ext3 filesystem.\\ ...\\ If unsure, say N. \end{exampleblock}} \end{frame} \begin{frame} \frametitle{Why not use Reiserfs?} \begin{itemize} \item<2-> Not very actively maintained \item<3-> ``Forgotten'' \end{itemize} \end{frame} \begin{frame} \frametitle{Why not use JFS?} \begin{itemize} \item<2-> Doesn't perform as well as it should \item<3-> Not as actively maintained as developed \item<4-> The maintainer contributes the odd fix \end{itemize} \end{frame} \begin{frame} \frametitle{Why not use btrfs?} \begin{itemize} \item<2-> Not stable/mature \end{itemize} \end{frame} \begin{frame} \frametitle{Why \textit{use} XFS?} \begin{itemize} \item<2-> Stable, mature codebase \begin{itemize} \item<3-> Oldest journaling filesystem on Linux \end{itemize} \item<4-> Very well performing \item<5-> Very fast repair time (for the times you need it) \item<6-> DMAPI support (for HSM) \end{itemize} %% That all sounds great, but is using XFS really worth it? Well, let me show %% you an example... Once upon a time, there was a system admin. \end{frame} \begin{frame} \frametitle{Why \emph{not} use it?} \begin{itemize} \item<2-> No data journaling \item<3-> Got time to waste waiting for fsck to finish running \item<4-> Don't like leather jackets \end{itemize} \end{frame} % % Demos % \newcommand{\demo}[1]{\begin{frame}\frametitle{#1}\begin{center}Demo\end{center}\end{frame}} \section{Demos} \demo{\texttt{\textbf{mkfs}} \& \texttt{\textbf{mount}}} \demo{\texttt{\textbf{xfs\_check}} \& \texttt{\textbf{xfs\_repair}}} \demo{\texttt{\textbf{xfs\_growfs}}} \demo{\texttt{\textbf{xfsdump}} \& \texttt{\textbf{xfsrestore}}} \demo{\texttt{\textbf{xfs\_bmap}}} \demo{\texttt{\textbf{xfs\_io}}} \demo{\texttt{\textbf{xfs\_quota}}} \demo{\texttt{\textbf{xfs\_admin}}} \demo{\texttt{\textbf{xfs\_freeze}}} % % Wrap-up % \section{} \begin{frame} \frametitle{Questions?} \begin{center} \includegraphics[width=\textwidth]{xfs.eps} \end{center} \end{frame} \begin{frame} \frametitle{More info/Resources/Thanks} \begin{itemize} \item \url{http://oss.sgi.com/projects/xfs/} \item \url{http://www.xfs.org} \item \url{xfs@oss.sgi.com} \item \url{http://oss.sgi.com/projects/xfs/papers/ukuug2003.pdf} \item \url{http://en.wikipedia.org/wiki/Comparison_of_file_systems} \item Martin K. Petersen for the apt description of XFS \end{itemize} \end{frame} % % Extra slides % \section{Extra stuff} \begin{frame} \frametitle{ext4 faults} \begin{itemize} \item Where do I even \emph{begin}?! \item<2-> Does not compact extents \item<3-> ... \end{itemize} \end{frame} \begin{frame} \frametitle{What are extents?} \begin{itemize} \item<1-> Suppose you need to keep track of what blocks belong to a file \item<2-> Naturally: $<$offset, block nr$>$ \end{itemize} \end{frame} \begin{frame} % should be continuation of previous frame \frametitle{What are extents?} (FIXME: graphic showing a file with blocks pointing to blocks on disk) \end{frame} \begin{frame} % should be continuation of previous frame \frametitle{What are extents?} \begin{itemize} % continue list from before \item<1-> All works well... \item<2-> ...unless you have millions of blocks (1 million 4K blocks is 4GB) \item<3-> Extents express a range of blocks instead of a single block \item<4-> Rely on the fact that many times, blocks are contiguously used within a file \item<5-> For example: $<$offset, nr blocks, block nr$>$ \end{itemize} \end{frame} \begin{frame} % should be continuation of previous frame \frametitle{What are extents?} (FIXME: graphic showing a file with an extent instead of many pointers) \end{frame} \end{document}