It's Not What You Write, it's How You Write It

The old-timers in the audience probably got this one on the first try. We need to format the drive. Formatting (usually known as "making a filesystem" in Linux parlance) writes information to the drive, creating order out of the empty space in an unformatted drive.

As Figure B-2 implies, the order imposed by a filesystem involves some tradeoffs:

• A small percentage of the drive's available space is used to store filesystem-related data, and can be considered as overhead.

• A filesystem splits the remaining space into small, consistently-sized segments. In the Linux world, these segments are known as blocks. [1]

Given that filesystems make things like directories and files possible, these tradeoffs are usually seen as a small price to pay.

It's also worth noting that there is no single, universal filesystem; as Figure B-3 shows, a disk drive may have one of many different filesystems written on it. As you might guess, different filesystems tend to be incompatible; that is, an operating system that supports one filesystem (or a handful of related filesystem types) may not support another. This last statement is not a hard-and-fast rule, however. For example, Red Hat Linux supports a wide variety of filesystems (including many commonly used by other operating systems), making data interchange easy.

Of course, writing a filesystem to disk is only the beginning. The goal of this process is to actually store and retrieve data. Let's take a look at our drive after some files have been written to it.

As Figure B-4 shows, 14 of the previously-empty blocks are now holding data. We cannot determine how many files reside on this drive; it may be as few as one or as many as 14, as all files use at least one block. Another important point to note is that the used blocks do not have to form a contiguous region; used and unused blocks may be interspersed. This is known as fragmentation. Fragmentation can play a part when attempting to resize an existing partition.

As with most computer-related technologies, disk drives continued to change over time. In particular, they changed in one specific way -- they got bigger. Not bigger in size, but bigger in capacity. And it was this additional capacity that drove a change in the way disk drives were used.

Partitions -- Turning One Drive Into Many

As disk drive capacities soared, some people started wondering if having all that space in one big chunk wasn't such a great idea. This line of thinking was driven by several issues, some philosophical, some technical. On the philosophical side, above a certain size, it seemed that the additional space provided by a larger drive created more clutter. On the technical side, some filesystems were never designed to support larger drives. Or the filesystems could support larger drives, but the overhead imposed by the filesystem became excessive.

The solution to this problem was to divide disks into partitions. Each partition can be accessed as if it was a separate disk. This is done through the addition of a partition table.

	Please Note
	While the diagrams in this chapter show the partition table as being separate from the actual disk drive, this is not entirely accurate. In reality, the partition table is stored at the very start of the disk, before any filesystem or user data. But for clarity, we'll keep it separate in our diagrams.

As Figure B-5 shows, the partition table is divided into four sections. Each section can hold the information necessary to define a single partition, meaning that the partition table can define no more than four partitions.

Each partition table entry contains several important characteristics of the partition:

• The points on the disk where the partition starts and ends;

• Whether the partition is "active";

• The partition's type.

Let's take a closer look at each of these characteristics. The starting and ending points actually define the partition's size and location on the disk. The "active" flag is used by some operating systems' boot loaders. In other words, the operating system in the partition that is marked "active" will be booted.

The partition's type can be a bit confusing. The type is a number that identifies the partition's anticipated usage. If that statement sounds a bit vague, that's because the meaning of the partition type is a bit vague. Some operating systems use the partition type to denote a specific filesystem type, to flag the partition as being associated with a particular operating system, to indicate that the partition contains a bootable operating system, or some combination of the three.

Table B-1 contains a listing of some popular (and obscure) partition types, along with their numeric values.

Now you might be wondering how all this additional complexity is normally used. See Figure B-6 for an example.

That's right -- in many cases there is but a single partition spanning the entire disk, essentially duplicating the pre-partitioned days of yore. The partition table has only one entry used, and it points to the start of the partition.

We've labeled this partition as being of type "DOS," although as you can see from Table B-1, that's a bit simplistic, but adequate for the purposes of this discussion. This is a typical partition layout for most newly purchased computers with some version of Windows pre-installed.

Partitions within Partitions -- An Overview of Extended Partitions

Of course, in time it became obvious that four partitions would not be enough. As disk drives continued to grow, it became more and more likely that a person could configure four reasonably-sized partitions and still have disk space left over. There needed to be some way of creating more partitions.

Enter the extended partition. As you may have noticed in Table B-1, there is an "Extended" partition type; it is this partition type that is at the heart of extended partitions. Here's how it works.

