The [v]fstab file is used to mount file systems at boot time.
The “v” is bracketed, as some versions of UNIX call this file /etc/fstab (primarily BSD UNIX), other versions of UNIX call this file /etc/vfstab (primarily System V UNIX), and a few versions of UNIX call this file /etc/checktab (HP/UX).
This file is read by the /etc/mountall command when it is run as part of the system boot sequence.
A quick way to add items to [ v]fstab is to use the - p option to the mount command.
It is also possible to add new file systems by editing the [v]fstab file and entering the required information manually.
The [v]fstab file format may contain minor modifications on different variants of UNIX,.
The Volume Manager provides users with a means of mounting/unmounting removable media without granting system users root privileges typically required to mount/unmount a file system.
Under Linux, you can add the “user” option to the list of options for a file system. This allows any user to mount/unmount the file system (an operation that usually requires root access).
For example, the following fstab entry would allow any user to mount the /jaz file system located on the removable disk /dev/sda1 . The nosuid option disallows execution of suid programs from this medium.
The mount command allows the administrator to view which file systems are mounted, as well as providing a method of mounting file systems. When invoked without arguments, the mount command lists mounted file systems by their mount points, showing the device mounted at each mount point, the mount options used, and the time the file system was mounted.
/ on /dev/dsk/c0t3d0s0 read/write/setuid on Sat Apr 1 1:23:45 2000
/usr on /dev/dsk/c0t3d0s6 read/write/setuid on Sat Apr 1 1:23:45 2000
/proc on /proc read/write/setuid on Sat Apr 1 1:23:45 2000
/dev/fd on fd read/write/setuid on Sat Apr 1 1:23:45 2000
/tmp on swap read/write on Sat Apr 1 1:23:45 2000
/opt on /dev/dsk/c0t3d0s5 setuid/read/write on Sat Apr 1 1:23:45 2000
Adding entries to the Solaris vfstab file works well for hard disks but is not suitable for removable media such as floppies and CD-ROMs.
These devices tend to be mounted and unmounted much more frequently than hard disks, and the user performing this “mount” operation may not have the root privileges required to mount a normal file system.
To handle such situations, Solaris uses the Volume Manager.
Volume Manager is also able to handle file system types other than ufs .
For instance, inserting an MS-DOS-formatted floppy and using File Manager or the volcheck command results in the disk being mounted under the /floppy directory on a mount point that bears the floppy volume name.
Starting and Stopping Volume Manager
UNIX makes it possible to disable Volume Manager and work directly with the CD-ROM and/or floppy drive.
To disable Volume Manager, invoke the /etc/init.d/volmgt script with the stop option.
To restart Volume Manager, invoke the /etc/init.d/volmgt script with the start option.
Hard errors are typically caused by head crashes, cabling problems, or electronics failures
WARNING: Whenever a fatal disk error is reported, the administrator should be very concerned about the integrity of the files on the disk drive. Steps must be taken to rectify the problem immediately, or data may be destroyed.
Perform a full backup of the failing disk, or better yet, the entire system.
Reboot the system to determine if the failure is due to corrupted system information.
If the block number of a bad spot is known, use the system’s format utility to map out the spot on the drive.
If there are several bad spots on the drive, use the surface verification portion of the format utility to perform nondestructive surface analysis of the drive to search for and optionally repair bad spots.
Replace the drive with a known good drive. Copy all data to the new drive. Note that this option can be time consuming and expensive.
Optimize file systems across multiple spindles and controllers.
Optimize file system structures for the type of files to be stored on the file system.
The default newfs settings are good for general purpose file systems. But they are also very inefficient for certain types of applications.
File systems containing primarily large files require fewer inodes. This leads to a lot of lost space.
File systems containing primarily small files require more inodes. This leads to a problem where there is space left on the device, but no file system structures are available to address the unused space!
File system tuning can provide only limited performance improvements.
Performance tuning is critical to the first type (active files), and probably not very important for the archive server.
In most instances, disk farms are set up to provide high-speed access to important data. Typical applications include database systems, medical images, and other space-intensive information services.
In a few instances, the disk farm is used for long-term archival storage. Because the information on these systems is not accessed very often, high performance is not always the driving criterion in file system tuning.
Although tunefs is capable of changing many characteristics of the disk subsystem, it is not a do-all/save-all I/O subsystem fix-it tool.
The tunefs command allows you to “tune” file system parameters as you build a file system (more/less inodes, more/less free space, …).
Tuning for Special Disks and Disk Controllers
By default, newfs uses the information in the disk label to calculate several factors related to the ability of the disk, controller, and CPU to read or write information. As the disk rotates, each block in the track moves past the disk heads. If the controller and CPU are fast enough, blocks may be written or read in the order they come under the heads.
Slower controller/CPU combinations must skip one or more blocks between read/writes to keep up with the I/O demands of the system. The newfs and tunefs commands allow the rotational interleave aspect of the file system to be adjusted by calculating the required time for a single block read to be processed.
Some disk controllers are capable of writing or reading multiple blocks in a single operation due to high-speed buffer memory located in the controller.
Applications that consistently read and write very small (or very large) files can often benefit from file system tuning.
Large files are often split between cylinder groups. A cylinder group is a collection of cylinders used by the disk I/O routines in the kernel to improve disk performance by grouping a file’s data blocks close together on the disk.
When a large file is split over two or more cylinder groups, the file’s data blocks are spread across the disk. Consequently, extra seek time is required.
Adjusting the maximum number of blocks that can be allocated to a single file within a cylinder group may help reduce this problem.
It is also possible to adjust basic allocation block and fragment sizes on the file system.
Larger allocation block and fragment sizes favor large files by reducing the time required for file allocation at the expense of reduced space efficiency.
If an application stores small files (exclusively), a smaller allocation block will improve speed, and a smaller fragment size will improve space utilization efficiency by avoiding the allocation of blocks that are much larger than the data to be stored.
The disk storage routines in the UNIX kernel have two strategies available for disk allocation: time and space.
Time efficiency refers to the time required to allocate space and write files. Optimizing time is wasteful of space because transfers often result in gaps being created in lieu of long, continuous disk writes.
Space efficiency refers to the efficient use of scattered blocks on the disk. Optimizing space wastes time because a file is allocated to blocks scattered around the disk, and the disk heads must move more frequently to read or write a file.