NAME

disk − random access bulk storage

DESCRIPTION

The secondary storage devices used by the system are media such as fixed disks and diskettes.  Disks are high-speed rotating magnetic media.  There are several platters in a fixed disk and one in a diskette.  Each platter provides up to two surfaces on which data can be stored; on each such surface, data is written in concentric rings known as tracks. Each set of parallel tracks on all the usable surfaces of a drive is considered to be a cylinder. Each track is divided into several sectors, each of which can hold the same number of data bytes (frequently 512). A sector is usually the smallest unit which can be transferred to or from the disk when using the raw disk devices.  However, the system allows read or write operations of any size to or from any location on the disk when using the buffered disk devices.  The special files for raw (unbuffered) disk devices are found in the directory /dev/rdsk, and the special files for the buffered disk devices are found in the directory /dev/dsk. 

High Performance Device Driver

Access to all fixed disk devices under the INTERACTIVE UNIX Operating System is provided by the High Performance Device Driver (HPDD).  This is a collection of routines that implements the kernel’s standard block device entry points.  Actual access to various types of disks and controllers is handled by a set of low-level driver modules, one for each distinct type of controller.  Low-level driver modules exist for AT-compatible fixed disk controllers, PS/2 Model 80 ESDI and ST-506 controllers, several SCSI host adapters, and for a RAM disk.  The low-level modules are responsible for initializing a particular type of controller and providing information as to the disks attached to it, performing read and write operations given physical sector and memory addresses, and handling controller-specific details of certain ioctl operations.  The HPDD is responsible for all request scheduling, bad-block mapping, virtual address translation, error reporting, and management of fixed disk partitions.  It also adjusts the manner in which I/O requests are presented to low-level modules based on the capabilities of the underlying hardware.  For example, it is possible to cause the HPDD to not generate low-level transfer requests that span multiple cylinders or more than a certain number of sectors, or to cause it to make explicit seek requests, as required. 

The low-level modules supported in a given system, as well as the mapping of device special files to physical disks, is specified when the system kernel is configured.  Up to 32 devices can be supported on as many adapters as the hardware will support.  See the section “High Performance Device Drivers” in the “INTERACTIVE UNIX Operating System Maintenance Procedures” for more information. 

Logical Disks

It is often useful to partition fixed physical disks into smaller sections, each of which may (although it need not) contain a UNIX System file system. A file system is a collection of data structures on the disk created by the mkfs(1M) program and used by the UNIX System to store user files.  The disk device driver can divide a physical disk into smaller logical disks or partitions. The partitioning occurs at two levels. The BIOS provides for up to four distinct operating system partitions and records this in the first sector on the disk in the fdisk table.  The HPDD can provide access to any of these partitions and can also further divide the UNIX Operating System’s partition.  The partitions are defined during system installation (for the primary drive) or when an additional drive is first added to the system.  See the section “Adding a Second Fixed Disk” in the “INTERACTIVE UNIX Operating System Installation Instructions” for information. 

Diskettes are not partitioned as are fixed disks.  There are up to four available “partitions” on each diskette.  The first of these spans the entire diskette.  The second specifies all but the first cylinder.  The third covers all but the first two cylinders.  The fourth is undefined.  Normally, the full diskette is used for data storage.  This may be unstructured (as in a cpio(1) file) or may contain a file system.  The second and third forms are used primarily for bootable diskettes, where the system bootstrap program is written in the first and second cylinders and the root file system is contained in the remainder of the diskette. 

Disk Device Special Files

Each fixed disk partition has a specific device special file associated with it.  There are rigid rules for the construction of their names. 

There are two sets of rules for device name construction.  The set used depends on the type of pseudo device the real device is connected to. 

If the connection is to a target pseudo device, for example dsk0t, the device names are of the forms citjpk and citjsk, where i is the (0-based) controller number (0 in this case, because dsk0t is being used), j is the (0-based) target on the designated controller, and k is the partition number (0-f) on that drive. 

If the connection is to a logical unit number (LUN) pseudo device, for example dsk32, the device names are of the forms citjlk p m and citlkj s m, where i is the (0-based) controller number (3 in this case, because dsk32 is being used), j is the (0-based) target number on the controller (2 in this case, because dsk32 is being used), k is the (0-based) LUN on the designated target on the designated controller, and m is the partition number (0-f) on that drive. 

When a LUN pseudo device is being used, the first device on the designated target will have two names, the LUN-based name and the target-based name.  This is because the target interface will always access the first LUN on any target. 