When a partition is created and its type is set to "Extended," an extended partition table is created. In essence, the extended partition is like a disk drive in its own right -- it has a partition table that points to one or more partitions (now called logical partitions, as opposed to the four primary partitions) contained entirely within the extended partition itself. Figure B-7 shows a disk drive with one primary partition, and one extended partition containing two logical partitions (along with some unpartitioned free space).

As this figure implies, there is a difference between primary and logical partitions -- there can only be four primary partitions, but there is no fixed limit to the number of logical partitions that can exist. (However, in reality it is probably not a good idea to try to define and use more than 12 logical partitions on a single disk drive.)

Now that we've discussed partitions in general, let's see how to use this knowledge to get Red Hat Linux installed.

Making Room For Red Hat Linux

There are three possible scenarios you may face when attempting to repartition your hard disk:

• Unpartitioned free space is available.

• An unused partition is available.

• Free space in an actively used partition is available.

Let's look at each scenario in order.

	Please Note
	Please keep in mind that the following illustrations are simplified in the interest of clarity, and do not reflect the exact partition layout that you will encounter when actually installing Red Hat Linux.

Using Free Space From An Active Partition

This is the most common situation. It is also, unfortunately, the hardest to work with. The main problem is that, even if you have enough free space, it's presently allocated to a partition that is in use. If you purchased a computer with pre-installed software, the hard disk most likely has one massive partition holding the operating system and data.

Aside from adding a new hard drive to your system, you have two choices:

Destructive Repartitioning

Basically, you delete the single large partition, and create several smaller ones. As you might imagine, any data you had in the original partition is destroyed. This means that making a complete backup is necessary. For your own sake, make two backups, use verification (if available in your backup software), and try to read data from your backup before you delete the partition. Note also that if there was an operating system of some type installed on that partition, it will need to be reinstalled as well.

After creating a smaller partition for your existing software, you can reinstall any software, restore your data, and continue with your Red Hat Linux installation. Figure B-10 shows this being done.

Figure B-10. Disk Drive Being Destructively Repartitioned

As Figure B-10 shows, any data present in the original partition will be lost without proper backup!

Non-Destructive Repartitioning

Here, you run a program that does the seemingly impossible: it makes a big partition smaller without losing any of the files stored in that partition. Many people have found this method to be reliable and trouble-free. What software should you use to perform this feat? There are several disk management software products on the market; you'll have to do some research to find the one that is best for your situation.

While the process of non-destructive repartitioning is rather straightforward, there are a number of steps involved:

• Compress existing data

• Resize partition

• Create new partition(s)

Let's take a look at each step in a bit more detail.

Compress existing data

As Figure B-11 shows, the first step is to compress the data in your existing partition. The reason for doing this is to rearrange the data such that it maximizes the available free space at the "end" of the partition.

Figure B-11. Disk Drive Being Compressed

This step is crucial; without it, it is possible that the location of your data could prevent the partition from being resized to the extent desired. Note also that, for one reason or another, some data cannot be moved. If this is the case (and it restricts the size of your new partition(s)), you may be forced to destructively repartition your disk.

Resize partition

Figure B-12 shows the actual resizing process. While the actual end-product of the resizing operation varies depending on the software used, in most cases the newly freed space is used to create an unformatted partition of the same type as the original partition.

Figure B-12. Disk Drive with Partition Resized

It's important to understand what the resizing software you use does with the newly freed space, so that you can take the appropriate steps. In the case we've illustrated, it would be best to simply delete the new DOS partition, and create the appropriate Linux partition(s).

Create new partition(s)

As the previous step implied, it may or may not be necessary to create new partitions. However, unless your resizing software is Linux-aware, it is likely you'll need to delete the partition that was created during the resizing process. Figure B-13 shows this being done.

Figure B-13. Disk Drive with Final Partition Configuration

	Intel
	The following information is specific to Intel-based computers only.

As a convenience to our customers, we provide the fips utility. This is a freely available program that can resize FAT (File Allocation Table) partitions. It's included on the Red Hat Linux/Intel CD-ROM in the dosutils directory.

	Please Note
	Many people have successfully used fips to repartition their hard drives. However, because of the nature of the operations carried out by fips, and the wide variety of hardware and software configurations under which it must run, Red Hat cannot guarantee that fips will work properly on your system. Therefore, no installation support whatsoever is available for fips; use it at your own risk.

