Managing Disk-Based File Systems
Disk-based file systems are the most commonly used type of file systems in Solaris. So although the other types are important, especially distributed file systems in a networked environment, this section concentrates on creating and managing disk-based file systems.
Earlier in this chapter, four local file system types were introduced: UFS, HSFS, PCFS, and UDF. Of the four, UFS is the most critical and widely used. Accordingly, it gets the most coverage in this chapter.
The UNIX File System (UFS)
The UNIX File System (UFS) is the default file system for hard disks in a Solaris environment. In fact, if you are working on a hard disk, it's a safe assumption that the disk is using UFS to store files. UFS has quite a few features that enable it to be a flexible file system.
One of the most important features of UFS is the state flag. Each UFS entity has its own flag to show the status of the file system. The state flags can be clean, stable, active, logging, bad, or unknown. If clean, stable, or logging, then no file system checks are needed. However, if the file system is in another state, system checks can be performed, and the file system repaired if needed.
Other UFS features include support of large file systems (up to 1 terabyte), support for large files (more than 2 gigabytes), and support for 32-bit User ID (UID), Group ID (GID), and device numbers.
UFS reads and writes are stable because UFS can be configured to log transactions before applying them. If the file system were to unexpectedly crash during a disk read or write, the saved log file could be accessed to complete the operation upon reboot. Logging improves file system consistency, and during peak read/write times, can also improve disk I/O performance.
UFS logging is not enabled by default. To enable logging, use the -o logging argument with the mount command. More on the mount command later in this chapter.
UFS Planning
Before creating file systems, plan their usage according to your anticipated needs. If you expect the file system to grow, allocate enough space to accommodate that growth. Planning ahead will save you from deleting and re-creating file systems after the computer is operational, which saves you downtime.
Here are some general guidelines to follow when planning UFS file systems:
-
Use as few file systems per disk as possible. Larger file systems tend to reduce file fragmentation, which speeds up disk I/O.
-
Distribute the workload among as many physical disks as possible.
-
Configure swap space to be evenly distributed among physical disks.
-
Consider creating separate file systems for users with specific needs. An example is users who need to store large files. If they have their own file system, they won't crowd out other users.
When creating UFS file systems, the maximum size is 1TB. Files can be as large as 800GB by default. Also, in case you've ever wondered, the maximum number of subdirectories allowed in one directory is limited to 32,767. Although it's an interesting statistic, you won't likely see it on the test or probably ever have to deal with it in real life.
Creating UFS File Systems
Your hard disk must be sliced and formatted before you create a file system. Typically, file systems are created after the hard disks are sliced and formatted during the Solaris installation process. However, if you are adding an additional hard disk, changing your existing partition structure, or performing a system restoration, you might need to manually create file systems. File systems are created with the newfs command.
| Note | The newfs command is used to create disk-based file systems. Creating virtual file systems is not performed with newfs. |
The newfs command is actually a front-end to the mkfs command. The newfs command is easier to use than mkfs and is therefore recommended. The syntax for using newfs is as follows:
# newfs arguments raw_device_name
where arguments enables you to customize the file system, and raw_device_name is the name of the device (slice) on which you wish to create this file system. When specifying the slice on which to create this file system, be sure to specify the right one. Creating a new file system destroys any existing data on the slice.
To create a file system on a hard disk, you must have superuser rights or be able to assume an equivalent role. Here are the steps to create a new file system:
-
Slice and format the hard disk. For information on these procedures, see Chapter 6.
-
Determine the disk and slice that will contain this file system.
Example: /dev/rdsk/c0t0d0s4
-
Create the file system by using newfs.
# newfs /dev/rdsk/c0t0d0s4
-
Verify the creation of the file system with the fsck command.
# fsck /dev/rdsk/c0t0d0s4
After creating the file system, you will need to mount it to make it available for file storage.
| Note | To create a local file system other than a UFS file system, you will need to use the mkfs -F FSType command, where FSType is the file system type (such as HSFS or PCFS) that you wish to create. |
Custom UFS File System Parameters
The newfs command uses default values for creating file systems. Among the default values are 8KB block size, 1KB fragment size, zero rotational delay, time as the optimization type, and one inode for each 2KB of data space. When creating a file system with newfs, you can customize these parameters to fit your needs:
Logical block size This is the block size that the Solaris kernel uses to read or write data. It differs from the physical block size, which is hardware dependent (and usually 512 bytes). Logical block sizes are typically 4KB or 8KB, with 8KB as the default. For file systems with large files, 8KB is more efficient. Likewise, file systems that typically store smaller files are more efficient with a 4KB block size. You cannot change block size within a file system without deleting and re-creating the file system. One physical hard disk can have multiple file systems with differing logical block sizes.
Fragment size For files that don't fit exactly into one logical block-and most don't-fragments are used to optimize space. Logical blocks are divided into one, two, four, or eight fragments. As an example, imagine a 9KB file. If you didn't use fragmentation, you would need two logical blocks (16KB total) to store the file, wasting 7KB in space. By using fragments, you can use one whole logical block, plus a 1KB fragment, and not waste any space.
The downside is that the more fragments you allocate and use, the slower your file system will become. Always remember to balance speed with space when optimizing file systems.
Minimum free space When you create a file system, a certain amount of space is held in reserve. This is because as file systems become full, they become less efficient. If the file system were to totally run out of space, disk reads and writes would become painfully slow.
By default, the reserved free space is between 1 and 10 percent of the total file system space, as determined by the following formula: [(64MB/partition size) × 100] rounded down to the nearest integer. After the file system fills up, only the superuser can write additional data into the reserved minimum free space.
Rotational delay Also known as gap, rotational delay is the expected minimum time in milliseconds that it takes the processor to complete a data transfer and initiate a new data transfer on the same hard disk. The default rotational delay is zero, because most current hard disks use caching, which essentially renders this option useless.
Optimization type You can set your file system to optimize for either space or time. If optimized for space, block fragments are utilized heavily. Time optimization results in slightly lower space efficiency but makes the file system as quick as possible.
Some people obsess over space versus time optimization. Realistically, though, you won't likely notice a great deal of difference either way on your computers. The tunefs command can be used to change your optimization type.
Number of bytes per inode Each file on your file system requires one inode. As you might remember from earlier in this chapter, inodes contain information about a file. By default, the file system uses 2048 bytes of storage space per inode for file systems 1GB or smaller, 4096 bytes per inode for file systems 2GB or smaller, 6144 bytes per node for file systems 3GB or smaller, and 8192 bytes per inode for file systems larger than 3GB.
Inodes take up space that would otherwise be reserved for file storage. Consequently, a large number of inodes can decrease storage space.
An abundance of small files and symbolic links can use up inodes quickly. If you run out of inodes, you will not be able to create additional files in that file system, even if space is available. Therefore, it's better to have too many inodes than not enough.
Note that because newfs generally does a good job on its own of setting up file systems, these customizations are not usually needed. The most commonly modified parameters are fragment size and number of blocks per inode. Table 7.2 lists some of the arguments for the newfs command.
| Argument | Description |
|---|---|
| -N | Prints the file system parameters that would be used to create the file system but does not actually create the file system |
| -b bsize | The logical block size, specified in bytes |
| -f fragsize | The fragment size, specified in bytes |
| -m free | The minimum percentage of reserved free disk space to allow |
| -i nbpi | The number of bits per inode to use when calculating how many inodes to create |
| -o opt | The optimization method to use: either space or time |
| -d gap | The expected rotational delay (not usually needed) |
Managing UFS File Systems
To effectively manage UFS file systems, you need to be familiar with the commands at your disposal. Some of the more useful commands are listed in Table 7.3.
| Command | Description |
|---|---|
| clri | Clears inodes. Useful for removing files that appear to have no directory home. |
| df | Displays the number of free disk blocks and files. |
| du | Shows disk usage. |
| ff | Lists filenames and statistics for file systems. |
| fsck | Checks file system integrity and repairs file system damage if possible. |
| fsdb | Debugs the file system. |
| fstyp | Displays the file system type for unmounted file systems. |
| labelit | Provides labels for file systems when they are copied to tape, or for unmounted disk file systems. |
| mkfs | Creates a new file system. |
| mount | Mounts local or remote file systems. |
| mountall | Mounts all file systems listed in the /etc/vfstab file. |
| umount | Unmounts local and remote file systems. |
| umountall | Unmounts all file systems listed in the /etc/vfstab file. |
| volcopy | Creates an image copy of a file system. |
Checking File System Consistency
One of UFS' responsibilities is to keep track of used and free data blocks as well as any inodes being used. If the computer's power is unexpectedly terminated or a fatal software error occurs, the UFS database can become misaligned with what's actually stored on the hard disk. In cases like this, it's said that the file system is inconsistent.
It's easy to imagine why this could be a serious problem. If the file system doesn't know where to properly locate your files, it could be a long, horrible day. The good news is that file system inconsistencies don't happen very often. Even if inconsistencies do happen, you might not realize it. By default, if the file system has problems, the fsck utility will check the file system during boot and repair all problems it finds.
If your file system is inconsistent, fsck will place all data blocks that don't appear to have a home (the proper directory) into a directory called lost+found. If your computer does not have a lost+found directory, fsck will create one automatically.
How does fsck know whether it needs to check a file system for inconsistencies? The superblock of the file system contains a state flag that displays the status of the file system. Possible values for state flags are FSACTIVE, FSBAD, FSCLEAN, FSSTABLE, and FSLOG. If the file system is FSACTIVE or FSBAD, fsck knows to check the file system. If no problems are found, or fsck can repair the problems, the file system status is changed to either FSCLEAN or FSSTABLE. The FSLOG status indicates that the file system was mounted with UFS logging enabled and is subsequently ignored by fsck.
Of course, if at any time you wish to run fsck manually, you can do so. Just be aware that it will slow down your computer considerably until it's done. Here's what a sample fsck output looks like, complete with an error message:
# fsck ** /dev/rdsk/c0t0d0s0 ** Currently Mounted on / ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups FILE SYSTEM STATE IN SUPERBLOCK IS WRONG; FIX? y 68781 files, 1683252 used, 332225 free (4441 frags, 40973 blocks, 0.2% fragmentation) FILE SYSTEM IS CURRENTLY MOUNTED. CONTINUE? y ** /dev/rdsk/c0t0d0s7 ** Currently Mounted on /export/home ** Phase 1 - Check Blocks and Sizes ** Phase 2 - Check Pathnames ** Phase 3 - Check Connectivity ** Phase 4 - Check Reference Counts ** Phase 5 - Check Cyl groups 188 files, 274 used, 16673240 free (400 frags, 2084105 blocks, 0.0% fragmentation) #
By fixing one problem, fsck might reveal a new problem. But because fsck does not rerun itself until all problems are fixed, you will need to run fsck again manually. Occasionally, you will encounter a problem that fsck cannot resolve. Other commands, including fsdb, ff, and clri, might help you determine the issue or resolve the problem. In the worst-case scenario, you will need to restore the file system from a tape backup.
Restoring a Bad Superblock
If the superblock becomes inaccessible, the file system is rendered useless. However, the superblock can be restored from backup copies located within the file system. The fsck -o b command will attempt to replace the superblock with one of the backups. If this fails, you will need to restore the file system from backup or create a new file system.
Monitoring File System Usage
The df, du, quot, and ls commands can be used to monitor file system usage. If you have one user or a few users abusing their disk space allocation, you can set up disk quotas.
To see how many 1024-byte blocks each user on the local file system is using, issue the quot -a command. Unfortunately, the quot command works only on local UFS file systems.
 |
