1. Types of disks
1. Floppy (Major Device # = 2)

 

Controllers

 

Minor Device #	Device Name	Description
0	/dev/fd0	Controller 1, drive 1 autodetect
1	/dev/fd1	Controller 1, drive 2 autodetect
2	/dev/fd2	Controller 1, drive 3 autodetect
3	/dev/fd3	Controller 1, drive 4 autodetect
128	/dev/fd4	Controller 2, drive 1 autodetect
129	/dev/fd5	Controller 2, drive 2 autodetect
130	/dev/fd6	Controller 2, drive 3 autodetect
131	/dev/fd7	Controller 2, drive 4 autodetect

 

 

5.25" Devices

 

Minor Device #	Device Name	Description
0	/dev/fd?	autodetect format
4	/dev/fd?d360	360K in a 360K drive
20	/dev/fd?h360	360K in a 1200K drive
48	/dev/fd?h410	410K in a 1200K drive
64	/dev/fd?h420	420K in a 1200K drive
24	/dev/fd?h720	720K in a 1200K drive
80	/dev/fd?h880	880K in a 1200K drive
8	/dev/fd?h1200	1200K in a 1200K drive
40	/dev/fd?h1440	1440K in a 1200K drive
56	/dev/fd?h1476	1476K in a 1200K drive
72	/dev/fd?h1494	1494K in a 1200K drive
92	/dev/fd?h1600	1600K in a 1200K drive

 

 

3.5" Devices

 

Minor Device #	Device Name	Description
12	/dev/fd?u360	360K Double Density
16	/dev/fd?u720	720K Double Density
120	/dev/fd?u800	800K Double Density
52	/dev/fd?u820	820K Double Density
68	/dev/fd?u830	830K Double Density
84	/dev/fd?u1040	1040K Double Density
88	/dev/fd?u1120	1120K Double Density
28	/dev/fd?u1440	1440K High Density
124	/dev/fd?u1600	1600K High Density
44	/dev/fd?u1680	1680K High Density
60	/dev/fd?u1722	1722K High Density
76	/dev/fd?u1743	1743K High Density
96	/dev/fd?u1760	1760K High Density
116	/dev/fd?u1840	1840K High Density
100	/dev/fd?u1920	1920K High Density
32	/dev/fd?u2880	2880K High Density
104	/dev/fd?u3200	3200K High Density
108	/dev/fd?u3520	3520K High Density
112	/dev/fd?u3840	3840K High Density
36	/dev/fd?CompaQ	Compaq 2880K drive; probably obsolete

 

1. Common Characteristics
1. Slow
2. Cheap
3. Limited Capacity
4. Easily transportable
2. Hard
1. Fixed vs Removable
1. Fixed - Means that the content of the data contained on the Unix Device (/dev/???) will remain consistent through a dismount/mount cycle.
2. Removable - Means the content of the data contained on the Unix Device (/dev/???) may change though a dismount/mount cycle. This is possible as the physically media may be replaced by another physical media between the dismount/mount commands. It is up to the systems administrator/usr/application to insure the proper physical media is mounted on the Unix device.
3. All commands (Shell and O/S) are identical to each type of device.
2. ST506 & ESDI (Older XT/AT standards - aka MFM & RLL drives)
3. IDE vs EIDE
1. IDE (aka ATA)
1. 528 MB limit
2. 3 MB/sec transfer rate
3. 2 devices per controller - 1 primary & 1 secondary
4. Limited to only disk drives
2. EIDE (aka Fast ATA)
1. 8.4 GB limit
2. Transfer Speeds
1. PIO Mode 3 (11.1 MB/sec)
2. PIO Mode 4 (16.1 MB/sec)
3. Multiword Mode 1 DMA (13.3 MB/sec)
4. Multiword Mode 2 DMA (16.1 MB/sec)
3. Provides for DMA (Direct Memory Access) data transfers
4. 4 -devices per controller - 2 primary (usually local bus speeds) & 2 secondary (usually ISA bus speeds). Attach slower devices (tapes & CD-ROMs) to secondary channel due to lower transfer rate requirements. Save primary channel for disks due to higher transfer rate requirements.
5. Supports CD-ROMs & tapes as well as disk drives
4. SCSI vs SCSI Fast vs SCSI Wide vs SCSI Ultra Wide vs SCSI-2 vs SCSI-3
1. SCSI - 5 MB/Sec - 8 bit bus
2. SCSI -2 - Backward compatible with all older/slower SCSI
1. SCSI-2 Fast - 10 MB/Sec - 8 bit bus
2. SCSI-2 Wide - 10 MB/Sec - 16 bit bus
3. SCSI-2 Ultra - 20 MB/Sec - 8 bit bus
4. SCSI-2 Ultra Wide- 40 MB/Sec - 16 bit bus
3. SCSI-3
1. Currently under development
2. Expanded command set
3. No speed increases
5. EIDE vs SCSI

 

EIDE	SCSI
Internal Cabling	Internal and/or External Cabling
FIFO I/O queuing	Tag command queuing & elevator seeking- Reorders I/O to reduce seek time and head movements
Compatibility between manufactures is spotty	Compatibility is not an issue
Cabling requirements are more forgiving	Cabling requirements are demanding
Terminator scheme is straight-forward	Terminator scheme is slightly more complicated
8.4 GB/drive limit	8.4 GB/drive limit
Internal hard drives, CD-ROM drives, tape drives	Internal and external hard drives, CD-R, CD-ROM, DAT, and tape drives; scanners; other peripherals
Maximum Connections: Four	Maximum Connections: 7
VL-Bus or PCI	VL-Bus or PCI
Generally cheaper	Generally more expensive
May require jumper modifications for Primary/Secondary device settings	May require jumper modifications for SCSI-ID and termination settings

 

1. EIDE is fine for workstation configurations or where budget considerations mandate lower costs. SCSI is preferable for server configurations or in heavy multi-user systems.
3. CD-ROM
1. Types
1. Read Only
2. WORM (Write Once - Read Many) - Writing requires a very lightly loaded system in order that data is always available for writing the data in one continuous pass of the media.
3. IDE, EIDE and SCSI available
4. Internal and External available
5. Single unit and tower units available
6. Caddy or Caddyless available
7. Multiple disk caddies are available
8. May require horizontal orientation
9. Speeds
1. 1X - transfer rate of 153.6 KB/sec
2. 2X
3. 4X - This is the minimally acceptable speed (with 250 kB buffer)
4. 6X
5. 8X
6. 10X
2. 682 MB capacity (Most use only 533MB)
3. ISO9660 filesystems are supported by M$ operating systems, Apple operating systems, and Unix operating systems

 

4. Futures - DVD

 

DVD Format	Capacity (120-mm disc)	Capacity (80-mm disc)
DVD-ROM: one side, one layer	4.7 GB	1.4 GB
DVD-ROM: one side, two layers	8.5 GB	2.6 GB
DVD-ROM: two sides, one layer	9.4 GB	2.9 GB
DVD-ROM: two sides, two layers	17 GB	5.3 GB
DVD-R: one side, one layer	3.9 GB	1.2 GB
DVD-R: two sides, one layer	7.8 GB	2.4 GB
DVD-RAM: one side, one layer	2.6 GB	0.7 GB
DVD-RAM: two sides, one layer	5.2 GB	1.5 GB

 

DVD-ROM - Similar in concept to CD-ROM.

DVD-R - Similar in concept to WORM.

DVD-RAM - Rewritable phase change.

 

 

5. RAM
1. A pseudo device stored in memory which acts like a physical device.
2. Very fast
3. Limited capacity
4. Volitle data (data is lost at system shutdown or system fault)
6. Floptical
1. Removable media
2. Faster than floppy - slower than hard disk
3. Re-writable
4. 100+ MB storage capacity
5. Often used to transfer graphics files
7. Zip and Jazz drives
1. Zip drives are a SCSI command set over a parallel port attachment. You need a relatively recent kernel to use these devices. Each media must be formatted separately then a file system created on each media. They should be treated from a users perspective exactally as one would a floppy disk. Mount/Use/Dismount. Be warned that the use of the parallel port simultaneously for printing may cause unpredictable results. There seems to be some debate as to being able to boot from this device. I am reasonably sure such a function will be explicitly provided in future PC BIOS and Linux kernels.
1. Jazz drives are a SCSI command set driven by a SCSI controller. Just like the Jazz drive you must format each media independently. You must also use the Mount/Use/Dismount sequence to keep things straight. Booting from these devices has been done succesfully by some, but not all. Again, I expect to see better support for these devices in the PC BIOS and Linux kernel soon.

 

8. Considerations
1. Average seek time - defines the average time the disk takes to move its read/write heads over the platters to a requested track. Seek times tend to decrease as you grow in disk capacity. Expect to see seek times of 10 to 12 ms in 540 MB drives, i to 10 ms for drives that are 730 MB or larger.

 

2. Average latency - defines the time the device take to spin the platters until the appropriate portions of the track are spinning under the heads. Expect to see latency times of 5.6 ms for 540 MB to 1 GB disks, and 4.2 ms for disks larger than 1 GB.

 

3. Average access time - defines the sum of Average seek time and Average Latency. It typically represents the amount of time it takes a disk to find a chunk of data. Expect 12.2 ms to 18 ms access times. Keep in mind that most ads in computer magazines quote seek times, even when they claim to be quoting access times. Random access applications (database or transaction processing) are most affected by average access time.

 

4. Data transfer rate (aka throughput) - defines that rate at which data is read from or written to the disk once the heads are positioned. Applications which read/write data sequentially are most affected by the data transfer rate.
1. Burst transfer rate - (aka external transfer rate) - defines the rate at which data is read from the drive buffer, which is a chunk of memory on the drive that captures disk reads and writes for faster access (disk cache). EIDE and Fast ATA drives typically have maximum burst data transfer rates of 11.1 to 16.6 MB/sec. SCSI-2 drives have maximum burst rates from 10 to 40 MB/sec.

 

2. Sustained transfer rate (aka internal transfer rate) - defines the rate at which data is read from the drive when the disk buffer is not being used. This rate is greatly dependent upon the spindle speed (aka rotational speed). Spindle speed is measured in revolutions per minute (RPM). Expect to see 5400 rpm for disks of 540 MB to 1 GB and 7200 rpm for disks above 1 GB.

 

5. A device can be no faster than its controller or its bus. Generally speaking the controller is not a limiting factor. An 16-bit- ISA bus has a maximum throughput of 8.3 MB/sec but it practical limit of about 3 MB/sec. An 16-bit -EISA bus has a throughput of about 33 MB/sec. A VESA local bus (VLB) or a PCI bus will often support 132 MB/sec.

 

2. Partition Geometry

 

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. Formatted vs Unformatted
1. Unformatted = #Sectors * Bytes/Sector
2. Formatted = (#Sectors * Bytes/Sector) - Spares - MBR
2. System BIOS
1. The System BIO (a hardware chip) contains the instructions and parameters necessary for a computer to begin the bootload process. One of the parameters is the type of disk and the geometry of each disk. The BIOS was developed during the days of 5-10 MB hard disks. Unfortunately in order to keep compatibility, the geometry parameters have not changed. Let us examine the problem in more detail.

struct partition {

char active; /* 0x80: bootable, 0: not bootable */

char begin[3]; /* CHS for first sector */

char type;

char end[3]; /* CHS for last sector */

int start; /* 32 bit sector number */

/* (counting from 0) */

int length; /* 32 bit number of sectors */

};

(where CHS stands for Cylinder/Head/Sector). Note the use of 28 bits to store the CHS information used to described the disk geometry. The IDE controller used 28 bits to define the CHS information regarding the disks which it controls. However, each uses a different scheme for subdividing the 28 bits into CHS information.

 

Parameter	BIOS Limit	IDE Controller Limit	Effective Limit
Cylinder	0-1023	0-65,535	0-1023
Head	0-255	0-15	0-15
Sectors/Track	1-63	1-256	1-63
Capacity	7.875 GB	130.56 GB	504 MB

 

The BIOS, via INT13, uses the least common denominator approach to determine the disk geometry. So what's the problem? For IDE disks <504 MB, there is no problem. But for IDE disks >=504 MB (typically more than 1023 cylinders), and the operating system of choice uses the INT13 BIOS interface, cylinders past 1023 are inaccessible. What operating systems use the BIOS? MS-DOS, Windows 95, Windows NT. Linux does not use the BIOS to access the disk. So therefore, this does not present a problem for Linux.

 

Well, except for two things:

(1) When you boot you system, Linux isn't running yet and cannot save you from the BIOS limitations. This has some consequences for LILO and similar boot loaders.

(2) It is necessary for all operating systems that use one disk to agree on where the partitions are. In other words, if you use both Linux and say DOS on one disk, then both must interpret the partition table in the same way. This has some consequences for the Linux kernel and for fdisk.

 

When the system is booted, the BIOS reads sector 0 (known as the MBR- the Master Boot Record) from the first disk (or from floppy), and jumps to the code found there - usually some bootstrap loader. These small bootstrap programs found there typically do not have their own disk drivers and use the BIOS services. This means that a Linux kernel can only be booted when it is entirely located within the first 1024 cylinders of a disk that the BIOS can access - probably this means the first or second disk.

 

Another point is the boot loader and the BIOS must agree as to the disk geometry. It may help to give LILO the 'linear' option. More details below.

 

If you have several operating systems on you disks, then each uses one or more disk partitions. A disagreement on where these partitions are may have catastrophic consequences.

 

The MBR contains a partition table describing where the (primary) partitions are. There are 4 table entries, for 4 primary partitions. The format of the partition table is given above. By inspection, it become obvious that some information is redundant; the location of a partition is given both by the 24-bit begin and end fields, and by the 32-bit start and length fields.

 

Linux only uses the start and length fields, and can therefore handle partitions of nor more than 2^32 sectors, that is, partitions of at most 2 TB. That is two hundred times larger than the disks available today, so maybe it will be enough for the next ten years or so.

 

Unfortunately, the BIOS INT13 call used CHS coded in three bytes, with 10 bits for the cylinder number, 8 bits for the head number, and 6 bits for the track sector number. Possible cylinder numbers are 0-1023, possible head numbers are 0-255, and possible track sector numbers are 1-63 (yes, sectors on a track are counted from 1, not 0). With these 24 bits, one can address 845571684 bytes (7.875 GB), two hundred times larger than the disks available in 1983.

 

Even more unfortunately, the standard IDE interface allows 256 sectors/track, 65536 cylinders and 16 heads. This in itself allows access to 2^37=137438953472 bytes (128 GB), but combined with the BIOS restriction to 63 sectors and 1024 cylinders only 528482394 bytes (504 MB) remain addressable.

 

This is not enough for present-day disks and people resort to all kinds of trickery, both in hardware and in software.

 

Nobody is interested in what the 'real' geometry of a disk is. Indeed, the number of sectors per track often is variable - there are more sectors per track close to the outer rim of the disk - so there is no 'real' number of sectors per track. For the user it is best to regard a disk as just a linear array of sectors numbered 0, 1, ...., and leave it to the controller to find out where a given sector lives on the disk.

 

This linear numbering is known as LBA. The linear address belonging to (c,h,s) for a disk with a geometry (C,H,S) is c*H*S + h*S + (s-1). All SCSI controllers speak LBA, while some IDE controllers do also.

 

If the BIOS converts the 24-bit (c,h,s) to LBA and feed that to a controller that understands LBA, then again 7.875 GB is addressable. Not enough for all disks, but still an improvement. Note that here CHS, as used by the BIOS, no longer has any relation to 'reality'.

 

Something similar works when the controller doesn't speak LBA but the BIOS knows about translation. (In the setup this is often indicated as 'Large'. Now the BIOS will present a geometry (C',H',S') to the operating system, and use (C,H,S) while talking to the disk controller. Usually S=S', C'=C/N and H' = H*N, where N is the smallest power of two that will ensure C" <= 1024 (so that least capacity is wasted by the rounding down in C' = C/N). Again, this allows access of up to 7.875 GB.

 