That said, if you decide to repartition your hard drive with fips, it is vital that you do two things:

• Perform a Backup -- Make two copies of all the important data on your computer. These copies should be to removable media (such as tape or diskettes), and you should make sure they are readable before proceeding.

• Read the Documentation -- Completely read the fips documentation, located in the /dosutils/fipsdocs subdirectory on Red Hat Linux/Intel CD 1.

Should you decide to use fips, be aware that after fips runs you will be left with two partitions: the one you resized, and the one fips created out of the newly freed space. If your goal is to use that space to install Red Hat Linux, you should delete the newly created partition, either by using fdisk under your current operating system, or while setting up partitions during a custom-class installation.

Partition Naming Scheme

Linux refers to disk partitions using a combination of letters and numbers which may be confusing, particularly if you're used to the "C drive" way of referring to hard disks and their partitions. In the DOS/Windows world, here is how partitions are named:

• Each partition's type is checked to determine if it can be read by DOS/Windows.

• If the partition's type is compatible, it is assigned a "drive letter." The drive letters start with "C".

• The drive letter can then be used to refer to that partition as well as the filesystem contained on that partition.

Red Hat Linux uses a naming scheme that is more flexible and conveys more information than the approach used by other operating systems. The naming scheme is file-based, with filenames in the form:

/dev/xxyN
        

Here's how to decipher the partition naming scheme:

/dev/

This string is the name of the directory in which all device files reside. Since partitions reside on hard disks, and hard disks are devices, the files representing all possible partitions reside in /dev/.

xx

The first two letters of the partition name indicate the type of device on which the partition resides. You'll normally see either hd (for IDE disks), or sd (for SCSI disks).

y

This letter indicates which device the partition is on. For example, /dev/hda (the first IDE hard disk) or /dev/sdb (the second SCSI disk).

N

The final number denotes the partition. The first four (primary or extended) partitions are numbered 1 through 4. Logical partitions start at 5. E.g., /dev/hda3 is the third primary or extended partition on the first IDE hard disk; /dev/sdb6 is the second logical partition on the second SCSI hard disk.

	Please Note
	There is no part of this naming convention that is based on partition type; unlike DOS/Windows, all partitions can be identified under Red Hat Linux. Of course, this doesn't mean that Red Hat Linux can access data on every type of partition, but in many cases it is possible to access data on a partition dedicated to another operating system.

Keep this information in mind; it will make things easier to understand when you're setting up the partitions Red Hat Linux requires.

Disk Partitions and Other Operating Systems

If your Red Hat Linux partitions will be sharing a hard disk with partitions used by other operating systems, most of the time you'll have no problems. However, there are certain combinations of Linux and other operating systems that require extra care. Information on creating disk partitions compatible with other operating systems is available in several HOWTOs and Mini-HOWTOs, available on the Red Hat Linux CD in the doc/HOWTO and doc/HOWTO/mini directories. In particular, the Mini-HOWTOs whose names start with Linux+ are quite helpful.

	Intel
	If Red Hat Linux/Intel will coexist on your machine with OS/2 , you must create your disk partitions with the OS/2 partitioning software---otherwise, OS/2 may not recognize the disk partitions. During the installation, do not create any new partitions, but do set the proper partition types for your Linux partitions using the Linux fdisk.

Disk Partitions and Mount Points

One area that many people new to Linux find confusing is the matter of how partitions are used and accessed by the Linux operating system. In DOS/Windows, it is relatively simple: If you have more than one partition, each partition gets a "drive letter." You then use the drive letter to refer to files and directories on a given partition.

This is entirely different from how Red Hat Linux deals with partitions and, for that matter, with disk storage in general. The main difference is that each partition is used to form part of the storage necessary to support a single set of files and directories. This is done by associating a partition with a directory through a process known as mounting. Mounting a partition makes its storage available starting at the specified directory (known as a mount point).

For example, if partition /dev/hda5 were mounted on /usr, that would mean that all files and directories under /usr would physically reside on /dev/hda5. So the file /usr/doc/FAQ/txt/Linux-FAQ would be stored on /dev/hda5, while the file /etc/X11/gdm/Sessions/Gnome would not.

Continuing our example, it is also possible that one or more directories below /usr would be mount points for other partitions. For instance, a partition (say, /dev/hda7) could be mounted on /usr/local, meaning that, for example, /usr/local/man/whatis would then reside on /dev/hda7 rather than /dev/hda5.

