%
% "@(#)sag:$Id$"
%

%--------------------------------------------------------------------
\chapter{Using Disks and Other Storage Media}
%--------------------------------------------------------------------

        \begin{raggedleft}
        \it
	On a clear disk you can seek forever. \\
        \end{raggedleft}
        \vspace{2em}

	% For the future:
	% \meta Rock Ridge on CD-ROM's.  Do directory entries shrink?  How
	% can the unused space in directories be reclaimed?  How are DOS
	% drive letters and Linux device files related?  Recovering from
	% a bad MBR or partition table or super block.  Device files
	% are created by MAKEDEV.  Major and minor numbers; nowadays
	% dynamic?  Manually remounting (ro->rw, rw->ro, when, why)

        \noindent
        When you install or upgrade your system, you need to do a fair
        amount of work on your disks.  You have to make filesystems on
        your disks so that files can be
        stored on them and reserve space for the different parts of
        your system.

        This chapter explains all these initial activities.  Usually,
        once you get your system set up, you won't have to go through
        the work again, except for using floppies.  You'll need to come
        back to this chapter if you add a new disk or want to fine-tune
        your disk usage.

        The basic tasks in administering disks are:
	%%
        \begin{itemize}
        \item
        Format your disk.  This does various things to prepare it for
        use, such as checking for bad sectors.  (Formatting is nowadays
	not necessary for most hard disks.)

        \item
        Partition a hard disk, if you want to use it for several
        activities that aren't supposed to interfere with one another.
        One reason for partitioning is to store different operating
        systems on the same disk.  Another reason is to keep user
        files separate from system files, which simplifies back-ups
        and helps protect the system files from corruption.

        \item
        Make a filesystem (of a suitable type) on each disk or partition.
	The disk means
        nothing to Linux until you make a filesystem; then files can
        be created and accessed on it.

        \item
        Mount different filesystems to form a single tree structure, either
	automatically, or manually as needed.  (Manually mounted filesystems
	usually need to be unmounted manually as well.)

        \end{itemize}

	Chapter~\ref{chap:mem} contains information about virtual memory
	and disk caching, of which you also need to be aware of when using
	disks.

        This chapter explains what you need to know for hard disks and
        floppies.  Unfortunately, because I lack the equipment, I cannot
        tell you much about using other types of media, such as tapes or
        CD-ROM's.

\section{Two kinds of devices}

	UNIX, and therefore Linux, recognizes two different
	kinds of devices: random-access block devices (such as disks),
	and character devices (such as tapes and serial lines),
	some of which may be serial, and some random-access.  Each
	supported device is represented in the filesystem as a
	\defin{device file}.  When you read or write a device file, the
	data comes from or goes to the device it represents.  This way
	no special programs (and no special application programming
	methodology, such as catching interrupts or polling a serial
	port) are necessary to access devices; for example, to send a
	file to the printer, one could just say
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl cat filename $>$ /dev/lp1} \\ \verb|ttyp5 root ~ $|
		\end{tscreen}
		%
	and the contents of the file are printed (the file must, of
	course, be in a form that the printer understands).  However,
	since it is not a good idea to have several people cat their
	files to the printer at the same time, one usually uses a special
	program to send the files to be printed (usually \cmd{lpr(1)}).
	This program makes sure that only one file is being printed
	at a time, and will automatically send files to the printer as
	soon as it finishes with the previous file.  Something similar
	is needed for most devices.  In fact, one seldom needs to worry
	about device files at all.

	Since devices show up as files in the filesystem (in the
	\fn{/dev} directory), it is easy
	to see just what device files exist, using \cmd{ls(1)} or
	another suitable command.  In the output of \cmd{ls -l}, the
	first column contains the type of the file and its
	permissions.  For example, inspecting a serial device
	gives on my system
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl ls -l /dev/cua0} \\
\verb|crw-rw-rw-   1 root     uucp       5,  64 Nov 30  1993 /dev/cua0| \\
\verb|ttyp5 root ~ $| 
		\end{tscreen}
		%
	The first character in the first column, i.e., `{\tt c}' in
	{\tt crw-rw-rw-} above, tells an informed user the type of the file,
	in this case a character device.  For
	ordinary files, the first character is `{\tt -}', for
	directories it is `{\tt d}', and for block devices `{\tt b}';
	see the \cmd{ls(1)} man page for further information.

	Note that usually all device files exist even though the
	device itself might be not be installed.  So just because you
	have a file \fn{/dev/sda}, it doesn't mean that you really do
	have an SCSI hard disk.
	Having all the device files makes the installation programs
	simpler, and makes it easier to add new hardware (there is no
	need to find out the correct parameters for and create the device
	files for the new device).