If a BIOS does now know about 'Large' or 'LBA', then there are software solutions around. Disk Manager like OnTrack or EZ-Drive replace the BIOS disk handling routines by their own. Often this is accomplished by having the disk manager code live in the MBR and subsequent sectors (OnTrack call this code DDO: Dynamic Drive Overlay), so that it is booted before any other operating system. That is why one may have problems when booting from a floppy when a Disk Manager has been installed.

The effect is more less the same as with a translating BIOS - but especially when running several operating systems on the same disk, disk managers can cause a lot of trouble.

 

Linux does support OnTrack Disk Manager since version 1.3.14, and EZ-Drive since version 1.3.29.

 

If the Linux kernel detects the presence of some disk manager on an IDE disk, it will try to remap the disk in the same way this disk manager would have done, so that Linux sees the same disk partitioning as for example DOS with OnTrack or EZ-Drive. However, No remapping is done when a geometry was specified on the command line - so a 'hd=cyls,heads,secs' command line option might well kill compatibility with a disk manager.

 

The remapping is done by trying 4, 8, 16, 32, 64, 128, 255 heads (keeping H*C) constant) until either C <= 1024 or H=255.

 

The details are as follows - subsection headers are the strings appearing in the corresponding boot messages. Here and everywhere else in this text, partition types are given in hexadecimal.

 