Partition names with a p indicate fdisk table partitions, while s partitions are UNIX System sub-partitions.  For drives on the primary controller, the c0t portion of the name is dropped, yielding a name like 0s1 for the root file system’s partition.  Thus, the special file for the fourth partition on the third target attached to the second controller on the system would be /dev/[r]dsk/c1t2s3 (remember all numbers are 0-based).  If the third target had LUNs connected, the partition in question could also be accessed as /dev/[r]dsk/c1t2l0s3.  Partition p0 always describes the entire physical disk; s0 is the entire UNIX System portion. 

The device special file names for diskettes also follow rigid naming conventions.  These names are of the form fi{dq}j{sd}[t|b] where i is the (0-based) number of the diskette (floppy) drive, d indicates a double-density diskette, and q indicates a quad- (high-) density diskette (either d or q must be present) having j sectors per track.  s indicates a single-sided diskette and d indicates a double-sided diskette (either s or d must be present); t (if present) indicates the entire (or total) diskette.  Names not ending in t indicate all but the first cylinder; names ending with a b do not include the first two cylinders.  Thus, the special file /dev/rdsk/f0q15dt refers to all of a high density dual-sided 5 ¼-inch diskette in the first drive accessed in unbuffered (raw) mode, and /dev/dsk/f1q18d refers to the file system portion of a bootable high density dual-sided 3 ½-inch diskette in the second drive accessed in buffered mode. 

Bad Sector Re-mapping

NOTE: Bad sector re-mapping is not supported on diskettes. 

Information recorded on fixed disk drives is stored in the form of tiny magnetic domains in an oxide coating on each surface of the disk.  Since this coating is applied mechanically, certain areas of the coating may be flawed.  Data recorded in a flawed area may be read incorrectly.  Several techniques are used to minimize the effects of such surface defects.  The sector headers written at low-level format time, which contain information about the address (cylinder, head, and sector number) of each sector on the disk, contain Cyclic Redundancy Check (CRC) values.  These are recomputed when the headers are read.  If the computed value fails to match the read value, some number of data bits in the header are known to be incorrect.  In addition, the data portion of each sector contains either a CRC or an Error Correcting Code (ECC).  In addition to spotting defective data, an ECC can also be used to correct some number of erroneous data bits.  Thus, by writing and reading all the sectors of a disk prior to storing actual data on it, those sectors that do not reliably hold the recorded data can be found.  This process is known as surface analysis.

In addition to these hard errors (defects that always cause data transfer failures), soft defects may also exist.  These are areas of the disk that may hold data for some period of time, but cannot be depended on for long periods or under marginal electrical conditions.  These defects are far less common in practice than hard errors, but they are considerably more difficult to locate. 

Drive manufacturers rigorously test their drives under forced marginal conditions for long periods of time.  Any areas that are defective are marked in a Manufacturer’s Defect List which is shipped with the drive (in hardcopy form) and may also be recorded in a known area on the drive.  During initialization of a fixed disk under the UNIX Operating System, an attempt is made to provide the system with a logically-contiguous set of sectors that can be considered to be error-free.  This is done by noting defective sectors and providing an alternative good sector for each one found to be bad.  This process is known as bad sector re-mapping, and it is performed in different ways depending on the type of drive and controller being used. 

First, the drive may be formatted.  This process rewrites all the sector headers and sets all the data fields to known values.  Formatting the drive will reinforce any header data that had been weakened by shock or exposure to magnetic fields during shipment of the drive.  In addition, some controllers (like those for SCSI disks) will actually read the manufacturer’s defect list and perform bad sector re-mapping on their own.  By doing this, they eliminate all defective (or marginal) sectors known to exist when the drive was built.  Other manufacturers format their drives in such a way that an extra sector is present in each track.  This sector (which is not normally accessible) is given the address of any other sector in the track that is found to be defective.  Thus, only a track with more than one defect (very rare) will actually exhibit a defect when the normally-available sectors are used.  This is known as sector slipping. 

Second, a partial (read-only) or complete (write all, then read) surface analysis is performed.  This is done with controller retries and error correction disabled (if possible, depending on the controller) so that soft errors will be detected.  All defective sectors located during surface analysis are noted.

Third, the user is asked to enter any known defects.  This can be from a printed manufacturer’s defect list (unless such defects are handled by the controller as described above) or those found during normal system operation.  All the defects obtained from these latter two sources are entered in an alternate-sectors table stored on the drive.  For each possible entry in the alternates table, a spare sector is reserved (and verified to be good).  Any sector listed as bad in the alternates table will not be used.  Routines in the HPDD will re-direct requests for such sectors to their good alternates.  This is done transparently to the operating system. 

If a latent defect emerges during the running of the system (a very rare event, in practice), the −A option of mkpart(1) can be used to add them to the alternates table after the system has been installed and is running.  The data that had been in the sector that is re-assigned in this manner is lost.  This may mean that from a sector’s worth of data in a file up to an entire file system may be corrupted, depending on the location of the defective sector in the file system.