How Many Partitions?

At this point in the process of preparing to install Red Hat Linux, you will need to give some consideration to the number and size of the partitions to be used by your new operating system. The question of "how many partitions" continues to spark debate within the Linux community and, without any end to the debate in sight, it's safe to say that there are probably as many partition layouts as there are people debating the issue.

Keeping this in mind, we recommend that, unless you have a reason for doing otherwise, you should create the following partitions:

• A swap partition -- Swap partitions are used to support virtual memory. In other words, data is written to swap when there is not RAM to hold the data your system is processing. If your computer has 16 MB of RAM or less, you must create a swap partition. Even if you have more memory, a swap partition is still recommended. The minimum size of your swap partition should be equal to your computer's RAM, or 16 MB (whichever is larger).

• Intel

  The following partition is specific to Red Hat Linux/Intel installations. A /boot partition -- The partition mounted on /boot contains the operating system kernel (which allows your system to boot Red Hat Linux), along with a few other files used during the bootstrap process. Due to the limitations of most PC BIOSes, creating a small partition to hold these files is a good idea. This partition should be no larger than 16MB.

  	Please Note
  	Make sure you read the section called One Last Wrinkle: Using LILO -- the information there applies to the /boot partition!

• 	Alpha
  	The following partition is specific to Red Hat Linux/Alpha installations. A MILO partition -- Alpha owners that will be using MILO to boot their systems should create a 2MB DOS partition where MILO can be copied after the installation is complete. We recommend using /dos as the mount point.

• A root partition (/) -- The root partition is where / (the root directory) resides. In this partitioning layout, all files (except those stored in /boot) reside on the root partition. Because of this, it's in your best interest to maximize the size of your root partition. A 600MB root partition will permit the equivalent of a workstation-class installation (with very little free space), while a 1.5GB root partition will let you install every package.

One Last Wrinkle: Using LILO

LILO (the LInux LOader) is the most commonly used method to boot Red Hat Linux on Intel-based systems. An operating system loader, LILO operates "outside" of any operating system, using only the Basic I/O System (or BIOS) built into the computer hardware itself. This section describes LILO's interactions with PC BIOSes, and is specific to Intel-compatible computers.

BIOS-Related Limitations Impacting LILO

LILO is subject to some limitations imposed by the BIOS in most Intel-based computers. Specifically, most BIOSes can't access more than two hard drives and they can't access any data stored beyond cylinder 1023 of any drive. Note that some recent BIOSes do not have these limitations, but this is by no means universal.

All the data LILO needs to access at boot time (including the Linux kernel) are located in the /boot directory. If you follow the partition layout recommended above, or you are performing a workstation- or server-class install, the /boot directory will be in a small, separate partition. Otherwise, it will reside in the root partition. In either case, the partition in which /boot resides must conform to the following guidelines if you are going to use LILO to boot your Red Hat Linux system:

On First Two IDE Drives

If you have 2 IDE (or EIDE) drives, /boot must be located on one of them. Note that this two-drive limit also includes any IDE CD-ROM drives on your primary IDE controller. So, if you have one IDE hard drive, and one IDE CD-ROM on your primary controller, /boot must be located on the first hard drive only, even if you have other hard drives on your secondary IDE controller.

On First IDE or First SCSI Drive

If you have one IDE (or EIDE) drive and one or more SCSI drives, /boot must be located either on the IDE drive or the SCSI drive at ID 0. No other SCSI IDs will work.

On First Two SCSI Drives

If you have only SCSI hard drives, /boot must be located on a drive at ID 0 or ID 1. No other SCSI IDs will work.

Partition Completely Below Cylinder 1023

No matter which of the above configurations apply, the partition that holds /boot must be located entirely below cylinder 1023. If the partition holding /boot straddles cylinder 1023, you may face a situation where LILO will work initially (because all the necessary information is below cylinder 1023), but will fail if a new kernel is to be loaded, and that kernel resides above cylinder 1023.

As mentioned earlier, it is possible that some of the newer BIOSes may permit LILO to work with configurations that don't meet our guidelines. Likewise, some of LILO's more esoteric features may be used to get a Linux system started, even if the configuration doesn't meet our guidelines. However, due to the number of variables involved, Red Hat cannot support such extraordinary efforts.

	Please Note
	Disk Druid as well as the workstation- and server-class installs take these BIOS-related limitations into account.