\section{Hard disks}

	This subsection introduces terminology related to hard disks.
	If you already know the terms and concepts, you can skip this
	subsection.

	See figure~\ref{fig:hd-schematic} for a schematic picture of the
	important parts in a hard disk.  A hard disk consists of one or
	more circular \defin{platters},\footnote{The platters are made of
	a hard substance, e.g., aluminium, which gives the hard disk its
	name.} of which either or both \defin{surfaces} are coated with a
	magnetic substance used for recording the data.  For each
	surface, there is a \defin{read-write head} that examines or
	alters the recorded data.  The platters rotate on a common axis;
	a typical rotation speed is 3600 rotations per minute,
	although high-performance hard disks have higher speeds.  The
	heads move along the radius of the platters; this movement
	combined with the rotation of the platters allows the head to
	access all parts of the surfaces.

	The processor (CPU) and the actual disk communicate through
	a \defin{disk controller}.  This relieves the rest of the computer
	from knowing how to use the drive, since the controllers for
	different types of disks can be made to use the same interface towards
	the rest of the computer.  Therefore, the computer can say just
	``hey disk, gimme what I want'', instead of a long and complex
	series of electric signals to move the head to the proper location
	and waiting for the correct position to come under the head
	and doing all the
	other unpleasant stuff necessary.  (In reality, the interface	
	to the controller is still complex, but much less so than it would
	otherwise be.)  The controller can also do some other stuff,
	such as caching, or automatic bad sector replacement.

	The above is usually what one needs to understand about the
	hardware.  There is also a bunch of other stuff, such as the
	motor that rotates the platters and moves the heads, and the
	electronics that control the operation of the mechanical
	parts, but that is mostly not relevant for understanding the
	working principle of a hard disk.

	The surfaces are usually divided into concentric rings, called
	\defin{tracks}, and these in turn are divided into \defin{sectors}.
	This division is used to specify locations
	on the hard disk and to allocate disk space to files.  To find
	a given place on the hard disk, one might say ``surface 3,
	track 5, sector 7''.  Usually the number of sectors is the
	same for all tracks, but some hard disks put more sectors in
	outer tracks (all sectors are of the same physical size, so
	more of them fit in the longer outer tracks).  Typically, a
	sector will hold 512~bytes of data.  The disk itself can't
	handle smaller amounts of data than one sector.

		\begin{figure}[thb]
		\begin{center}
		\leavevmode \epsffile{hd-schematic.ps}
		\end{center}
		\caption{A schematic picture of a hard disk.}
		\label{fig:hd-schematic}
		\end{figure}

	Each surface is divided into tracks (and sectors) in the same
	way.  This means that when the head for one surface is on a
	track, the heads for the other surfaces are also on the
	corresponding tracks.  All the corresponding tracks taken
	together are called a \defin{cylinder}.  It takes time to move
	the heads from one track (cylinder) to another, so by placing
	the data that is often accessed together (say, a file) so that
	it is within one cylinder, it is not necessary to move the
	heads to read all of it.  This improves performance.  It is
	not always possible to place files like this; files that are
	stored in several places on the disk are called \defin{fragmented}.

	The number of surfaces (or heads, which is the same thing),
	cylinders, and sectors vary a lot; the specification of the
	number of each is called the \defin{geometry} of a hard disk.  The
	geometry is usually stored in a special, battery-powered memory
	location called the \defin{CMOS RAM}, from where the operating
	system can fetch it during bootup or driver initialization.

	Unfortunately, the BIOS\footnote{The BIOS is some built-in software
	stored on ROM chips.  It takes care, among other things, of the
	initial stages of booting.} has a design limitation, which makes it
	impossible to specify a track number that is larger than 1024 in
	the CMOS RAM,
	which is too little for a large hard disk.  To overcome this,
	the hard disk controller lies about the geometry, and 
	\defin{translates the addresses} given by the computer into something
	that fits reality.  For example, a hard disk might have 8 heads,
	2048 tracks, and 35 sectors per track\footnote{The numbers are
	completely imaginary.}.  Its controller could lie to the
	computer and claim that it has 16 heads, 1024 tracks, and 35
	sectors per track, thus not exceeding the limit on tracks, and
	translates the address that the computer gives it by halving the
	head number, and doubling the track number.  The math can be
	more complicated in reality, because the numbers are not as nice
	as here (but again, the details are not relevant for
	understanding the principle).  This translation distorts the
	operating system's view of how the disk is organized, thus making it
	impractical to use the all-data-on-one-cylinder trick to boost
	performance.

	The translation is only a problem for IDE disks.  SCSI disks use
	a sequential sector number (i.e., the controller translates a
	sequential sector number to head/cylinder/sector), and a
	completely different method for the CPU to talk with the
	controller, so they are insulated from the problem.  Note,
	however, that the computer might not know the real geometry of
	an SCSI disk either.

	Since Linux often will not know the real geometry of a disk,
	its filesystems don't even try to keep files within a single cylinder.
	Instead, it tries to assign sequentially numbered sectors to
	files, which almost always gives similar performance.  The issue
	is further complicated by on-controller caches, and automatic
	prefetches done by the controller.

	Each hard disk is represented by a separate device file.  There
	can (usually) be only two IDE hard disks.  These are known as
	\fn{/dev/hda} and \fn{/dev/hdb}, respectively.  SCSI hard disks
	are known as \fn{/dev/sda}, \fn{/dev/sdb}, and so on.  Similar
	naming conventions exist for other hard disk types
	%%%% ; see 
	%%%% appendix~\ref{app:device-list} for more information.
	Note that
	the device files for the hard disks give access to the entire
	disk, with no regard to partitions (which will be discussed
	below), and it's easy to mess up the partitions or the data
	in them if you aren't careful.  The disks' device files are
	usually used only to get access to the master boot record (which
	will also be discussed below).

\section{Floppies}

	A floppy disk consists of a flexible membrane covered on one
	or both sides with similar magnetic substance as a hard disk.
	The floppy disk itself doesn't have a read-write head, that is
	included in the drive.  A floppy corresponds to one platter in
	a hard disk, but is removable and one drive can be used to
	access different floppies, whereas the hard disk is one
	indivisible unit.

	Like a hard disk, a floppy is divided into tracks and sectors
	(and the two corresponding tracks on either side of a floppy
	form a cylinder), but there are many fewer of them than on a
	hard disk.

	A floppy drive can usually use several different types of disks;
	for example, a $3{1\over 2}$ inch drive can use both 720~kB and
	1.44~MB disks.  Since the drive has to operate a bit differently
	and the operating system must know how big the disk is, there
	are many device files for floppy drives, one per combination of
	drive and disk type.
	Therefore, \fn{/dev/fd0H1440} is the first floppy drive (\fn{fd0}),
	which must be a $3{1\over 2}$ inch drive,
	using a $3{1\over 2}$ inch, high density disk (\fn{H}) of
	size 1440~kB (\fn{1440}), i.e., a normal $3{1\over 2}$ inch HD floppy.
	For more information on the naming conventions for the floppy
	devices.
	%%%% , again see appendix~\ref{app:device-list}, the device list.

	The names for floppy drives are complex, however, and Linux
	therefore has a special floppy device type that automatically
	detects the type of the disk in the drive.  It works by trying
	to read the first sector of a newly inserted floppy using different
	floppy types until it finds the correct one.  This naturally requires
	that the floppy is formatted first.  The automatic devices are
	called \fn{/dev/fd0}, \fn{/dev/fd1}, and so on.

	The parameters the automatic device uses to access a disk can
	also be set using the program \cmd{setfdprm(8)}.  This can be
	useful if you need to use disks that do not follow any usual
	floppy sizes, e.g., if they have an unusual number of sectors,
	or if the autodetecting for some reason fails and the proper
	device file is missing.

	Linux can handle many nonstandard floppy disk formats in
	addition to all the standard ones.  Some of these require
	using special formatting programs.
	We'll skip these disk types for now.

	% there exists an extension to the std Linux fd driver for
	% non-std formats (is this different from setfdprm?): check mail
	% from geyer (1993-07-22) and verify

	% The operating system must know when a disk has been changed in
	% a floppy drive, for example, in order to avoid using cached
	% data from the previous disk.  Unfortunately, the signal line
	% that is used for this is sometimes broken, and worse, this won't
	% always be noticeable when using the drive from within MS-DOS.
	% If you are experiencing weird problems using floppies, this might
	% be the reason.  The only way to correct it is to repair the
	% floppy drive.
	% move the above paragraph to a trouble shooting chapter