The software bad sector re-mapping scheme is enabled on a per-partition basis.  Partitions 0 (the entire UNIX System partition) and any MS-DOS (DOS) partitions (p0−p4) are exempt from re-mapping. 

Fixed Disk Layout

The first sector of the disk (sector 0) consists of a data structure called the fdisk table.  The fdisk table describes the partitions on the fixed disk.  fdisk partitions should not be confused with UNIX System partitions.  fdisk partitions describe entire operating system areas that may reside on the disk, e.g., UNIX, DOS, and OS/2. 

A total of four physical partitions can be described.  At least one of the partitions must describe a UNIX System partition.  The fdisk partition structure and fdisk table look like:

/∗
* structure to hold the fdisk partition table
∗/
struct ipart{
unsigned char bootid;/∗ bootable or not ∗/
unsigned char beghead;/∗ beginning head, sector, cylinder ∗/
unsigned char begsect;/∗ begcyl is a 10-bit number ∗/
unsigned char begcyl;  /∗ high 2 bits are in begsect ∗/
unsigned char systid;/∗ OS type ∗/
unsigned char endhead;/∗ ending head, sector, cylinder ∗/
unsigned char endsect;/∗ endcyl is a 10-bit number ∗/
unsigned char endcyl;  /∗ high 2 bits are in endsect ∗/
long reselect;/∗ first sector relative to start of disk ∗/
long numsect;/∗ number of sectors in partition ∗/
};
/∗ Fdisk Structure
* structure to hold master boot block in physical sector 0 of the disk
* note that partitions structure can’t be directly included in the structure
* due to 386 compiler alignment design
∗/
struct mboot {/∗ master boot block ∗/
charbootinst [BOOTSZ];
charparts [FD_NUMPART * sizeof (struct ipart)];
ushort signature;
};

The relsect field of the table entry points to the start of the fdisk partition.  At least one of the partitions must describe a UNIX System ­partition. 

Inside the UNIX partition at logical sector 29 is the UNIX System pdinfo table.  The pdinfo table points to both the VTOC and the alts_table. Usually, the pdinfo and VTOC are in the same sector, and the alts_table is in the following sector.  The alts_table is included for backward compatibility and is used only in the absence of an ALTSCTR partition (see mkpart(1M)).

The VTOC can describe up to 16 UNIX System partitions.  See /usr/include/sys/vtoc.h for a description of these partitions. 

Ioctl Calls Supported

All the standard disk ioctl calls defined in the file /usr/include/sys/vtoc.h are supported for all disk devices.  In addition, each low-level driver module may support controller-specific ioctls. See the low-level module descriptions for details.  The standard calls supported are:

V_CONFIG This call is used by mkpart to reconfigure the drive, so that the drive configuration matches the parameters specified in the /etc/partitions file.  The argument to the ioctl is the address of one of the following structures, defined in <sys/vtoc.h>, containing the new configuration parameters:

union io_arg {
struct {
ushortncyl;/∗ number of cylinders ∗/
uncharnhead;/∗ heads/cylinder ∗/
uncharnsec;/∗ sectors/track ∗/
ushortsecsiz;/∗ bytes/sector ∗/
} ia_cd;
}

Note that it is not possible to change the sector size on a fixed disk, and that an attempt to do so will result in the ioctl failing, with errno set to EINVAL. 

V_REMOUNT
This call is used to force the driver to re-read the VTOC on the next open of the drive.   It will fail if any partition other than partition 0 is currently open, since changing the partition table information is potentially disastrous for a process using the partition.  This is used by mkpart when it changes the VTOC, so that the driver will update its internal tables. 

V_XGETPARMS
This call is used to get information about the current drive configuration. The argument to the ioctl is the address of one of the following structures, defined in <sys/vtoc.h>, which will be filled in by the ioctl:

