Certification Objective 4.01Exploring the Solaris Directory Hierarchy | Sun Certified System Administrator for Solaris 10 Study Guide Exams 310-XXX & 310-XXX

Certification Objective 4.01—Exploring the Solaris Directory Hierarchy

Exam Objective 2.1: Explain the Solaris 10 OS directory hierarchy, including root subdirectories, file components, and file types, and create and remove hard and symbolic links.

As in other operating systems, the files on Solaris are grouped into a directory, and the directories are organized into a hierarchy. A directory (called folder in the Windows operating systems) may contain files and other directories, called subdirectories. In Solaris, however, directories are just a special kind of file.

In this section we explore the Solaris Directory Hierarchy, beginning with the concept of a file.

File: The Atom of the Solaris World

As in Java, it is said that everything is object; in Solaris everything is file. File is the basic unit, the atom, in Solaris. Everything is treated as a file. Here are a few examples:

Commands. These are the executable files.
Devices. All devices on the system, such as disk drive, printer, or terminal, are treated as files by the system—that is, the system communicates with them through files.
Directories. The directories are special files that contain other files.
Documents. These are the regular files such as text file or a computer program containing the source code.

A file occupies the space on disk in units of what is called a block. The blocks are measured in two sizes: physical block size, which is the size of the smallest block that the disk controller can read or write, and logical block size, which is the size of the block that UNIX (Solaris in our case) uses to read or write files. The physical block size and the logical block size may not be the same.

A file has a name that is a link to the file, and the user accesses the file by its name. The name is stored inside a directory. All the other information about a file is stored in a data structure called inode. An inode, which is 128KB in size and is stored in the cylinder information block, contains the following information about the file:

The type of the file—regular, block special, character special, directory, FIFO named pipe, socket, symbolic link, or other inode
The file modes (i.e., the read, write, and execute permissions)
The number of hard links to the file
The group ID to which the file belongs
The user ID of the user that owns the file
The number of bytes in the file
An array of addresses for 15 disk blocks
The date and time the file was last accessed
The date and time the file was last modified
The date and time the file was created

Note that the first 12 (0 to 11) of the 15 disk-block addresses point directly to the blocks that store the file content. In other words, the first 12 elements of the address array point directly to the logical blocks in which the file content is stored. If the file is larger than 12 logical blocks, the additional (up to 3) addresses point to indirect blocks that contain the addresses of direct blocks. The physical block size is usually 512 bytes, and the logical block size is set (by default) to the page size of the system, which is 8KB for a UFS file system, the default file system for Solaris.

Because each file needs an inode, the number of inodes on a file system determines the maximum number of files that can be created on the system. The maximum number of inodes you can create depends on the size of the file system. For example, you can create one mode for each 2KB of disk space for a file system of size up to 1GB. That means 1GB/2KB = 500,000 files can be created at maximum on a file system of 1GB size. For larger file systems, the number of bytes needed on the disk per inode increases, as shown in Table 4-1.

Table 4-1: Number of bytes per inode with varying disk size
File System Size (GB)	Number of Bytes per Inode (KB)
0–1	2
1–2	4
2–3	6
3–1000	8
>1000	1024

Files in Solaris are grouped into directories, and the directories are organized into a directory hierarchy, which we explore next.

Directory Hierarchy in Solaris

Just as in any other OS, files in Solaris are organized into directories, and directories are organized into a hierarchy called a directory tree, which is an inverted tree with the root directory (symbolized by /) on the top, which contains other directories. The root directories and several other directories underneath it are created when you install Solaris. You must be familiar with the following directories underneath the root:

/bin. Symbolic link to the /usr/bin directory.
/dev. Contains logical device names (defined in the next chapter) for the devices.
/devices. Device-related files controlled by the file system: devfs.
/lib. Contains shared libraries such as SMF executables.
/etc. Administrative and configuration files.
/export. You can define it according to your needs, but commonly used to hold user home directories.
/home. This is the default mount point for user home directories.
/mnt. Default mount point used to temporarily mount file systems.
/sbin. Contains system administration commands and utilities. Used during booting when /usr//bin has not yet been mounted.
/tmp. Contains temporary files that are deleted when the system is rebooted.
/usr. UNIX System Resources. Holds OS commands and programs.

Of course you can create your own directories and files in the already existing tree.

The user refers to the files and directories by their names. It can be advantageous not to expose the real names of some directories and files to users. Instead create something that points to the file, and if that pointer is deleted, the actual file is not (hence the advantage). These pointers are called links, which we discuss next.

Managing Hard and Symbolic Links

A link is a file that points to another file. There are two kinds of links available in Solaris: hard links and symbolic links. A hard link is a pointer to a file that is indistinguishable from the original file. That is, any changes to a file are effective regardless of the name used to refer to the file—the link name or the original file name. Furthermore, a hard link can point only to a file, not to a directory. In addition, a hard link cannot span file systems; that is, the link and the file must be on the same file system because both have the same inode number.

A symbolic link, on the other hand, is an indirect pointer to a file—that is, its directory entry contains the name of the file to which it points. Furthermore, it may span file systems and point to cither a directory or a file.

Creating Hard and Symbolic Links

To create a symbolic link or a hard link, you use the same command name, In, which has the following syntax:

 In [-fns] <source> [<target>]

Exam Watch

Hard link is the default output of the ln command—that is, if you issue the ln command without the - s option, a hard link will be created.

In this command, <source> is the original file and <target> is the link that will be created and linked to the <source>. The options for the command are listed here:

-f (force). Link the file without questioning the user.
-n. If the <target> is an existing file, do not overwrite the content of the file. The -f option overrides this option.
-s. Create a symbolic link. The default is a hard link.

The hard links and symbolic links are compared in Table 4-2

Table 4-2: Comparison of hard and soft links
Characteristic	Hard Link	Soft Link
Existence of original file	You cannot create a hard link to a file that does not exist.	You can create a symbolic link to a file that does not exist.
File systems	A hard link cannot span file systems—that is, the link and the file it points to have to be in the same file system.	A soft link can span file systems.
Kind of original file	A hard link can only point to a file that is not a directory.	A soft link can point to a file or a directory.
I-node	A hard link has the same inode number as the file it points to.	A soft link has a different inode from the file it points to.

Removing Hard and Symbolic Links

To remove a file, all hard links that point to it must be removed, including the name by which it was originally created. Only after removing the file itself and all of its hard links, will the inode associated with the file be released.

In both cases, hard and soft links, if you remove the original file, the link will still exist. A link can be removed just as can a file:

    rm <linkName>

On the Job

When you delete a file, the clean thing to do is: delete all the symbolic links pointing to it.

Remember that you can (but should not) delete a file without deleting the symbolic links. However, you cannot delete the file (its content) unless you delete all the hard links pointing to it.

The directory tree in Solaris appears as one uniform file system to an ordinary user, who can assume that it is true for all practical purposes. However, you, the system administrator, must know that the tree is made of several file systems. Next, we explore the file systems supported by Solaris.