EZD

EZ-Drive is detected by the fact that the first primary partition has type 55. The geometry is remapped as described above, and the partition table from sector 0 is discarded - instead the partition table is read from sector 1. Disk block numbers are not changed, but writes to sector 0 are redirected to sector 1. This behavior can be changed by recompiling the kernel with

#define FAKE_FDISK_FOR_EZDRIVE 0 in ide.c

 

DM6:DDO

OnTrack DiskManager (on the first disk) is detected by the fact that the first primary partition has type 54. The geometry is remapped as described above and the entire disk is shifted by 63 sectors (so that the old sector 63 becomes sector 0). Afterwards a new MBR (with the partition table) is read from the new sector 0. Of course this shift is to make room for the DDO - that is why there is no shift on other disks.

 

DM6:AUX

OnTrack DiskManager (on other disks) is detected by the fact that the first primary partition has type 51 or 53. The geometry is remapped as described above.

 

DM6:MBR

An older version of OnTrack DiskManaager is detected not by partition type, but by signature. (Test whether the offset found in bytes 2 and 3 of the MBR is not more than 430, and the short found at this offset equals 0x55AA, and is followed by an odd byte.) Again the geometry is remapped as above.

 

PTBL

Finally, there is a test that tries to deduce a translation from the start and end values of the primary partitions: If some partition has start and end cylinder less than 256, and start and send sector number 1 and 63, respectively, and end heads 31, 63, or 127, then, since it is customary to end partitions on a cylinder boundary and since moreover the IDE interface uses at most 16 heads, it is conjectured that a BIOS translation is active, and the geometry is remapped to use 32, 64 or 128 heads, respectively. (Maybe there is a flaw here, and genhd.c should not have tested the high order two bits of the cylinder number?) However, no remapping is done when the current idea of the geometry already has 63 sectors per track and at least as many heads (since this probably means that a remapping was done already).

 