struct  disk_xparms {
chardpx_type;/∗ Disk type (see below) ∗/
ulongdpx_heads;/∗ Number of heads ∗/
ulongdpx_cyls;/∗ Number of cylinders ∗/
ulongdpx_sectors;/∗ Number of sectors/track ∗/
ulongdpx_secsiz;/∗ Number of bytes/sector ∗/
/∗ for this partition: ∗/
ushortdpx_ptag;/∗ Partition tag ∗/
ushortdpx_pflag;/∗ Partition flag ∗/
union{/∗ value depends on partition # ∗/
struct  {/∗ returned for partition 0: ∗/
ulong dp0_secovhd;/∗ Controller’s per-sector overhead ∗/
ulong dp0_rsrvdcyls;/∗ # of reserved cylinders from total ∗/
ulong dp0_intlv;/∗ Interleave factor (0 if unknown) ∗/
ulong dp0_skew;/∗ Sector skew factor (per head) ∗/
/∗ Meaningful only if dp0_intlv == 1 ∗/
/∗ If intlv == 1 & skew == 0, unknown ∗/
ulong dp0_ctlflags;/∗ Controller-specific flags ∗/
ulong dp0_pheads;/∗ Physical heads ∗/
ulong dp0_pcyls;/∗ Physical cylinders ∗/
ulong dp0_psectors;/∗ Physical sectors/track ∗/
ulong dp0_psecsiz;/∗ Physical bytes/sector ∗/
    } dp0_ctl;
daddr_t dp1_pstartsec; /∗ returned for any other partition ∗/
} dpx_psense;
daddr_t dpx_pnumsec;/∗ Number of sectors ∗/
};
/∗ Disk types ∗/
#defineDPT_WINI1/∗ Winchester disk ∗/
#defineDPT_FLOPPY2/∗ Floppy ∗/
#defineDPT_OTHER3/∗ Other type of disk ∗/
#defineDPT_NOTDISK0/∗ Not a disk device ∗/
/∗ Partition identification tags ∗/
#defineV_UNUSED0x00/∗ Unused partition ∗/
#defineV_BOOT0x01/∗ Boot partition ∗/
#defineV_ROOT0x02/∗ Root filesystem ∗/
#defineV_SWAP0x03/∗ Swap filesystem ∗/
#defineV_USR0x04/∗ Usr filesystem ∗/
#defineV_BACKUP0x05/∗ full disk ∗/
#defineV_ALTS0x06/∗ alternate sector space ∗/
#defineV_OTHER0x07/∗ non-unix space ∗/
#defineV_ALTTRK0x08/∗ alternate track space ∗/
#defineV_ALTSCTR0x09/∗ alternate sector partition ∗/
/∗ Partition flag ∗/
#defineV_UNMNT0x001/∗ unmountable partition ∗/
#defineV_RONLY0x010/∗ read only partition ∗/
#defineV_OPEN0x100/∗ partition open ∗/
#defineV_VALID0x200/∗ partition valid to use ∗/

For the fixed disk driver, the disk type will always be DPT_WINI.  Since the structure returned by V_XGETPARMS is the same for both the diskette and fixed disk drivers, programs may be written to understand either one. 

V_FORMAT
This call is used to format tracks on a disk. The argument passed to the ioctl is the address of one of the following structures, defined in <sys/vtoc.h>, containing the starting track, number of tracks, and interleave factor:

union io_arg {
struct {
ushortstart_trk;/∗ first track ∗/
ushortnum_trks;/∗ number of tracks to format ∗/
ushortintlv;/∗ interleave factor ∗/
} ia_fmt;
}

Note that the file descriptor argument to the ioctl must refer to the character (raw) special device for the desired drive, and the file must have been opened in exclusive mode, i.e., O_EXCL. 

Also note that a drive will only accept one of either V_FORMAT or V_FMTDRV (see next paragraph), depending on the capabilities of the controller.  Typically, SCSI disks require V_FMTDRV, while MFM, RLL, and ESDI controllers need V_FORMAT. 

V_FMTDRV
This call is used to format the entire disk. The argument passed to the ioctl is the desired interleave factor. 

Note that the file descriptor argument to the ioctl must refer to the character (raw) special device for the desired drive, and the file must have been opened in exclusive mode, i.e., O_EXCL. 

V_PDLOC
This call is used to return the starting sector number of the pdinfo structure.  This information is passed back in the return argument as arg.

V_RETRYCTL
This call is used to direct the driver to turn retry and error correction logic on or off. The argument passed will be one of:

V_RETRY_ON/∗ turn retry/error correction on */
V_RETRY_OFF/∗ turn retry/error correction off */

For each disk device, the initial state for this flag is on.

Configuration Parameters

The configuration parameters are found in the cf.d/mtune file.  The parameters that apply to the HPDD are:

Error Messages

The HPDD has a well-defined set of error conditions.  Each of the low-level drivers is responsible for translating its error conditions into the appropriate HPDD error condition.  The normal course of action taken for errors is to retry the operation if the controller is set up for retrys.  If the operation succeeds upon retry, then no error is reported.  If after 10 retrys the operation still fails, then an error message is printed on the console.  The possible error messages are:

SEE ALSO

fdisk(1M), mkfs(1M), mkpart(1M), mount(1M), intro(7). 
ioctl(2) in the INTERACTIVE SDS Guide and Programmer’s Reference Manual.
“INTERACTIVE UNIX Operating System Maintenance Procedures” and “INTERACTIVE UNIX Operating System Installation Instructions” in the INTERACTIVE UNIX Operating System Guide.

ADDED VALUE

This entry, supplied by INTERACTIVE Systems Corporation, contains enhancements to UNIX System V. 

\*U  —  Version 1.0