A group of engineers at your company has been assigned to a critical research project. Because of the sensitivity and importance of the project, management has instructed you to create a slice on your Solaris server exclusively for the engineers' use. The engineers estimate that they will need approximately 1GB of storage space. You have some free space on a 40GB non-system disk, so you decide to create the slice there.
You execute the following command to create the file system on the 1GB partition:
# newfs -b 8192 -f 1024 -i 8192 -o space /dev/rdsk/c0t2d0s4
You mount the partition and verify that the engineers have access to the volume.
A few weeks later, one of the engineers calls, saying that they have run out of disk space and need you to increase the size of the partition. When you investigate, you discover that the file system still has nearly 40 percent of its total space available. What happened?
The file system has run out of inodes, meaning that no new files can be created in the file system. Perhaps this happened because of how you created the file system. Instead of allowing the default of 2KB per inode on a 1GB or smaller file system, you created a file system that allocated one inode per 8KB of disk space (with the -i 8192 option). Now the question becomes, what's the easiest way to fix this problem?
Make a backup of the data. You're going to need to delete this file system, re-create a new one, and then restore the original data to the new file system. This time, allow the default setting for bits per inode. Also, because you're re-creating this file system in the middle of the project, reconfirm disk space with the engineers. They might have discovered that they will need more disk space, and because you're re-creating anyway, asking now might save you extra work in the long run.
|
Mounting and Unmounting
To access files in a file system, you must mount the file system. The process of mounting a file system connects the file system with a directory in the hierarchical directory structure, known as a mount point. The root file system is always mounted by default and must be mounted in order to access any files on the computer.
Four commands that you will use for mounting and unmounting file systems are mount, mountall, umount, and umountall.
Generally speaking, mount point directories do not contain files. As an example, imagine that you are going to mount a custom file system called /workfile into the mount point /docs. After you mount /workfile, any files that were in the /docs directory will be obscured. No permanent damage is done to them. In fact, if you were to unmount /workfile, all the original files in /docs would be available again. It's just that when /workfile is mounted, you can't get to the original /docs files or subdirectories.
The /etc/mnttab (mount table) file keeps a record of all mounted file systems within your computer. You cannot edit this file because it's read-only, but you can display its contents:
# cat /etc/mnttab /dev/dsk/c0t0d0s0 / ufs rw,intr,largefiles, ... /proc /proc proc dev=3b40000 1031950360 mnttab /etc/mnttab mntfs dev=3c00000 1031950360 fd /dev/fd fd rw,suid,dev=3c40000 1031950362 swap /var/run tmpfs xattr,dev=1 1031950363 swap /tmp tmpfs xattr,dev=2 1031950367 /dev/dsk/c0t0d0s7 /export/home ufs rw,intr,largefiles ... -hosts /net autofs indirect,nosuid,ignore,nobrowse,... auto_home /home autofs indirect,ignore,nobrowse,... -xfn /xfn autofs indirect,ignore,dev=3dc0003 1031950370 Q-Sol:vold(pid247) /vol nfs ignore,dev=3d80001 1031950379 /vol/dev/diskette0/unnamed_floppy /floppy/unnamed_floppy pcfs
rw,nohidden,nofoldcase,dev=16c0002 1031953542 # Another critical file exists to assist in mounting file systems, and that's the /etc/vfstab (virtual file system table) file. This file controls the automatic mounting of file systems when Solaris is booted or when the mountall command is manually issued. This saves the hassle of manually mounting each file system every time you reboot Solaris.
Unlike /etc/mnttab, the /etc/vfstab file can be manually edited. In fact, if you want a file system to be mounted automatically, it's suggested that you do add an entry to the /etc/vfstab file. To add an entry, you will need to know where the file system is physically located, the name of the mount point, the type of file system, whether you want the file system to mount automatically, and any mount options. Here is a sample /etc/vfstab file:
# cat /etc/vfstab #device device mount FS fsck mount mount #to mount to fsck point type pass at boot options # fd - /dev/fd fd - no - /proc - /proc proc - no - /dev/dsk/c0t0d0s1 - - swap - no - /dev/dsk/c0t0d0s0 /dev/rdsk/c0t0d0s0 / ufs 1 no - /dev/dsk/c0t0d0s7 /dev/rdsk/c0t0d0s7 /files ufs 2 yes - swap - /tmp tmpfs - yes - #
One thing that many new administrators find odd is that the root (/) and /usr file systems have the mount at boot field set to no. These file systems are obviously critical, so why are they set this way? It's because the Solaris kernel mounts these file systems during the boot sequence, before the mountall command is issued. Table 7.4 describes the fields in /etc/vfstab.
| Field | Description |
|---|---|
| Device to mount | Provides the block device name for local UFS file systems or swap slices, the resource name for a remote file system, or a directory for a virtual file system. |
| Device to fsck | The raw device name that corresponds to the UFS file system defined in the device to mount field. For read-only, remote, and virtual file systems, this field will contain a dash (-). |
| mount point | The directory in which to mount the file system. |
| FS type | Names the type of file system. |
| fsck pass | Used by the fsck command to determine whether to check the file system. A dash (-) means that the file system is not checked. If the value is 0, UFS file systems are ignored, but others are checked. A value greater than 0 means that the file system is always checked. |
| mount at boot | A yes or no value, indicating whether the file system should be automatically mounted at boot. |
| mount options | A list of options, separated by commas. A dash (-) indicates no options. |
Mounting File Systems
Before moving on to mounting a file system, take a moment to reflect on what a file system really is. Yes, it's a method in which to store files, but more importantly in this context, a file system is a collection of files and directories.
You have already learned that file systems need to be mounted in order to be accessed, and that file systems are mounted to a directory called a mount point. So when you mount a file system, you are inserting a directory tree, however large, into a certain place in your existing file system.
There are three ways to mount file systems. One is to use the mount command, another is to use the mountall command, and the last is to add an entry into the /etc/vfstab file. If you need to mount the file system frequently, it's much easier to use the /etc/vfstab file, or perhaps AutoFS for remote file systems. For file systems that are mounted infrequently, the mount command should be sufficient.
| Note | The mount and mountall commands will not mount a read/write file system that contains known inconsistencies. Run fsck to fix the file system before mounting. |
To use mount, you must be the superuser or be able to assume an equivalent role. The mount command has quite a number of options, which will be covered shortly. Here's the syntax for mount:
# mount -F FSType [generic_options] [-o specific_options] device_name mount_point
You have to love a command that has both generic options and specific options. Specific options are invoked by using the -o switch and are separated by commas (with no spaces). If there's a conflict between a generic and a specific option, the specific option overrides the generic one. This can all be a bit confusing, so after describing the options, we'll go over a few examples. Table 7.5 displays some generic mount options.
| Argument | Description |
|---|---|
| -F FSType | Specifies the file system type to mount. |
| -m | Mounts the file system but does not create an entry in /etc/mnttab. |
| -O | Overlay mount. This enables you to mount a file system over an existing mount. The overwritten file system will not be accessible while the new file system is mounted. |
| -p | Prints a list of mounted file systems in /etc/vfstab format. Must be used alone. |
| -r | Mounts the file system as read-only. |
| -v | Prints the list of mounted file systems in verbose format. Must be used alone. |
Specific mount options, as invoked with -o, are listed in Table 7.6. These mount options are available only if they correspond to the file system type specified by the -F FSType variable.
| Option | File System | Description |
|---|---|---|
| bg | fg | NFS | Specifies whether to retry the mount operation in the background or foreground if mounting fails the first time. Foreground is the default. |
| hard | soft | NFS | Specifies how to proceed if the server does not respond. The soft option returns an error, and hard retires the request until the server responds. The default is hard. |
| retry=n | NFS | Retries the mount operation if it fails. The variable n determines the number of times to retry. |
| largefiles | nolargefiles | UFS | The default is largefiles, which means the file system can contain files larger than 2GB. The nolargefiles option means that the file system cannot contain files larger than 2GB. |
| logging | nologging | UFS | Enables or disables UFS logging on the file system. The default is nologging. Enabling logging does take up a small amount of additional disk space but helps keep the file system consistent. |
| remount | All | This option changes features of an already mounted file system. It can be used with any options except ro. |
| ro | rw | CacheFS, NFS, PCFS, UFS, HSFS | Read-only versus read/write. The default is read/write, except for HSFS, which is read-only. |
| suid | nosuid | CacheFS, HSFS, NFS, UFS | Enables or disables the use of SetUID. The default is suid. |
As promised, here are some examples of using the mount command. Perhaps the easiest one is to check the currently mounted file systems. To do that, just type mount and press Enter. If you wish to mount a file system that's listed in the /etc/vfstab file, all you need is the mount command and the name of the mount point. For example, to mount the file system /files (as shown in the earlier /etc/vfstab example), you would type:
# mount /files
You could also use the name in the device to mount field (/dev/dsk/c0t0d0s7 in this case), but generally speaking, using the mount point name is easier.
Also, don't forget that you're mounting a file system into a directory. If the mount point directory does not exist, you must create that directory before attempting to mount the file system. Here's an example of mounting the device /dev/dsk/c0t0d0s4 in a directory named /finance (and the /finance directory does not yet exist):
# mkdir /finance # mount /dev/dsk/c0t0d0s4 /finance
If you wanted to mount the same file system but make it read-only, you could use:
# mount -o ro /dev/dsk/c0t0d0s4 /finance
Or, you could mount the file system as read/write (which is the default, but the argument is listed for illustrative purposes anyway), enable logging, and disable large files:
# mount -o rw,logging,nolargefiles /dev/dsk/c0t0d0s4 /finance
Here's one more example. It's for mounting an NFS file system from a directory named docs on the gandalf server, into your local /finance directory.
# mount -F nfs gandalf:/docs /finance
I realize that we haven't covered NFS in any detail yet, but I also wanted to provide a quick example in case it pops up on the Part I test. It shouldn't, but you never know.
Unmounting File Systems
Because mounting a file system makes its resources available, it logically follows that unmounting a file system makes its resources unavailable. When you unmount, the file system is removed from the mount point and removes the entry from the /etc/mnttab file.
You might want to unmount a file system for a variety of reasons. One example is that the files are outdated and need to be replaced with newer files (such as an updated software package). Another example is system administration, such as backups. Backups cannot be performed on mounted file systems. When you shut down Solaris, all file systems are automatically unmounted.
To unmount file systems, you can use the umount and umountall commands. The umount command requires you to specify the file system to unmount, whereas umountall unmounts all file systems listed in the /etc/vfstab file.
To unmount a file system, you must be the superuser or assume an equivalent role. Also, the file system must not be busy. File systems are considered busy if a user is accessing a directory in the file system, a program has an open file in the file system, or the file system is being shared. You might need to use the fuser command to list and/or stop all processes that are accessing the file system.
| Note | Although umount and umountall will not unmount busy file systems, you can force a busy file system to unmount by using umount -f. |
|
|
EAN: 2147483647
Pages: 194