What does all of this mean? For Linux users only one thing: that they must make sure that LILO and fdisk (cfdisk) use the right geometry where 'right' is defined for fdisk as the geometry used by the other operating systems on the same disk, and for LILO as the geometry that will enable successful integration with the BIOS at boot time. (Usually these two requirements coincide.)

 

Then how does fdisk and an OS determine the geometry of a large IDE drive? In descending order 1) command line arguments 2) CMOS values and 3) IDE Controller values. The OS then must determine via algorithm not a physical geometry, but rather a logical geometry. As a point of fact, the actual physical geometry is unimportant, rather fdisk and an OS simply must agree on a logical geometry which maps the entire physical drive. The actual values of C', H', and S' may or may not match the physical drive, but they must be agreed upon by both fdisk and all the OSs which will use the partition tables.

 

For SCSI drives, the SCSI commands already use logical block numbers, so a 'geometry' is entirely irrelevant for actual I/O. However, the format of the partition table is still the same, so fdisk has to invent some geometry because fdisk does not distinguish between IDE and SCSI. What is the real geometry of a SCSI disk? The easiest answer is that there is no such thing. And if there were, you wouldn't wan to know, and certainly NEVER, EVER tell fdisk or LILO or the kernel about it. It is strictly a business between the SCSI controller and the disk. Let me repeat that: only silly people tell fdisk/LILO/kernel about the TRUE SCSI geometry.

 