\section{Formatting}

	\defin{Formatting} is the process of writing marks on the
	magnetic media that are used to mark tracks and sectors.
	Before a disk is formatted, its magnetic surface is a complete
	mess of magnetic signals.  When it is formatted, some order is
	brought into the chaos by essentially drawing lines where the
	tracks go, and where they are divided into sectors.  The
	actual details are not quite exactly like this, but that is
	irrelevant.  What is important, is that a disk cannot be used
	unless it has been formatted.

	The terminology is a bit confusing here: in MS-DOS, the word
	formatting is used to cover also the process of creating a
	filesystem (which will be discussed below).  There, the two
	processes are often combined, especially for floppies.  When
	the distinction needs to be made, the real formatting is
	called \defin{low-level formatting}, while making the filesystem
	is called \defin{high-level formatting}.  In UNIX circles,
	the two are called formatting and making a filesystem, so
	that's what is used in this book as well.

	For IDE and some SCSI disks the formatting is actually
	done at the factory and doesn't need to be repeated; hence
	most people rarely need to worry about it.  In fact,
	formatting a hard disk can cause it to work less well, for
	example because a disk might need to be formatted in some very
	special way to allow automatic bad sector replacement to work.

	Disks that need or can be formatted, often require a special
	program anyway, because the interface to the formatting logic
	inside the drive is different from drive to drive.  The
	formatting program is often either on the controller BIOS, or
	is supplied as an MS-DOS program; neither of these can easily be used
	from within Linux.

	During formatting one might encounter bad spots on the disk,
	called \defin{bad blocks} or \defin{bad sectors}.  These are sometimes
	handled by the drive itself,
	but even then, if more of them develop, something needs to be
	done to avoid using those parts of the disk.  The logic to do
	this is built into the filesystem; how to add the information
	into the filesystem is described below.  Alternatively, one
	might create a small partition that covers just the bad part
	of the disk; this approach might be a good idea if the bad
	spot is very large, since filesystems can sometimes have
	trouble with very large bad areas.

	Floppies are formatted with \cmd{fdformat(8)}.  The floppy device
	file to use is given as the parameter.  For example, the
	following command would format a high density,
	$3{1\over 2}$ inch floppy in the first floppy drive:
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl fdformat /dev/fd0H1440} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formatting ... done| \\
\verb|Verifying ... done| \\
\verb|ttyp5 root ~ $ |
		\end{tscreen}
		%
	Note that if you want to use an autodetecting device (e.g.,
	\fn{/dev/fd0}), you {\em must} set the parameters of the device
	with \cmd{setfdprm(8)} first.  To achieve the same effect as
	above, one would have to do the following:
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl setfdprm /dev/fd0 1440/1440} \\
\verb|ttyp5 root ~ $| {\sl fdformat /dev/fd0} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formatting ... done| \\
\verb|Verifying ... done| \\
\verb|ttyp5 root ~ $ |
		\end{tscreen}
		%
	It is usually more convenient to choose the correct device file
	that matches the type of the floppy.  Note that it is unwise to
	format floppies to contain more information than what they are
	designed for.

	\cmd{fdformat} will also validate the floppy, i.e., check it
	for bad blocks.  It will try a bad block several times (you
	can usually hear this, the drive noise changes dramatically).
	If the floppy is only marginally bad (due to dirt on the
	read/write head, some errors are false signals), \cmd{fdformat} won't
	complain, but a real error will abort the validation process.
	The kernel will print log messages for each I/O error it
	finds; these will go to the console or, if \cmd{syslog}
	is being used, to the file \fn{/usr/adm/messages}.  \cmd{fdformat}
	itself won't tell where the error is (one usually doesn't care,
	floppies are cheap enough that a bad one is automatically thrown
	away).
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl fdformat /dev/fd0H1440} \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formatting ... done| \\
\verb|Verifying ... read: Unknown error| \\
\verb|ttyp5 root ~ $ |
		\end{tscreen}
		%

	The \cmd{badblocks(8)} command can be used to search any disk or
	partition for bad blocks (including a floppy).  It does not
	format the disk, so it can be used to check even existing
	filesystems.  The example below checks a $3{1\over 2}$ inch
	floppy with two bad blocks.
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $| {\sl badblocks /dev/fd0H1440 1440} \\
\verb|718| \\
\verb|719| \\
\verb|ttyp5 root ~ $ |
		\end{tscreen}
		%
	\cmd{badblocks} outputs the block numbers of the bad blocks it finds.
	Most filesystems can avoid such bad blocks. They maintain a list
	of known bad blocks, which is initialized when the filesystem is
	made, and can be modified later.  The initial search for bad
	blocks can be done by the \cmd{mkfs} command (which initializes
	the filesystem), but later checks should be done with
	\cmd{badblocks} and the new blocks should be added with
	\cmd{fsck}.  We'll describe \cmd{mkfs} and \cmd{fsck} later.


\section{Partitions}

	A hard disk can be divided into several \defin{partitions}.
	Each partition functions as if it were a separate hard disk.
	The idea is that if you have one hard disk, and want to have,
	say, two operating systems on it, you can divide the disk into
	two partitions.  Each operating system uses its partition as
	it wishes and doesn't touch the other one's.  This way the two
	operating systems can co-exist peacefully on the same hard
	disk. Without partitions one would have to buy a hard disk for
	each operating system.

	Floppies are not partitioned.  There is no technical reason
	against this, but since they're so small, partitions would be
	useful only very rarely.

\subsection{The MBR, boot sectors and partition table}

	The information about how a hard disk has been partitioned is
	stored in its first sector (that is, the first sector of the
	first track on the first disk surface).  The first sector is the
	\defin{master boot record} (MBR) of the disk; this is the sector
	that the BIOS reads in and starts when the machine is first
	booted.  The master boot record contains a small program that
	reads the partition table, checks which partition is active
	(that is, marked bootable), and reads the first sector of that
	partition, the partition's \defin{boot sector} (the MBR is also a
	boot sector, but it has a special status and therefore a special
	name).  This boot sector contains another small program that
	reads the first part of the operating system stored on that
	partition (assuming it is bootable), and then starts it.

	The partitioning scheme is not built into the hardware, or
	even into the BIOS.  It is only a convention that many
	operating systems follow.  Not all operating systems do follow
	it, but they are the exceptions.  Some operating
	systems support partitions, but they occupy one partition on
	the hard disk, and use their internal partitioning method
	within that partition.  The latter type exists peacefully
	with other operating systems (including Linux), and does not
	require any special measures, but an operating system
	that doesn't support partitions cannot co-exist on the same
	disk with any other operating system.

	As a safety precaution, it is a good idea to write down the
	partition table on a piece of paper, so that if it ever corrupts
	you don't have to lose all your files.  (A bad partition table
	can be fixed with \cmd{fdisk}).

\subsection{Extended and logical partitions}

	The original partitioning scheme for PC hard disks allowed
	only four partitions.  This quickly turned out to be too little
	in real life, partly because some people want more than four
	operating systems (Linux, MS-DOS, OS/2, Minix, FreeBSD, NetBSD, or
	Windows/NT, to name a few), but primarily because sometimes it
	is a good idea to have several partitions for one
	operating system.  For example, swap space is usually best put
	in its own partition for Linux instead of in the main
	Linux partition for reasons of speed (see below).

	To overcome this design problem, \defin{extended partitions} were
	invented.  This trick allows partitioning a \defin{primary
	partition} into sub-partitions.  The
	primary partition thus subdivided is the extended partition; the
	subpartitions are \defin{logical partitions}.  They behave 
	like primary\footnote{Illogical?} partitions, but are created
	differently.

	The partition structure of a hard disk might look like that in
	figure~\ref{fig:hard-disk-layout}.  The disk is divided into
	three primary partitions, the second of which is divided into
	two logical partitions.  Part of the disk is not partitioned at
	all.  The disk as a whole and each primary partition has a boot
	sector.

		\begin{figure}[thb]
		\begin{center}
		\leavevmode \epsffile{hd-layout.ps}
		%\include{hd-layout}
		\end{center}
		\caption{A sample hard disk partitioning.}
		\label{fig:hard-disk-layout}
		\end{figure}

