%\documentclass[colorBG,slideColor,troispoints,pdf]{prosper}
\documentclass[colorBG,total,slideColor,pdf]{prosper}
%\documentclass[colorBG,slideColor,ps]{prosper}

\usepackage{alltt,key,xr,cols,rcs,acro,nick,%
  graphicx,varioref,explanation,booktabs,calc}
\usepackage[nolineno,noindent]{lgrind}

\definecolor{green}{rgb}{0,1,0}

\RCS $Revision: 1.1 $

\renewcommand*{\bs}{\texttt{\char '134}} % Backslash `\'
\newcommand*{\labTitle}{Processes and Threads}
\newcommand*{\subject}{Operating Systems and Systems Integration}
\newcommand*{\emphcolour}[1]{\emph{\red#1}}

\providecommand*{\RPM}{\acro{RPM}\xspace}
\providecommand*{\CD}{\acro{CD}\xspace}
\providecommand*{\IPC}{\acro{IPC}\xspace}
\providecommand*{\UID}{\acro{UID}\xspace}
\providecommand*{\GID}{\acro{GID}\xspace}
\providecommand*{\SMP}{\acro{SMP}\xspace}
\providecommand*{\API}{\acro{API}\xspace}
\providecommand*{\IRQ}{\acro{IRQ}\xspace}
\providecommand*{\PIC}{\acro{PIC}\xspace}
\providecommand*{\NIC}{\acro{NIC}\xspace}
\providecommand*{\ATA}{\acro{ATA}\xspace}
\providecommand*{\LVM}{\acro{LVM}\xspace}

\title{Input and Output}
\subtitle{Reference: \emph{Operating Systems}, Fourth Edition, William
  Stallings, Chapters 11, 12}
\author{Nick Urbanik \texttt{<nicku\at{}vtc.edu.hk>}\\
\footnotesize{}Copyright Conditions: GNU FDL (see
\url{http://www.gnu.org/licenses/fdl.html})}
\institution{Department of Information and Communications Technology}
\slideCaption{OSSI --- Input/Output --- ver. \RCSRevision}
\Logo{\includegraphics[width=15mm]{ict-logo-smaller}}

\begin{document}
\maketitle

\begin{slide}{Input/Output}
\Huge
\begin{center}
What is involved in input/output?
\end{center}

\vfill

\begin{center}
How does the operating system manage I/O?
\end{center}
\end{slide}

\begin{slide}{I/O --- Enormous Variety}
  \begin{itemize}
  \item Three main categories:
    \begin{description}
    \item[\red{}Human readable:] video displays, printers, keyboard, mouse
    \item[\red{}Machine readable:] disk, \CDROM, tape drives, sensors,
      controllers, actuators
    \item[\red{}Communications:] network cards, modems
    \end{description}
  \end{itemize}
\end{slide}

\begin{slide}{Differences in I/O Devices}
  \begin{description}
  \item[\red{}Data rate:] Speeds of \IO devices vary greatly:
    {\green{}Fast:} Gigabit Ethernet --- $10^9$\,bps,
    {\green{}Slow:} keyboard --- $10^2$\,bps
  \item[\red{}Application:] \OS Policies and supporting utilities
    required depend on application.  Disks holding files need file
    management support.  Disks for swap require virtual memory
    hardware and software.
  \item[\red{}Complexity of control:] A printer has a simple control
    interface; a disk has a complex control interface.
  \item[\red{}Unit of transfer:] Can transfer a stream of bytes (e.g.,
    keyboard), or large blocks of data (e.g., disk \IO)
  \item[\red{}Data representation:] Different data encoding schemes
  \item[\red{}Error conditions:] Type of errors, way they are reported
    vary greatly
  \end{description}
\end{slide}

\begin{slide}{Techniques of I/O}
  \begin{description}
  \item[\blue{}Programmed \IO:] \CPU gives \IO command; \CPU polls in
    a loop waiting for \IO to complete (busy waiting)
  \item[\blue{}Interrupt-driven \IO:] \CPU gives \IO command,
    continues with some other work, then \IO module sends interrupt to
    \CPU when it is finished.
  \item[\blue{}Direct memory access (\DMA):] A \DMA controller moves
    data between memory and \IO device \emphcolour{independently of
      \CPU}.  \CPU simply tells \DMA controller \emphcolour{where} to
    move data, and \emphcolour{how much}, \DMA controller does the
    rest.  \DMA controller interrupts \CPU when finished.
  \end{description}
\end{slide}

\begin{slide}{What is I/O?}
  \begin{itemize}
  \item Involves transferring data to/from hardware, e.g.
    \begin{itemize}
    \item Printers, hard disks, mice, displays, cameras,
      networks,\ldots
    \end{itemize}
  \item Hardware often has support for data transfer independent of
    main \CPU, e.g., \DMA, \CPU on \IO device.
  \item \CPU will have some involvement
  \item \mbox{}\emphcolour{Disk I/O is very important}, and most
      effort in improving \IO in \OS goes into improving disk \IO
    \end{itemize}
\end{slide}

\begin{slide}{I/O (usually) limits execution speed}
\begin{itemize}
\item Most processes perform a burst of:
  \begin{itemize}
  \item \CPU activity
  \item \IO activity
  \item \CPU activity
  \item \IO activity \ldots
  \end{itemize}
\item Even with maximum priority, most processes are limited by the
  \IO they perform.
\item We say that most processes are \emphcolour{I/O bound}
  \begin{itemize}
  \item If a process performs much computation, but little \IO, it is
    said to be \emphcolour{CPU bound}
  \end{itemize}
\end{itemize}
\end{slide}

\begin{slide}{PC architecture}
  \centering%
  \includegraphics[width=0.5\slideWidth]{p4-architecture}
\end{slide}

\begin{slide}{I/O ports}
\begin{itemize}
\item Registers in \IO interface, often grouped into:
  \begin{itemize}
  \item Control registers
  \item Status registers
  \item Input register
  \item Output register
  \end{itemize}
\item Originally mostly connected to ``\IO bus''
\item Use only \texttt{in}, \texttt{out} machine instructions
\item Memory mapped \IO ports more common now
\item PCI cards use high addresses
\end{itemize}
\end{slide}


\begin{slide}{Memory mapped I/O}
\begin{itemize}
\item \IO ports can be mapped into the same address space as \RAM, \ROM.
\item Full range of normal instructions can be used to access \IO ports
\item Fuller address space available
\end{itemize}
\end{slide}

\begin{slide}{I/O mapped I/O --- 1}
  \centering%
  \includegraphics[width=\slideWidth]{io-memory}
\end{slide}

\begin{slide}{I/O mapped I/O --- 2}
\begin{itemize}
\item The diagram may be just conceptual
  \begin{itemize}
  \item There is a \emphcolour{logically separate} data and address bus
    for \IO ports
  \item Some hardware provides a separate bus dedicated to \IO, e.g.
    \PCI
  \end{itemize}
\item Limited special instructions perform input or output to port.
\item On Intel architecture, only $2^{16}$ different port addresses
  available for \ISA devices
\end{itemize}
\end{slide}

\begin{slide}{I/O interface}
\begin{itemize}
\item An \emphcolour{I/O interface} is a hardware circuit between 
\item some \IO ports and their
\item device controller
\item Often connected to Programmable Interrupt controller through
  \IRQ line
\item Can have
\item Custom \IO interface, or
\item General purpose \IO interface
\end{itemize}
\end{slide}

\begin{slide}{Examples of I/O interfaces}
  % See \label{bib:B&C} for this categorisation
  \begin{minipage}[t]{4\slideWidth/9}
    \begin{center}
      \textbf{Custom interfaces}
    \end{center}
    \begin{itemize}
    \item Specialised to a particular function
    \item Examples:
      \begin{itemize}
      \item Keyboard
      \item Graphic display
      \item Disk
      \item Network
      \end{itemize}
    \end{itemize}
  \end{minipage}%
  \hspace*{1em}%
  \begin{minipage}[t]{4\slideWidth/9}
    \begin{center}
      \textbf{General interfaces}
    \end{center}
    \begin{itemize}
    \item Can plug in many types of device
    \item Examples:
      \begin{itemize}
      \item Parallel port
      \item Serial port
      \item \USB port
      \item \PCMCIA
      \item \SCSI
      \end{itemize}
    \end{itemize}
  \end{minipage}
\end{slide}

\begin{slide}{I/O controller}
\begin{itemize}
\item Hardware used by complex devices, e.g., disk controller
\item Interprets high level commands received by interface through \IO ports
\item Converts these to complex operations on the hardware
\item Simpler devices have no device controller, e.g., \PIC and \PIT
\end{itemize}
\end{slide}

\begin{slide}{Methods of I/O}
\begin{itemize}
\item There are three basic methods of \IO:
  \begin{itemize}
  \item \DMA (Direct Memory Access)
  \item Interrupt-driven \IO
  \item polling
  \end{itemize}
\end{itemize}
\end{slide}

\begin{slide}{\DMA}
\begin{itemize}
\item Used on PCI bus and ATA hard disks
\item A special processor called a \emphcolour{DMA controller} (\DMAC)
  takes over from \CPU
\item Transfers data rapidly, no need to fetch instructions
\item Called a \emphcolour{bus master} because it takes over the buses
  from \CPU
\item \PC has five \ISA \DMA channels, and also special \DMA
  controllers built into \PCI controller
\end{itemize}
\end{slide}

\begin{slide}{Interrupts}
\begin{itemize}
\item PC supports 15 hardware interrupts
\item Each interrupt is a hardware connection from \IO device to \CPU
\item Goes through a \PIT (Programmable interrupt controller) module
\item Interrupts have different priorities
\item Notice that \IO devices usually use interrupts
\end{itemize}
\end{slide}

\begin{slide}{What is an interrupt?  Example}
\begin{itemize}
\item Use serial port (\UART) as an example
\item \UART = Universal Asynchronous Receiver/Transmitter = an \IC
\item Receives/transmits characters one bit at a time.
\item Frame each char with start/stop bit
\end{itemize}
\end{slide}

\begin{slide}{Interrupt example: UART --- 2}
\begin{itemize}
\item When character is finally received by \UART:
  \begin{enumerate}
  \item \UART sends hardware signal to \CPU
  \item \CPU determines whether priority higher than current task---if
    so,
  \item \CPU stores program counter (\PC), some other registers on
    \emphcolour{stack}
  \item Executes a subroutine called an \ISR (interrupt Service
    Routine) that allows \CPU to copy character(s) from \UART to
    buffer in \RAM
  \item \CPU restores PC, registers, continues from where it left off.
\end{enumerate}
\end{itemize}
\end{slide}

\begin{slide}{Polling}
\begin{itemize}
\item \IO device has a register
\item \CPU checks a flag in this register in a loop.
\item \CPU may be busy, unable to do other tasks, so waste time
\item But simpler than other \IO methods
\end{itemize}
\end{slide}

\begin{slide}{Input/Output: how?}
\begin{itemize}
\item In the old days, (\MSDOS), application programs would write
  directly to input/output hardware
\item Examples: hardware = registers in \UART, or \DMAC, other registers
  in \IO device
\item Problems: if program has bug, whole system hangs: unreliable
\item What if two processes want the same resource?
\end{itemize}
\end{slide}

\begin{slide}{I/O: how now? --- 2}
\begin{itemize}
\item Each hardware device has a \emphcolour{device driver}.
\item High level command $\to$ Device driver $\to$ low level actions
\item Application uses same high level commands with different
  hardware
\item Provides modularity
\end{itemize}
\end{slide}

\begin{slide}{Advantages of device drivers}
\begin{itemize}
\item Reliability
\item \OS controls access to the hardware
\item Modular system possible, e.g. Linux has dynamically loading modules
\item Separate kernel from low-level details of hardware.
\item In Linux, device drivers part of the kernel distribution.
\end{itemize}
\end{slide}

\begin{slide}{Installing a driver (e.g. for \NIC)}
\begin{itemize}
\item To install the driver for a 3Com 3c59x card in Linux, simply do:
\item \texttt{modprobe 3c59x}
\item To install it permanently for \texttt{eth0},
  \begin{itemize}
  \item Edit \texttt{/etc/modules.conf}
  \item Add the line:
  \item \texttt{alias eth0 3c59x}
  \item Restart networking on that \NIC with \texttt{ifup eth0}
  \item Do not reboot!
  \end{itemize}
\item Command \texttt{lsmod} lists all installed drivers; drivers are
  usually loadable modules.
\end{itemize}
\end{slide}

\begin{slide}{Block and character devices}
\label{sld:block-char}%
\begin{itemize}
\item \emphcolour{Block devices} include disks
  \begin{itemize}
  \item Provide random access
  \item Data transferred in \emphcolour{fixed-sized} blocks
  \end{itemize}
\item \emphcolour{Character devices} include serial devices, printers
  \begin{itemize}
  \item Transfer data in \emphcolour{variable sized} chunks
  \item Provide sequential access
  \end{itemize}
\end{itemize}
\end{slide}

\begin{slide}{I/O Buffering --- 1}
  \begin{itemize}
  \item Buffering provides two benefits:
    \begin{itemize}
    \item Improves \emphcolour{performance}
    \item Allows process to be \emphcolour{swapped out} of \RAM while \OS performs
      \IO for the process
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{I/O Buffering --- 2}
  \begin{itemize}
  \item If transfer \IO data directly to or from a slow device to a
    process, the memory page getting or providing the data must stay
    in \RAM
  \item \mbox{}{\red{}So \OS could not completely swap out this process}
  \item More \emphcolour{efficient} to use \emphcolour{buffering}:
    \begin{itemize}
    \item perform \emphcolour{input} transfer \emphcolour{before} the
      data is required
    \item perform \emphcolour{output} sometime \emphcolour{later} than
      when request is made.
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Single Buffer}
  \begin{itemize}
  \item \OS requests one block of data before it is needed --- read
    ahead.
  \item \IO device fills block
  \item Application finds data is there immediately it is required
  \end{itemize}
\end{slide}

\begin{slide}{Double Buffer}
  \begin{itemize}
  \item Use two memory buffers instead of one.
  \item While \OS fills one buffer, user process empties the other.
  \item Very important for process that {\green{}continuously provides
      data}, such as \emphcolour{data acquisition}, since data may be
    lost with a single buffer, as the input cannot be paused while
    emptying the buffer ready for new data
  \end{itemize}
\end{slide}

\begin{slide}{Case Study: \DMA and Double Buffering --- 1}
  \begin{itemize}
  \item I wrote software some years ago to collect data, analyse the
    data, graph the data, and write the data to disk
  \item Used \DMA on the \ISA bus (A Data Translation DT2821 data
    acquisition card)
  \item The DT2821 used an interrupt and two \DMA channels
  \item The device driver initialised the two \DMA channels with this
    information:
    \begin{itemize}
    \item The \emphcolour{direction} of data transfer (read or write)
    \item The \emphcolour{address} of the \DMA buffer
    \item The \emphcolour{size} of the \DMA buffer
    \end{itemize}
  \end{itemize}
\end{slide}  

\begin{slide}{Case Study: \DMA and Double Buffering --- 2}
  \begin{itemize}
  \item The device driver enables the \DMA controller
    \begin{itemize}
    \item The \DMA controller transfers data from DT2821 to the \DMA
      buffer
    \end{itemize}
  \item When \DMA buffer filled, \DMAC raises an interrupt
  \item The Interrupt Service Routine (\ISR) {\red{}starts the other
      \DMA channel}, then re-programs the \DMA controller that has
    just finished.
  \end{itemize}
\end{slide}

\begin{slide}{Buffer in Process or Device Driver?}
  \begin{itemize}
  \item Should we put the buffers in the process that uses the data or
    should we put it in the device driver?
  \item For most applications, should \emphcolour{put buffers in
      device driver}
    \begin{itemize}
    \item Allows process to be swapped out during \IO
    \item Avoids problems with special memory needs of special \IO
      devices:
      \begin{itemize}
      \item High speed \DMA requires the buffer to be continuous
        memory, not pages scattered about in \RAM
      \end{itemize}
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Main Effects of Buffering}
  \begin{itemize}
  \item Smooth out peaks of \IO demand
  \item Allow processes to be swapped in and out, regardless of state
    of \IO for the process
  \end{itemize}
\end{slide}

\begin{slide}{Device files --- 1}
  \begin{itemize}
  \item In Linux and \UNIX, most \IO devices are accessed through a
    \emphcolour{device file}
  \item These are in the \texttt{/dev} directory.
  \item Why?
    \begin{itemize}
    \item Allows device access to be managed using file access
      permissions
    \item Provides a uniform access method to all \IO devices, similar
      to those used to access files
    \end{itemize}
  \item Example: a temperature controller device file may give the
    current temperature when read it
  \item Example: the same \texttt{write()} system call can write data
    to an ordinary file or send it to a printer by writing to the
    \texttt{/dev/lp0} device.
    % See page 437 of \emph{Understanding the Linux Kernel}, Second
    % Edition, 
  \end{itemize}
\end{slide}

\begin{slide}{Device files --- 2}
  \begin{itemize}
  \item There are two types of device files as mentioned in
  slide~\ref{sld:block-char}: {\green{}block} and {\green{}character}
  \item Each device file has two numbers:
    \begin{itemize}
    \item Major number
    \item Minor number
    \end{itemize}
  \item These two numbers, and the type, uniquely identify a device
    and its device file.
\begin{alltt}\tiny
$ \textbf{ls -l /dev/hd[a-d]}
brw-rw----    1 root     disk       3,   0 Oct 22 22:53 /dev/hda
brw-rw----    1 root     disk       3,  64 Aug 31  2002 /dev/hdb
brw-rw----    1 root     disk      22,   0 Aug 31  2002 /dev/hdc
brw-rw----    1 root     disk      22,  64 Aug 31  2002 /dev/hdd
\end{alltt}%$
  \item Note: major number is on the left, minor number is on the
  right; for \texttt{/dev/hdd}, major is 22, minor is 64
  \end{itemize}
\end{slide}

\begin{slide}{Device files --- 3}
  \begin{itemize}
  \item How do I know what device numbers my hardware should have?
    \begin{itemize}
    \item see the file \texttt{devices.txt} that is part of the kernel
      source code:
      \begin{alltt}
$ \textbf{rpm -ql kernel-doc | grep '/devices.txt'}
/usr/share/doc/kernel-doc-2.4.18/devices.txt
\end{alltt}%$
    \end{itemize}
  \item How do I create a device file if it is missing (for eaxample,
    on a rescue disk?)
    \begin{itemize}
    \item Use the \texttt{mknod} command.
    \item See also the command \texttt{/dev/MAKEDEV}, which also has
      its manual page.
    \end{itemize}
  \end{itemize}
\end{slide}

\begin{slide}{Monitoring I/O performance}
\begin{itemize}
\item Both \texttt{vmstat} and \texttt{procinfo} provide information about \IO.
\item Also \texttt{sar -b}
\item \texttt{iostat} gives details of data transfers to/from each
  hard disk
\item The command \texttt{hdparm -tT} gives some basic performance
  parameters for your hard disks.
\item \texttt{hdparm} and \texttt{hdparm -i} gives other info about your
  hard disks.
\item \texttt{netstat -i}, \texttt{ifconfig} and \texttt{ip
    -statistics -statistics link} give details of network performance
\end{itemize}
\end{slide}

\begin{slide}{Types of hard disk}
\begin{itemize}
\item Currently have two choices:
\item \ATA{}133, or \SCSI.
\item \ATA is cheaper, now reasonable performance compared with \SCSI
  for a small number of disks.
\item A cost effective method is to:
  \begin{itemize}
  \item add a number of \IDE controllers to a server,
  \item Add one disk to each \IDE channel
  \item Use software \RAID for reliability \& speed
  \end{itemize}
\item \SCSI controller has processor to reduce load on main \CPU, \ATA
  adds load to main \CPU
\item Coming soon: serial \ATA and serial \SCSI, reducing size of
  cables, increasing data rate (early models are already on the
  market)
\end{itemize}
\end{slide}

\begin{slide}{Getting info about I/O devices}
\begin{itemize}
\item Can list all \PCI devices with \texttt{lspci}
\item Can list all devices with \texttt{lsdev}
\item List all modules that are currently loaded into kernel with
  \texttt{lsmod}
\item The \texttt{/proc} file system contains all you ever wanted to know about
  your hardware and \OS
\item See which hard disks are the busiest with \texttt{iostat}
\end{itemize}
\end{slide}

\begin{slide}{Virtual Filesystem}
  \begin{itemize}
  \item Linux supports many file systems:
    \begin{itemize}
    \item Filesystems for Linux: Ext2, Ext3, ReiserFS
    \item Filesystems for other \UNIX{}s: \acro{SYSV}, \acro{UFS},
      \acro{MINIX}, Veritas VxFS
    \item Microsoft filesystems: \MSDOS, \acro{VFAT}, \NTFS
    \item Filesystems for \CD{}s and \acro{DVD}{}s: \acro{ISO}9660,
      Universal Disk Format (\acro{UDF})
    \item \acro{HPFS} (\OS{}2), \acro{HFS} (Apple), \acro{AFFS} (Amiga),
      \acro{ADFS} (Acorn)
    \item Journalling filesystems from elsewhere: \acro{JFS} from
      \IBM, \acro{XFS} from \acro{SGI}
    \end{itemize}
  \item Same commands and system calls work with all!
  \item How does it all work?
  \end{itemize}
 \end{slide}

\begin{slide}{Virtual Filesystem (\acro{VFS}) --- 2}
  \begin{itemize}
  \item \mbox{}{\red\acro{VFS}} is a kernel software layer
  \item handles all system calls to a file system
  \item Provides a \emphcolour{common interface} to all filesystems
  \item Also handles network filesystems, including \acro{NFS}, \SMB
    (used in Microsoft networking), \acro{NCP} (Novell)
  \item Also handles special or ``virtual'' file systems, such as the
    \texttt{/proc} filesystem, and supports block devices such as
    \texttt{/dev/loop0} which allow mounting a file as if it were a
    disk partition.
  \end{itemize}
\end{slide}


\begin{slide}{Volume Managers}
  \begin{itemize}
  \item A \emphcolour{Volume Manager} is a software layer built into
    an \OS that allows logical disk partitions to be created from
    physical disks.
  \item Allows logical partitions to be \emphcolour{dynamically
      resized} (without rebooting the computer)
  \item Very useful for large systems with rapidly changing data
  \item Examples: \emph{Logical Volume Manager} (\acro{LVM}) from
    Sistina on Linux, a standard part of the kernel
    \begin{itemize}
    \item Can be built on top of software \RAID, a good choice
    \end{itemize}
  \item Microsoft Dynamic Disks {\tiny (see
      \texttt{http://www.winnetmag.com/\allowbreak
        WindowsServer2003/\allowbreak
        Index.cfm?\allowbreak{}ArticleID=27085)}}
  \end{itemize}
\end{slide}

\begin{slide}{Redundant Array of Independent Disks}
  \begin{itemize}
  \item \RAID
  \item Allows disks or disk partitions to be combined to appear to be
    one disk
  \item Aims:
    \begin{itemize}
    \item Performance Increase --- because data can be transferred
      from many disks in parallel
    \item Redundancy --- \RAID above ``level 0'' allows one or more disks to
      fail without losing any data: system continues to be available
    \end{itemize}
  \item Can be implemented in \emphcolour{hardware} or
    \emphcolour{software}
    \begin{itemize}
    \item Software \RAID earned a bad name on Microsoft \OS, but
      reliable and efficient on Linux
    \end{itemize}
  \end{itemize}
\end{slide}


\begin{slide}{Example: \RAID and \LVM on Linux Server}
  \begin{itemize}
  \item Have two \IDE controller cards, two \IDE interfaces on
    motherboard
  \item Five 80\,GB hard disks, one on each of the six \IDE interfaces,
    set as master,
  \item Partition all hard disks the same way: 
  \end{itemize}
\end{slide}

\begin{slide}{Example Use of \RAID and \LVM --- 2}
  \begin{center}
    \includegraphics[width=\slideWidth]{partitioning-for-raid}
  \end{center}
\end{slide}

\begin{slide}{Example Use of \RAID and \LVM --- 3}
  \begin{itemize}
  \item Combine hda1, hdc1 into \RAID 1, specify as the \texttt{/boot}
    partition: \texttt{md0}
    \begin{itemize}
    \item install \texttt{grub} into Master Boot Record of both
      \texttt{hda} and \texttt{hdc} so can still boot if either fails
    \end{itemize}
  \item Combine \texttt{hde1}, \texttt{hdg1}, \texttt{hdi1} into \RAID
    5 for the swap partition: \texttt{md1}
  \item Combine \texttt{hda2}, \texttt{hdc2},  \texttt{hde2},
    \texttt{hdg2}, \texttt{hdi2} into \RAID 5 for the root partition
    \texttt{/}: \texttt{md2}
  \item Combine \texttt{hda3}, \texttt{hdc3}, \texttt{hde3},
    \texttt{hdg3}, \texttt{hdi3} into \RAID 5 for large flexible \LVM
    storage for \texttt{/home} and \texttt{/var}: \texttt{md3}
  \end{itemize}
\end{slide}

\begin{slide}{Example Use of \RAID and \LVM --- 4}
  \begin{itemize}
  \item Run \texttt{pvcreate} on \texttt{/dev/md3} to initialise the
    disks ready to hold \LVM information
  \item Use \texttt{vgcreate} to create a logical volume group
    \texttt{main}
  \item Use \texttt{vgextend} to add the \RAID device \texttt{md3} to
    the volume group
  \item Use \texttt{lvcreate} to create two logical volumes, one for
    \texttt{/var} and the other for \texttt{/home}.
  \item Format the two logical volumes and start using them.
  \item In the future, if \texttt{/var} is full and \texttt{/home} is
    not as full, then can dynamically resize both partitions, removing
    storage from the \texttt{/home} logical volume, and add to the
    \texttt{/var} logical volume, without needing to reboot or shut
    down the server
  \end{itemize}
\end{slide}


\begin{slide}{Summary of \RAID, Volume Managers}
  \begin{itemize}
  \item The use of \RAID provides two benefits:
    \begin{itemize}
    \item \emphcolour{Higher performance} (in example, because can
      read or write to five disks at once through five separate \IDE
      interfaces)
    \item \emphcolour{Redundancy}: if any disk fails, server can
      continue to operate normally, (with reduced disk performance),
      without data loss, until disk is replaced.
    \end{itemize}
  \item The use of a volume manager, such as \LVM on top of \RAID,
    adds the benefit of \emphcolour{flexibility}, allowing system
    administrator to resize logical volumes, add new disks, re-arrange
    storage without disrupting service to the customers
  \end{itemize}
\end{slide}

\begin{slide}{References}
  %\begin{thebibliography}[B&C2002]{bib:B&C2002}
  %\bibitem{bib:B&C2002}
  %\end{thebibliography}
  \begin{itemize}
  \item \label{bib:B&C}Daniel P. Bovet and Marco Cesati,
    \emph{Understanding the Linux Kernel}, Second Edition, O'Reilly,
    Dec 2002, Chapter 13: \emph{Managing I/O Devices}.
  \item \label{bib:Sta}William Stallings, \emph{Operating Systems},
    Fourth Edition, Prentice Hall, 2001, Chapters 11 and 12.
  \item \label{bib:tan}Andrew S. Tanenbaum, \emph{Modern Operating
      Systems}, Prentice Hall, 2001, Chapter 5, \emph{Input/Output}.
  \item \label{bib:nutt}Gary J. Nutt, \emph{Operating Systems: A
      Modern Perspective}, 2nd Edition, Lab Update, Addison-Wesley,
    2002, Chapter 5, \emph{Device Management}.
  \item \emph{LVM HOWTO}, \url{http://tldp.org/HOWTO/LVM-HOWTO/}
  \end{itemize}
\end{slide}
\end{document}