One final note, by convention partitions end on a cylinder boundary. This again is for the convience of DOS partitions. Some fdisk implementations enforce this restrictions, some implementations give warnings if this restriction is ignored, and some implementation ignore this restriction. My advice would be to pay homage to DOS and be safe.

 

 

 

 

3. SCSI BIOS - Often separate from the mother board BIOS. Sometimes it can be used to boot from any SCSI device and sometimes it can only boot from a limited number of SCSI devices. Often has an option to use LBA addressing instead of CHS addressing. Remember changing this option after placing initial partitions on a disk may render your disk unusable until you reformat the device.

 

3. Partitions
1. MBR - Master Boot Record - a sector or few sectors starting at sector 0 which is used to manage the partition table. It also may contain additional code necessary to aid the bootload process (OnTrack DiskManager, etc.)

 

2. Partitions
1. Primary - up to 4 per disk. May be (un)bootable.
2. Extended - 1 per disk. Used as a container for partition tables of Logical Volumes
3. Logical - A partition which is unknown to the MBR, but is known to an extended partition. (Only a few OSs (includes Linux) can boot from a logical partition.

 

3. How many do I need? In theory one partition may be sufficient to run Linux. Practically however, at least two partitions are usually required (one for swap and one for /). Larger systems often have five or more partitions.

 

4. Where should they reside? The root partition should reside entirely within the first 1023 cylinders of the disk. Many BIOS implementations only allow booting from the first two hard disks. All other partitions may reside anywhere on any disk. There are all sorts of theories regarding placement of "swap" and "root" partitions. Some say these should be located near the center of the disk to minimize seek time, others say these should be located near the outside of the disk to maximize the number of sectors in a cylinder. Unless you have an extremely heavily loaded system, these arguments are of little consequence.

 

5. How big should they be? See your installation documentation for recommendations. Be sure to leave plenty of growth space in /tmp, /var/spool, /home, /opt, and /usr (if you plan to add additional software components). A general rule of thumb for swap partitions is (physical memory * 2).

 

6. Alignment Issues. Many OSs require that partition begin/end on cylinder boundaries. It is good practice to adhere to this standard. A few wasted sectors now can save hours of save/delete/create/restore later.

 

7. Partition Types. Partition types are used to help the various operating systems identify those partitions which they should manage. Currently Linux used 0x83 to identify a native Linux partition and 0x82 to identify a swap partition. Be sure to remember the partition types does not identify the type of filesystem used to manage the partition.

 

8. Beware of Win95. This is a friendly word to the unsuspecting. The installation of Windows 95 destroys the contents of the MBR. You will need to use loadlin, or boot diskettes to recover from Microsoft's arrogance.

 

9. Useful Utilities
1. fdisk (DOS). This is a Microsoft utility which deals only with DOS partitions. It is unusable for use in defining partitions for Linux.

 

2. fdisk (Linux) This is a utility for adding/deleting partitions. It supports partitions used by Linux and a multitule of other operating systems. It is command line driven with some rather cryptic user interaction. It can be used to add/delete/modify paritions on a disk. It can also set the "TYPE" of the partition and mark certain partitions as "Active" (which means the BIOS should boot from this partition. Note that a mistake using this utility is usually catastrophic. Be sure to make backups of any/all crucial data before beginning. Newer versions allow for units of measure other than sectors (MB and/or cylinders). Note that this program does not create a file system on partitions.

 

3. cfdisk (Linux) This is a graphical front end to the fdisk utility. One nice feature is the showing of all current information and the amount and location of available free space remaining on the disk. It is more menu driven than is fdisk and therefore less error prone. The same warning regarding mistakes while using fdisk are applicable here.

 

4. Partition Magic. This is a utility which can change the size of an "allocation unit" for a FAT (DOS) based file system. It can also be used to modify the size (increase or decrease) the size of a FAT table. While this utility has been found to be highly reliable, prudence dictates backing up any crucial data. This utility comes in several flavors to allow for running under the many Microsoft operating systems.

 

5. FIPS. A freeware utility used to accomplish the same thing as Partition Magic. However, it does not modify the allocation units setting in a FAT filesystem.

 

4. File Systems
1. Linux Native. Type 0x83. They can reside upon any disk. They may or may not have an filesystem installed on them. Creation of this filesystem require mkfs. Arguments are usually 1) device name, 2) number of blocks, and 3) number of inodes. Note that Linux by default reserves 5% of the filesystem for the exclusive use of the superuser. This allows for emergency repairs on a "full" filesystem.

 