\subsection{Partition types}

	The partition tables (the one in the MBR, and the ones for
	extended partitions) contain one byte per partition that
	identifies the type of that partition.  This attempts to
	identify the operating system that uses the partition, or what
	it uses it for.  The purpose is to make it possible to avoid
	having two operating systems accidentally using the same
	partition.  However, in reality, operating systems do not
	really care about the partition type byte; e.g., Linux
	doesn't care at all what it is.  Worse, some of them use it
	incorrectly; e.g., at least some versions of DR-DOS ignore the
	most significant bit of the byte, while others don't.

	There is no standardization agency to specify what each byte
	value means, but some commonly accepted ones are included in
	the table in table~\ref{tab:partition-ids}.  The same list is
	available in the Linux \cmd{fdisk(8)} program.

\begin{table}[ht]
\caption{Partition types (from the Linux \cmd{fdisk(8)} program).}
\begin{center}
\begin{tabular}{rl rl rl rl}
\hline
0 & Empty               & 40 & Venix 80286  & 94 & Amoeba BBT     \\
1 & DOS 12-bit FAT      & 51 & Novell?      & a5 & BSD/386        \\
2 & XENIX root          & 52 & Microport    & b7 & BSDI fs        \\
3 & XENIX usr           & 63 & GNU HURD     & b8 & BSDI swap      \\
4 & DOS 16-bit $<$32M   & 64 & Novell       & c7 & Syrinx         \\
5 & Extended            & 75 & PC/IX        & db & CP/M           \\
6 & DOS 16-bit $\ge$32M & 80 & Old MINIX    & e1 & DOS access     \\
7 & OS/2 HPFS           & 81 & Linux/MINIX  & e3 & DOS R/O        \\
8 & AIX                 & 82 & Linux swap   & f2 & DOS secondary  \\
9 & AIX bootable        & 83 & Linux native & ff & BBT            \\
a & OS/2 Boot Manag     & 93 & Amoeba       &    &                \\
\hline
\end{tabular}
\end{center}
\label{tab:partition-ids}
\end{table}

\subsection{Partitioning a hard disk}

	There are many programs for creating and removing partitions.
	Most operating systems have their own, and it can be a good
	idea to use each operating system's own, just in case it does
	something unusual that the others can't.  Many of the programs
	are called \cmd{fdisk}, including the Linux one, or
	variations thereof.  Details on using the Linux \cmd{fdisk}
	are given on its man page.  The \cmd{cfdisk} command is similar
	to \cmd{fdisk}, but has a nicer (full screen) user interface.

	% future:
	% \meta common problems: partition does not start on a cylinder
	% boundary; check faq, saved articles, newsgroups for more.

	When using IDE disks, the boot partition (the partition
	with the bootable kernel image files) must be completely
	within the first 1024 cylinders.  This is because the disk is
	used via the BIOS during boot (before the system goes into
	protected mode), and BIOS can't handle more than 1024 cylinders.
	It is sometimes possible to use a boot partition that is only
	partly within the first 1024 cylinders.  This works as long
	as all the files that are read with the BIOS are within the
	first 1024 cylinders.  Since this is difficult to arrange,
	it is \emph{a very bad idea} to do it; you never know when
	a kernel update or disk defragmentation will result in an 
	unbootable system.  Therefore, make sure your boot partition
	is completely within the first 1024 cylinders.

	Some newer versions of the BIOS and IDE disks can, in fact,
	handle disks with more than 1024 cylinders.  If you have such
	a system, you can forget about the problem; if you aren't
	quite sure of it, put it within the first 1024 cylinders.

	Each partition should have an even number of sectors, since
	the Linux filesystems use a 1~kB block size, i.e., two
	sectors.  An odd number of sectors will result in the last
	sector being unused.  This won't result in any problems, but
	it is ugly, and some versions of \cmd{fdisk} will warn about
	it.

	Changing a partition's size usually requires first backing up
	everything you want to save from that partition (preferably the
	whole disk, just in case), deleting the partition, creating
	new partition, then restoring everything to the new partition.
	There is a program for MS-DOS, called \cmd{fips}, which does
	this without requiring the backup and restore, but for other
	filesystems it is still necessary.

\subsection{Device files and partitions}

	Each partition and extended partition has its own device file.
	The naming convention for these files is that a partition's
	number is appended after the name of the whole disk, with the
	convention that 1--4 are primary partitions (regardless of
	how many primary partitions there are) and 5--8 
	are logical partitions (regardless of within which primary
	partition they reside).  For example, \fn{/dev/hda1} is the
	first primary partition on the first IDE hard disk, and
	\fn{/dev/sdb7} is the third extended partition on the second
	SCSI hard disk.
	%%%% The device list in appendix~\ref{app:device-list}
	%%%% gives more information.

\section{Filesystems}

\subsection{What are filesystems?}

	A \defin{filesystem} is the methods and data structures that an
	operating uses to keep track of files on a disk or partition
	that is, the way the
	files are organized on the disk.  The word is also used to
	refer to a partition or disk that is used to store the files
	or the type of the filesystem.  Thus, one might say ``I have
	two filesystems'' meaning one has two partitions on which one
	stores files, or that one is using the ``extended
	filesystem'', meaning the type of the filesystem.

        The difference between a disk or partition and the filesystem
        it contains is important.  A few programs---including,
        reasonably enough, programs that create filesystems---operate
        directly on the raw sectors of a disk or partition; if there
        is an existing file system there it will be destroyed or
        seriously corrupted.  Most programs operate on a filesystem,
        and therefore won't work on a partition that doesn't contain
        one (or that contains one of the wrong type).

	Before a partition or disk can be used as a filesystem, it
	needs to be initialized, and the bookkeeping data structures need
	to be written to the disk.  This process is called
	\defin{making a filesystem}.

	Most UNIX filesystem types have a similar general structure,
	although the exact details vary quite a bit.  The central
	concepts are \defin{superblock}, \defin{inode}, \defin{data block},
	\defin{directory block}, and \defin{indirection block}.  The
	superblock contains information about the filesystem as a
	whole, such as its size (the exact information here depends
	on the filesystem).  An inode contains all information about
	a file, excepts its name.  The name is stored in the directory,
	together with the number of the inode.  A directory entry consists
	of a filename and the number of the inode which represents the
	file.  The inode contains the numbers of several data blocks,
	which are used to store the data in the file.  There is space
	only for a few data block numbers in the inode, however, and if more
	are needed, more space for pointers to the data blocks is allocated
	dynamically.  These dynamically allocated blocks are indirect
	blocks; the name indicates that in order to find the data block,
	one has to find its number in the indirect block first.

	UNIX filesystems usually allow one to create a \defin{hole}
	in a file (this is done with \cmd{lseek(2)}; check the manual
	page), which means that the filesystem just pretends that at a
	particular place in the file there is just zero bytes, but no
	actual disk sectors are reserved for that place in the file
	(this means that the file will use a bit less disk
	space). This happens especially often for small binaries, Linux
	shared libraries, some databases, and a few other special cases.
	(Holes are
	implemented by storing a special value as the address of the
	data block in the indirect block or inode.  This special address
	means that no data block is allocated for that part of the file,
	ergo, there is a hole in the file.)

	Holes are moderately useful.  On the author's system, a simple
	measurement showed a potential for about 4~MB of savings through
	holes of about 200~MB total used disk space.  That system, however,
	contains relatively few programs and no database files.  The
	measurement tool is described in appendix~\ref{chap:measure-holes}.