2. Linux Swap. Type 0x82. They can reside upon any disk. They do not have a filesystem installed on them. Swapon requires a magic number in the first bytes in order for Linux to accept them for usage. Under extreme circumstances, one can use this space for Windows swap space, but this is HIGHLY discouraged.

 

3. ISO9660. A filesystem used extensively by CD-ROMs. The Rock Ridge extensions allow for conversion of long file names to the 8.3 convention of MS-DOS. Supported by a multitude of operating systems.

 

4. FAT based file systems
1. MS-DOS. The filesystem defined by Microsoft and used by MS-DOS.
2. UMS-DOS. A filesystem which allows for UNIX files to be stored withing a MS-DOS filesystem.

 

5. VFAT. The filesystem used by Windows 95. It is basically an extension to the MS-DOS filesystem which allows for long file names and eases the alpha-numeric restrictions on file names.

 

6. System V. The file system defined by AT&T in the SVID (System V Interface Document)

 

7. HPFS. The file system supported by IBMs OS/2.

 

8. NFS. The Network File System is a file system that physically resides on another machine which is mounted locally and accessed via the network.

 

9. Netware. The file system used by Novell Netware and accessed from Linux. Caldera has developed and released into the public domain utilities and administration tools necessary to access and administer Netware file and print sharing services.

 