\subsection{Filesystems galore}

	Linux supports several types of filesystems.  As of this
	writing the most important ones are:
		%
	\begin{quote}
	\begin{dispitems}
	\item[minix]
		The oldest, presumed to be the most reliable, but quite
		limited in features (some time stamps are missing, at
		most 30 character filenames) and restricted in
		capabilities (at most 64~MB per filesystem).
	\item[xia]
		A modified version of the minix filesystem that lifts
		the limits on the filenames and filesystem sizes,
		but does not otherwise introduce new features.  It is
		not very popular, but is reported to work very well.
	\item[ext2]
		The most featureful of the native Linux filesystems,
		currently also the most popular one.  It is designed to
		be easily upwards compatible, so that new versions
		of the filesystem code do not require re-making the
		existing filesystems.
	\item[ext]
		An older version of \texttt{ext2} that wasn't upwards
		compatible.  It is hardly ever used in new installations
		any more, and most people have converted to \texttt{ext2}.
	\end{dispitems}
	\end{quote}
		%
	In addition, support for several foreign filesystem exists,
	to make it easier to exchange files with other operating
	systems.  These foreign filesystems work just like native
	ones, except that they may be lacking in some usual UNIX
	features, or have curious limitations, or other oddities.
		%
	\begin{quote}
	\begin{dispitems}
	\item[msdos]
		Compatibility with MS-DOS (and OS/2 and Windows NT)
		FAT filesystems.
	\item[umsdos]
		Extends the \texttt{msdos} filesystem driver under
		Linux so that Linux can see long filenames, owners,
		permissions, links, and device files.  This allows a normal
		\texttt{msdos} filesystem to be used as if it were a
		Linux one, thus removing the need for a separate
		partition for Linux.
	\item[iso9660]
		The standard CD-ROM filesystem; the popular Rock Ridge
		extension to the CD-ROM standard that allow longer file
		names is supported automatically.
	\item[nfs]
		A networked filesystem that allows sharing a filesystem
		between many computers to allow easy access to the
		files from all of them.
	\item[hpfs]
		The OS/2 filesystem.
	\item[sysv]
		SystemV/386, Coherent, and Xenix filesystems.
	\end{dispitems}
	\end{quote}
	\meta ifs, userfs
		%
	The choice of filesystem to use depends on the situation.  If
	compatibility or other reasons make one of the non-native
	filesystems necessary, then that one must be used.  If one can
	choose freely, then it is probably wisest to use ext2, since
	it has all the features but does not suffer from lack of
	performance.

	There is also the \texttt{proc} filesystem, usually accessible as
	the \fn{/proc} directory, which is not really a
	filesystem at all, even though it looks like one.  The
	\texttt{proc} filesystem makes it easy to access certain kernel
	data structures, such as the process list (hence the name).
	It makes these
	data structures look like a filesystem, and that filesystem
	can be manipulated with all the usual file tools.  For example,
	to get a listing of all processes one might use the
	command
		%
		\begin{tscreen}
\verb|ttyp5 root ~ $ | {\sl ls -l /proc} \\
\verb|total 0| \\
\verb|dr-xr-xr-x   4 root     root            0 Jan 31 20:37 1| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 63| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 94| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 95| \\
\verb|dr-xr-xr-x   4 root     users           0 Jan 31 20:37 98| \\
\verb|dr-xr-xr-x   4 liw      users           0 Jan 31 20:37 99| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 devices| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 dma| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 filesystems| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 interrupts| \\
\verb|-r--------   1 root     root      8654848 Jan 31 20:37 kcore| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 11:50 kmsg| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 ksyms| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 11:51 loadavg| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 meminfo| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 modules| \\
\verb|dr-xr-xr-x   2 root     root            0 Jan 31 20:37 net| \\
\verb|dr-xr-xr-x   4 root     root            0 Jan 31 20:37 self| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 stat| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 uptime| \\
\verb|-r--r--r--   1 root     root            0 Jan 31 20:37 version| \\
\verb|ttyp5 root ~ $ |
		\end{tscreen}
		%
	(There will be a few extra files that don't correspond to
	processes, though.  The above example has been shortened.)

	Note that even though it is called a filesystem, no part of 
	the \texttt{proc} filesystem touches any disk.  It exists only in the
	kernel's imagination.  Whenever anyone tries to look at any
	part of the \texttt{proc} filesystem, the kernel makes it look as if
	the part existed somewhere, even though it doesn't.  So, even
	though there is a multi-megabyte \fn{/proc/kmem} file,
	it doesn't take any disk space.

	% for the future:
	% The various filesystems are described further on their
	% respective man pages: \man{ext2(4)}, \man{proc(4)}, and so on.
	% \meta the man pages are yet unwritten

\subsection{Which filesystem should be used?}

	There is usually little point in using many different filesystems.
	Currently, ext2fs is the most popular one, and it is probably
	the wisest choice.  Depending on the overhead for bookkeeping
	structures, speed, (perceived) reliability, compatibility,
	and various other reasons, it may be advisable to use another file
	system.  This needs to be decided on a case-by-case basis.

\subsection{Creating a filesystem}\label{sec:mkfs}

	Filesystems are created, i.e., initialized, with the \cmd{mkfs(8)}
	command.  There is actually a separate program for each filesystem
	type.  \cmd{mkfs} is just a front end that runs the appropriate
	program depending on the desired filesystem type.  The type is
	selected with the \texttt{-t fstype} option.

	The programs called by \cmd{mkfs} have slightly different
	command line interfaces.  
	The common and most important options are summarized below; see
	the manual pages for more.
	%
	\begin{quote}
	\begin{description}
	\item[{\tt -t} {\it fstype}] Select the type of the filesystem.
	\item[{\tt -c}] Search bad bad blocks and initialize the bad
		block list accordingly.
	\item[{\tt -l} {\it filename}] Read the initial bad block list
		from the file {\it filename}.
	\end{description}
	\end{quote}
	%
	To create an ext2 filesystem on a floppy, one would give the
	following commands:
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $| {\sl fdformat -n /dev/fd0H1440 } \\
\verb|Double-sided, 80 tracks, 18 sec/track. Total capacity 1440 kB.| \\
\verb|Formatting ... done| \\
\verb|ttyp6 root ~ $| {\sl badblocks /dev/fd0H1440 1440 $>$ bad-blocks} \\
\verb|ttyp6 root ~ $| {\sl mkfs -t ext2 -l bad-blocks /dev/fd0H1440} \\
\verb|mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|360 inodes, 1440 blocks| \\
\verb|72 blocks (5.00%) reserved for the super user| \\
\verb|First data block=1| \\
\verb|Block size=1024 (log=0)| \\
\verb|Fragment size=1024 (log=0)| \\
\verb|1 block group| \\
\verb|8192 blocks per group, 8192 fragments per group| \\
\verb|360 inodes per group| \\
\verb||\\
\verb|Writing inode tables: done     | \\
\verb|Writing superblocks and filesystem accounting information: done| \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%
	First, the floppy was formatted (the \texttt{-n} option prevents
	validation, i.e., bad block checking).  Then bad blocks were
	searched with \cmd{badblocks}, with the output redirected to
	a file, \fn{bad-blocks}.  Finally, the filesystem was created,
	with the bad block list initialized by whatever \cmd{badblocks}
	found.

	The {\tt -c} option could have been used with \cmd{mkfs}
	instead of \cmd{badblocks} and a separate file.  The example
	below does that.
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $| {\sl mkfs -t ext2 -c /dev/fd0H1440 } \\
\verb|mke2fs 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|360 inodes, 1440 blocks| \\
\verb|72 blocks (5.00%) reserved for the super user| \\
\verb|First data block=1| \\
\verb|Block size=1024 (log=0)| \\
\verb|Fragment size=1024 (log=0)| \\
\verb|1 block group| \\
\verb|8192 blocks per group, 8192 fragments per group| \\
\verb|360 inodes per group| \\
 \\