10. Samba - A set of utilities and assorted other software which allows Linux machines to participate in Microsoft "Share" networks. It allows for peer-to-peer file and print services.
5. Booting Your System

 



 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1. LILO - A package which provides a bootload facility for Linux and other operating systems. Its primary components are 1) a configuration file 2) an configuration program and 3) the bootloading program.

Some interesting entries in the /etc/lilo.conf file are:

BOOT = The location where the bootstrap loader and configuration information should be written. If not specified the current / partition is used as default.

COMPACT = Tries to merge read requests for adjacent sectors into a single read request. This drastically reduces load time and keeps the map smaller. Using COMPACT is especially recommended when bootingh from a floppy disk. COMPACT may cause conflicts with the use of the LINEAR option.

DEFAULT = The image to be used as the boot image if the operator does not choose another.

delay = Specified the numbefr of tenths of a second LILO should wait before booting the first image.

DISK = Defines any non-standard disk paramaters (I/O Address, Geometry).

INSTALL = Install the specified file as the new boot sector. If INSTALL is omitted, then /boot/boot.b is used as the default.

LINEAR = Generate linear sector addresses instead of sector/head/cylinder addresses. Make sure your BIOS setting agrees with the use of this option.

MAP= Specified the location of the map file. If MAP is omitted, a file /boot/map is used.

MESSAGE= A file containing a message to be displayed before outputting the LILO prompt. This file is limited to 65K in length.

PASSWORD = Requires the operator to enter a password before the boot process will continue.

 

A sample lilo.conf file follows:

#

# general section

#