\verb|Checking for bad blocks (read-only test): done         | \\
\verb|Writing inode tables: done     | \\
\verb|Writing superblocks and filesystem accounting information: done| \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%
	The {\tt -c} is more convenient than a separate use of
	\cmd{badblocks}, but \cmd{badblocks} is necessary for checking
	after the filesystem has been created.

	The process to prepare to filesystems on hard disks or partitions
	is the same as for floppies, except that the formatting isn't needed.

\subsection{Mounting and unmounting}\label{subsec:mount}

	Before one can use a filesystem, it has to be \defin{mounted}.
	The operating system then does various bookkeeping things to
	make sure that everything works.  Since all files in UNIX are
	in a single directory tree, the mount operation will make it
	look like the contents of the new filesystem are the contents of
	an existing subdirectory in some already mounted filesystem.

	For example, figure~\ref{fig:hd-mount-root} shows three
	separate filesystems, each with their own root directory.
	When the last two filesystems are mounted below \fn{/home}
	and \fn{/usr}, respectively, on the first filesystem, we
	can get a single directory tree, as in
	figure~\ref{fig:hd-mount-all}.

		\begin{figure}[thb]
		\begin{center}
		\input{hd-mount-separate.tex}
		\end{center}
		\caption{Three separate filesystems.}
		\label{fig:hd-mount-root}
		\end{figure}

		\begin{figure}[thb]
		\begin{center}
		\input{hd-mount-mounted.tex}
		\end{center}
		\caption{\fn{/home} and \fn{/usr} have been mounted.}
		\label{fig:hd-mount-all}
		\end{figure}

	The mounts could be done as in the following example:
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $ | {\sl mount /dev/hda2 /home} \\
\verb|ttyp6 root ~ $ | {\sl mount /dev/hda3 /usr} \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%
	The \cmd{mount(8)} command takes two arguments.  The first one is
	the device file corresponding to the disk or partition containing
	the filesystem.  The second one is the directory below which it
	will be mounted.  After these commands the contents of
	the two filesystems look just like the contents of the \fn{/home}
	and \fn{/usr} directories, respectively.  One would then say that
	``\fn{/dev/hda2} \defin{is mounted on} \fn{/home}'', and similarly
	for \fn{/usr}.  To look at either filesystem, one would look
	at the contents of the directory on which it has been mounted,
	just as it were any other directory.  Note the
	difference between the device file, \fn{/dev/hda2}, and the
	mounted-on directory, \fn{/home}.  The device file gives access
	to the raw contents of the disk, the mounted-on directory
	gives access to the files on the disk.  The mounted-on directory
	is called the \defin{mount point}.

	%\meta mount -t fstype; autodetection

	The mounted-on directory need not be empty, although it must
	exist.  Any files in it,
	however, will be inaccessible by name while the filesystem
	is mounted.  (Any files that have already been opened will
	still be accessible.  Files that have hard links from
	other directories can be accessed using those names.)
	There is no harm done with this, and it can even be useful.
	For instance, some people like to have \fn{/tmp} and \fn{/usr/tmp}
	synonymous, and make \fn{/tmp} be a symbolic link to \fn{/usr/tmp}.
	When the system is booted, before the \fn{/usr} filesystem is
	mounted, a \fn{/usr/tmp} directory residing on the root filesystem
	is used instead.  When \fn{/usr} is mounted, it will make the
	\fn{/usr/tmp} directory on the root filesystem inaccessible.
	If \fn{/usr/tmp} didn't exist on the root filesystem, it would
	be impossible to use temporary files before mounting \fn{/usr}.

	If you don't intend to write anything to the filesystem, use
	the {\tt -r} switch for \cmd{mount} to do a \defin{readonly
	mount}.  This will make the kernel stop any attempts at
	writing to the filesystem, and will also stop the kernel from
	updating file access times in the inodes.  Read-only mounts
	are necessary for unwritable media, e.g., CD-ROM's.

	The alert reader has already noticed a slight
	logistical problem.  How is the first filesystem (called the \defin{root
	filesystem}, because it contains the root directory) mounted,
	since it obviously can't be mounted on another filesystem?
	Well, the answer is that it is done by magic.\footnote{For more
	information, see the kernel source or the Kernel Hackers'
	Guide.}  The root filesystem is magically mounted at boot time,
	and one can rely on it to always be mounted---if the root
	filesystem can't be mounted, the system does not boot.  The
	name of the filesystem that is magically mounted as root is
	either compiled into the kernel, or set using LILO or \cmd{rdev}.

	The root filesystem is usually first mounted readonly.  The
	startup scripts will then run \cmd{fsck(8)} to verify its
	validity, and if there are no problems, they will \defin{re-mount}
	it so that writes will also be allowed.  \cmd{fsck} must not
	be run on a mounted filesystem, since any changes to the
	filesystem while \cmd{fsck} is running {\em will} cause
	trouble.  Since the root filesystem
	is mounted readonly while it is being checked, \cmd{fsck}
	can fix any problems without worry, since the remount operation
	will flush any metadata that the filesystem keeps in memory.

	On many systems there are other filesystems that should also
	be mounted automatically at boot time.  These are specified
	in the \fn{/etc/fstab} file; see the \man{fstab(5)} man page for
	details on the
	format.  The details of exactly when the extra filesystems
	are mounted depend on many factors, and can be configured
	by each administrator if need be.  When the chapter on booting
	is finished, you may read all about it there.

	When a filesystem no longer needs to be mounted, it can be
	unmounted with \cmd{umount(8)}\footnote{It should of course be
	\cmd{unmount(8)}, but the {\tt n} mysteriously disappeared in
	the 70's, and hasn't been seen since.  Please return it to Bell
	Labs, NJ, if you find it.}.  \cmd{umount} takes one argument:
	either the device file or the mount point.  
	For example, to unmount the directories of
	the previous example, one could use the commands
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $ | {\sl umount /dev/hda2 } \\
\verb|ttyp6 root ~ $ | {\sl umount /usr} \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%
	See the man page for further instructions on how to use the
	command.  It is imperative that you always unmount a mounted
	floppy.  {\em Don't just pop the floppy out of the drive!}
	Because of disk caching, the data is not necessarily written
	to the floppy until you unmount it, so removing the floppy
	from the drive too early might cause the contents to become
	garbled.  If you just read from the floppy, this is not very
	likely, but if you write, even accidentally, the result may be
	catastrophic.

	Mounting and unmounting requires super user priviledges, i.e.,
	only \fn{root} can do it.  The reason for this is that if any
	user can mount a floppy on any directory, then it is rather easy
	to create a floppy with, say, a Trojan horse disguised as
	\cmd{/bin/sh}, or any other often used program.  However, it is
	often necessary to allow users to use floppies, and there are
	several ways to do this:
		%
	\begin{itemize}
	\item Give the users the \fn{root} password.  This is obviously
		bad security, but is the easiest solution.  It works
		well if there is no need for security anyway, which is
		the case on many non-networked, personal systems.
	\item Use a program such as \cmd{sudo(8)} to allow users to
		use mount.  This is still bad security, but doesn't
		directly give super user priviledges to
		everyone.\footnote{It requires several seconds of hard
		thinking on the users' behalf.}
	\item Make the users use \cmd{mtools}, a package for manipulating
		MS-DOS filesystems, without mounting them.  This works
		well if MS-DOS floppies are the only thing that is needed,
		but is rather awkward otherwise.
	\item List the floppy devices and their allowable mount points
		together with the suitable options in \fn{/etc/fstab}.
	\end{itemize}
		%
	The last alternative can be implemented by adding a line like
	the following to \fn{/etc/fstab}:
		%
		\begin{tscreen}
		/dev/fd0            /floppy      msdos   user,noauto
		\end{tscreen}
		%
	The columns are: device file to mount, directory to mount on,
	filesystem type, and options.  The \texttt{noauto} option
	stops this mount to be done automatically when the system
	is started (i.e., it stops \cmd{mount -a} from mounting it).
	The \texttt{user}
	option allows any user to mount the filesystem, and, because
	of security reasons, disallows execution of programs (normal
	or setuid) and interpretation of device files from the
	mounted filesystem.  After this, any user can mount a
	floppy with an \texttt{msdos} filesystem with the following
	command:
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $ | {\sl mount /floppy} \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%
	The floppy can (and needs to, of course) be unmounted with
	the corresponding \cmd{umount} command.

	\meta What to do if several types of floppies are needed?

	% for the future:
	% \meta automounting, more on mtools

\subsection{Keeping filesystems healthy}

	% for the future:
	% \meta fragmentation: what it is, and how to avoid it; 
	% maintaining free disk space; quotas; ext2fs 95 percent full

	Filesystems are complex creatures, and as such, they tend to be
	somewhat error-prone.  A filesystem's correctness and validity
	can be checked using the \cmd{fsck(8)} command.  It can be
	instructed to repair any minor problems it finds, and to
	alert the user if there any unrepairable problems.  Fortunately,
	the code to implement filesystems is debugged quite
	effectively, so there are seldom any problems at all, and they
	are usually caused by power failures, failing hardware, or
	operator errors; for example, by not shutting down the system
	properly.

	Most systems are setup to run \cmd{fsck} automatically at
	boot time, so that any errors are detected (and hopefully
	corrected) before the system is used.  Use of a corrupted
	filesystem tends to make things worse: if the data structures
	are messed up, using the filesystem will probably mess them
	up even more, resulting in more data loss.  However,
	\cmd{fsck} can take a while to run on big filesystems, and
	since errors almost never occur if the system has been shut
	down properly, a couple of tricks are used to avoid doing the
	checks in such cases.  The first is that if the file \fn{/etc/fastboot}
	exists, no checks are made.  The second is that the ext2 filesystem
	has a special marker in its superblock that tells whether
	the filesystem was unmounted properly after the previous mount.
	This allows \cmd{e2fsck} (the version of \cmd{fsck} for
	the ext2 filesystem) to avoid checking the filesystem if
	the flag indicates that the unmount was done (the assumption
	being that a proper unmount indicates no problems).  Whether
	the \fn{/etc/fastboot} trick works on your system depends on
	your startup scripts, but the ext2 trick works every time
	you use \cmd{e2fsck}---it has to be explicitly bypassed with
	an option to \cmd{e2fsck} to be avoided.  (See the \man{e2fsck(8)}
	man page for details on how.)

	The automatic checking only works for the filesystems that are
	mounted automatically at boot time.  Use \cmd{fsck} manually
	to check other filesystems, e.g., floppies.

	If \cmd{fsck} finds unrepairable problems, you need either
	in-depth knowlege of how filesystems work in general,
	and the type of the corrupt filesystem in particular, or
	good backups.  The latter is easy (although sometimes tedious)
	to arrange, the former can sometimes be arranged via a friend,
	the Linux newsgroups and mailing lists,
	or some other source of support, if you don't have the
	know-how yourself.  I'd like to tell you more
	about it, but my lack of education and experience in this regard
	hinders me.  The \cmd{debugfs(8)} program by Theodore T'so
	should be useful.

	\cmd{fsck} must only be run on unmounted filesystems, never on
	mounted filesystems (with the exception of the read-only root
	during startup).  This is because it accesses the raw
	disk, and can therefore modify the filesystem without the
	operating system realizing it.  There \emph{will} be trouble,
	if the operating system is confused.

	It can be a good idea to periodically check for bad blocks.
	This is done with the \cmd{badblocks} command.  It outputs
	a list of the numbers of all bad blocks it can find.  This list
	can be fed to \cmd{fsck} to be recorded
	in the filesystem data structures so that the operating system
	won't try to use the bad blocks for storing data.
	The following example will show how this could be done.
		%
		\begin{tscreen}
\verb|ttyp6 root ~ $| {\sl badblocks /dev/fd0H1440 1440 $>$ bad-blocks } \\
\verb|ttyp6 root ~ $| {\sl fsck -t ext2 -l bad-blocks /dev/fd0H1440} \\
\verb|Parallelizing fsck version 0.5a (5-Apr-94)| \\
\verb|e2fsck 0.5a, 5-Apr-94 for EXT2 FS 0.5, 94/03/10| \\
\verb|Pass 1: Checking inodes, blocks, and sizes| \\
\verb|Pass 2: Checking directory structure| \\
\verb|Pass 3: Checking directory connectivity| \\
\verb|Pass 4: Check reference counts.| \\
\verb|Pass 5: Checking group summary information.| \\
 \\
\verb|/dev/fd0H1440: ***** FILE SYSTEM WAS MODIFIED *****| \\
\verb|/dev/fd0H1440: 11/360 files, 63/1440 blocks| \\
\verb|ttyp6 root ~ $ |
		\end{tscreen}
		%

\section{Disks without filesystems}

	Not all disks or partitions are used as filesystems.  A swap
	partition, for example, will not have a filesystem on it.  Many
	floppies are used in a tape-drive emulating fashion, so that
	a \cmd{tar} or other file is written directly on the raw disk,
	without a filesystem.  This has the advantages of making more
	of the disk usable (a filesystem always has some bookkeeping
	overhead) and more easily compatible with other systems: the
	\cmd{tar} file format is the same on all systems, while filesystems
	are different on most systems.  You will quickly get used to
	disks without filesystems if you need them.  Bootable Linux
	floppies also do not necessarily have a filesystem, although that
	is also possible.

	One reason to use raw disks is to make image copies of them.
	For instance, if the disk contains a partially damaged filesystem,
	it is a good idea to make an exact copy of it before trying to
	fix it, since then you can start again if your fixing breaks things
	even more.  One way to do this is to use \cmd{dd(1)}:
		%
		\begin{tscreen}
\verb|ttyp2 root /usr/tmp $ | {\sl dd if=/dev/fd0H1440 of=floppy-image} \\
\verb|2880+0 records in| \\
\verb|2880+0 records out| \\
\verb|ttyp2 root /usr/tmp $ | {\sl dd if=floppy-image of=/dev/fd0H1440 } \\
\verb|2880+0 records in| \\
\verb|2880+0 records out| \\
\verb|ttyp2 root /usr/tmp $ |
		\end{tscreen}
		%
	The first \cmd{dd} makes an exact image of the floppy to the file
	\fn{floppy-image}, the second one writes the image to the floppy.
	(The user has presumably switched the floppy before the second
	command.  Otherwise the command pair is of doubtful usefulness.)

\section{Allocating disk space}

\subsection{Partitioning schemes}

	It is not easy to partition a disk in the best possible way.
	Worse, there is no universally correct way to
	do it; there are too many factors involved.

	The traditional way is to have a (relatively) small root
	filesystem, which contains \fn{/bin}, \fn{/etc}, \fn{/dev},
	\fn{/lib}, \fn{/tmp}, and other stuff that is needed to get the
	system up and running.  This way, the root filesystem (in its
	own partition or on its own disk) is all that is needed to bring
	up the system.  The reasoning is that if the root filesystem is
	small and is not heavily used, it is less likely to become
	corrupt when the system crashes, and you will therefore find it
	easier to fix any problems caused by the crash.  Then you create
	separate partitions or use separate disks for the directory tree
	below \fn{/usr}, the users' home directories (often under
	\fn{/home}), and the swap space.  Separating the home
	directories (with the users' files) in their own partition makes
	backups easier, since it is usually not necessary to backup
	programs (which reside below \fn{/usr}).  In a networked
	environment it is also possible to share \fn{/usr} among several
	machines (e.g., by using NFS), thereby reducing the total disk
	space required by several tens or hundreds of megabytes times
	the number of machines.

	The problem with having many partitions is that it splits the
	total amount of free disk space into many small pieces.
	Nowadays, when disks and (hopefully) operating systems are
	more reliable, many people prefer to have just one partition
	that holds all their files.  On the other hand, it can be less
	painful to back up (and restore) a small partition.

	For a small hard disk (assuming you don't do kernel
	development), the best way to go is probably to have just one
	partition.  For large hard disks, it is probably
	better to have a few large partitions, just in case
	something does go wrong.  (Note that `small' and `large' are
	used in a relative sense here; your needs for disk space
	decide what the threshold is.)

	If you have several disks, you might wish to have the root
	filesystem (including \fn{/usr}) on one, and the users' home
	directories on another.

	It is a good idea to be prepared to experiment a bit with
	different partitioning schemes (over time, not just while
	first installing the system).  This is a bit of work, since it
	essentially requires you to install the system from scratch
	several times, but it is the only way to be sure you do it right.

\subsection{Space requirements}

	The Linux distribution you install will give some indication
	of how much disk space you need for various configurations.  
	Programs installed separately may also do the same.  This will
	help you plan your disk space usage, but you should prepare
	for the future and reserve some extra space for things you will
	notice later that you need.

	The amount you need for user files depends on what your users
	wish to do.  Most people seem to need as much space for their
	files as possible, but the amount they will live happily with
	varies a lot.  Some people do only light text processing and
	will survive nicely with a few megabytes, others do heavy
	image processing and will need gigabytes.

	By the way, when comparing file sizes given in kilobytes or
	megabytes and
	disk space given in megabytes, it can be important to know that
	the two units can be different.  Some disk manufacturers like
	to pretend that a kilobyte is 1000 bytes and a megabyte is
	1000 kilobytes, while all the rest of the computing world
	uses 1024 for both factors.  Therefore, my 345~MB hard disk
	is really a 330~MB hard disk.\footnote{Sic transit discus mundi.}

	Swap space allocation is discusses in section~\ref{sec:swap-alloc}.

\subsection{Examples of hard disk allocation}

	% \meta rewrite this so that it doesn't use "I"

	I used to have a 109~MB hard disk.  Now I am using a 330~MB
	hard disk.  I'll explain how and why I partitioned these
	disks.

	The 109~MB disk I partitioned in a lot of ways, when my needs
	and the operating systems I used changed; I'll explain two
	typical scenarios.  First, I used to run MS-DOS
	together with Linux.  For that, I needed about 20~MB of
	hard disk, or just enough to have MS-DOS, a C compiler, an
	editor, a few other utilities, the program I was working on,
	and enough free disk space to not feel claustrophobic.  For
	Linux, I had a 10~MB swap partition, and the rest, or 79~MB,
	was a single partition with all the files I had under
	Linux.  I experimented with having separate root,
	\fn{/usr}, and \fn{/home} partitions, but there was never
	enough free disk space in one piece to do much interesting.

	When I didn't need MS-DOS anymore, I repartitioned the disk so
	that I had a 12~MB swap partition, and again had the rest as a
	single filesystem.

	The 330~MB disk is partitioned into several partitions, like
	this:
		%
		\begin{quote}
		\begin{tabular}{r l}
	  	  5 MB & root filesystem \\
	 	 10 MB & swap partition \\
		180 MB & \fn{/usr} filesystem \\
		120 MB & \fn{/home} filesystem \\
	 	 15 MB & scratch partition
		\end{tabular}
		\end{quote}
		%
	The scratch partition is for playing around with things that
	require their own partition, e.g., trying different Linux
	distributions, or comparing speeds of filesystems.  When not
	needed for anything else, it is used as swap space (I like to
	have a {\em lot} of open windows).

\subsection{Adding more disk space for Linux}

	Adding more disk space for Linux is easy, at least after the
	hardware has been properly installed  (the hardware installation is
	outside the scope of this book).  You format it if necessary,
	then create the partitions and filesystem as described above, and
	add the proper lines to \fn{/etc/fstab} so that it is mounted
	automatically.

\subsection{Tips for saving disk space}

	The best tip for saving disk space is to avoid installing
	unnecessary programs.  Most Linux distributions have an
	option to install only part of the packages they contain,
	and by analyzing your needs you might notice that you don't
	need most of them.  This will help save a lot of disk space,
	since many programs are quite large.  Even if you do need a
	particular package or program, you might not need all of it.
	For example, some on-line documentation might be unnecessary,
	as might some of the Elisp files for GNU Emacs, some of the
	fonts for X11, or some of the libraries for programming.

	If you cannot uninstall packages, you might look into
	compression.  Compression programs such as \cmd{gzip(1)} or
	\cmd{zip(1)} will compress (and uncompress) individual files
	or groups of files.  The \cmd{gzexe} system will compress and
	uncompress programs invisibly to the user (unused programs
	are compressed, then uncompressed as they are used).
	The experimental \cmd{DouBle} system
	will compress all files in a filesystem, invisibly to the
	programs that use them.  (If you are familiar with products
	such as Stacker for MS-DOS, the principle is the same.)