boot = /dev/sdb1

install =/boot/boot.b

message = /boot/message

prompt

 

# wait 20 seconds (200 10ths) for user to select the entry

timeout = 200

 

#

# default entry

#

 

image = /vmlinuz

label = linux

root = /dev/sdb1

read-only

 

#

# additional entries

#

image = /vmlinuz.960505

label = OldLinux

root = /dev/sdb1

read-only

 

 

 

2. Loadlin - A DOS package which provides a bootload facility for Linux. It allows a user in the DOS operating system to execute the Linux operating system. (Un)fortunately, it does not return control to DOS without a complete reboot. Can be made to boot from a diskette with only DOS and config.sys. It can also be run as a DOS executable called by a DOS batch file. I have successfully used it from Windows 95 by shutting down to DOS mode and executing a .bat file. It is perhaps safer than Loadlin for beginners. It can have problems when used in Virtual-86 mode (which is normal when using EMS drivers) if a VCPI server is present. The documentation is far easier to understand than the documentation for LILO.

 

3. Boot/Root Disks (Plus Utility Disks) - A bootload program, Linux kernel, and minimal operating system can be placed on diskettes. From these diskettes the user can 1) start a complete version of Linux running entirely from diskettes or 2) start a complete version of Linux running from the hard disk. Can be used to bootload Linux located on the disk, or can be used to recover from hardware/software/configuration errors. Some distributions include these disks other provide macros to generate these diskettes. Still other distributiions and special circumstances require the systems administrator to custom make their own. Note: Remember that is is easy to exceed the inode limit on a default floppy file system.

 

6. Useful Utilities
1. System Commander - A program from V Communications which allows for booting Linux, DOS, Windows 95, Windows NT, Novell NetWare ,OS/2, Coherent, SCO, Novell Unixware and Solaris from a multitude of disk devices. It also allows for multiple copies of different versions of the same operating system to co-exist on the same disk drives. 1-408-296-4224.

 

2. Partition Magic - A program from PowerQuest Corporation which allows FAT based filesystems to be expanded or contracted. It also allows for the "allocation unit" to be modified to maximize disk utilitization. 1-800-379-2566.

 

7. How many paritions?
1. How are you going to use your system?
1. News Server
2. Database Server
3. Timesharing
4. Web Server
5. ISP
6. Firewall
7. Router
8. Application Development
9. Turnkey (vertical) application
2. Recovery strategies
3. Backup strategies
4. Different types of file systems
1. Large vs. Small block sizes
2. Journaling
3. Mirroring or Raid considerations
4. Volume Manager (MD)

e. One suggestion

/ 30M

usr 300M

var 100M

root 100M

tmp 100M

home 200M

swap 32M

8. Placement of partitions.
1. One theory says place swap near the center of the device.
2. Another theory says place swap near the exterior of the device since there are more sectors per track located there.
3. Another theory says swap doesn't matter, for if you are placing much of a load on the swap partition, then you should be buying more RAM.ZipZip
4. First try to spread heavily accessed paritions on differring devices. Then try to place the heavily used partitions on a device next to each other starting from the outside.
5. Example:

First Disk Second Disk Third Disk

1 2 3

6 5 4

7 8 9

Acknowledgements:

Much of the information for this presentation was taken verbatim from the following sources:

1. "Linux System Administrators Guide 0.3" by Lars Wirzenius, Published August 6, 1995.
2. PC Magazine, Vol. 14 No. 13 "Inside the Perfect Hard Disk" by Leon Erlanger, Published July 1995 by Ziff-Davis Publishing Company LP.
3. Byte , Vol. 19. No. 3 "IDE Takes Off" by John Bryan, Published March 1994 by McGraw Hill Inc.
4. Byte, Vol. 19. No. 3 "SCSI vs. IDE" by John Bryan, Published March 1994 by McGraw Hill Inc.
5. Byte, Vol. 21. Number 10. "CDs for the Gigabyte Era" by Tom R. Halfhill, Published October 1996 by McGraw Hill Inc.
6. System Commander Published October 1995 by V Communications, Inc.