| When files are created on a filesystem they are stored inside a directory. A directory is simply a file that has a particular format. It is stored on the disk in the same way as ordinary files. The only reason you can't edit them like an ordinary file is because the editor programs (such as vi) specifically stop you from doing so. We will use the directory /var/adm as an example to demonstrate the structure of a directory. As you know, the ls command is provided to list the contents of a directory: hydrogen# cd /var/adm hydrogen# ls aculog log passwd sulog utmpx wtmp lastlog messages spellhist utmp vold.log wtmpx hydrogen# This has shown us the names of the files and directories that are in the directory /var/adm, but we cannot tell which are files and which are directories. If we use the "-l" option with ls we can see quite a bit more information about the contents of /var/adm: hydrogen# ls -l total 1036 -rw------- 1 uucp bin 0 Oct 23 22:21 aculog -r--r--r-- 1 root other 28 Apr 16 18:19 lastlog drwxrwxr-x 2 adm adm 512 Oct 23 22:20 log -rw-r--r-- 1 root root 212878 Apr 16 15:15 messages drwxrwxr-x 2 adm adm 512 Oct 23 22:20 passwd -rw-rw-rw- 1 bin bin 0 Oct 23 22:21 spellhist -rw------- 1 root root 0 Jan 20 16:19 sulog -rw-r--r-- 1 root bin 396 Apr 16 18:19 utmp -rw-r--r-- 1 root bin 4092 Apr 16 18:19 utmpx -rw-rw-rw- 1 root root 4756 Apr 16 15:14 vold.log -rw-rw-r-- 1 adm adm 25200 Apr 16 18:19 wtmp -rw-rw-r-- 1 adm adm 260400 Apr 16 18:19 wtmpx hydrogen# You may be tempted to think all this information is stored within the directory, but the actual directory contents are closer to the first ls listing we saw. On our server, the directory /var/adm actually contains the information listed in Table 6.7 and nothing more. Table 6.7. The Real Contents of /Var/admColumn 1 | Column 2 |
|---|
18 | . | 2 | .. | 11344 | log | 15122 | passwd | 24 | aculog | 25 | spellhist | 26 | utmp | 27 | utmpx | 28 | wtmp | 29 | wtmpx | 14 | messages | 252 | vold.log | 254 | lastlog | 270 | sulog |
The column headings are just for reference and are not actually held in the directory, but everything else is. The second column contains the names of the files and directories (as shown by the ls command), but the directory does not hold any more information about the file other than the file's inode number. This (you will have worked it out by a process of elimination) is in the first column. There are two entries within the directory that did not show up in the ls output. These are "." (dot) and ".." (dot dot). The reason that ls did not display these entries (which are actually directories) is because UNIX convention has it that files beginning with a dot are classed as hidden files and ls does not show hidden files unless the "-a" option is supplied. In fact, every single directory contains two entries called dot and dot dot. We will see that these entries are crucial to the way that directories and subdirectories are linked together. So, at the moment we know that a directory is actually a file that simply contains the names of the files and directories that belong in it. Along with each name is a number called the inode number. When we looked at the format of a filesystem we saw that the largest areas are the inode area and the data area. The data area holds the actual data contained within the files; since a directory is a special type of file we know that the data we saw in Table 6.7 (inode numbers and filenames) is stored somewhere in this part of the filesystem. The inode area of the filesystem contains the actual inodes. As each inode is 128 bytes in size, this section of the filesystem will be a multiple of 128 bytes in length. This 128 bytes contain all the information about a file apart from its name. Each inode contains the information provided in Table 6.8. Table 6.8. The Contents of an InodeField | Description |
|---|
file type | This is a single byte and will be one of the following characters: - (for a regular file) d (for a directory) b (for a block special file) c (for a character special file) L (for a symbolic link) p (for a named pipe or FIFO file)
File types are also mentioned in Chapter 4, "Permissions and All That." | file mode | The access permissions that belong to the file. See Chapter 4, "Permissions and All That," for more information. | number of hard links | This is equal to the number of references there are inside directories to this inode. When a file is deleted, this number is reduced by one. When it goes to zero the inode becomes "free." | user ID | This is equal to the user ID of the file owner. | group ID | This is equal to the group ID that the file belongs to. | number of bytes | This shows how many bytes in the filesystem data area belong to this file. | 15 disk block addresses | These addresses are numbered 0 to 14 and each one contains the address of a data block in the filesystem data area. These addresses are described in more detail later. | last access date and time | This is the date and time the file was last opened. | last modification date and time | This is the date and time that the contents of the file last changed. (This is not the same as the contents of the inode getting changed.) | file creation date and time | This is not the date and time that the file was created, but is actually the date and time that the inode last changed. |
Most information in the inode can be displayed using the ls command with various options. For example, the "-i" option will display the inode number of each file: hydrogen# ls -ia 18. 2 .. 24 aculog 254 lastlog 11344 log 14 messages 15122 passwd 25 spellhist 270 sulog 26 utmp 27 utmpx 252 vold.log 28 wtmp 29 wtmpx hydrogen# The inode number is shown before each filename. Since we also included the "-a" flag, we can see the entries for dot and dot dot. The above example shows the true contents of the directory /var/adm as all the other information about the files is stored in the individual inodes. If you try to look at a directory using the cat command, you will not see the output in a very readable format as the terminal emulator is likely to be confused by the inode numbers since they are not stored in text format. You can, however, use the od command to verify that a directory really is just a file containing inode numbers and filenames. The best way to do this is to run od -bc dir_name. Each file that exists on a Solaris UFS filesystem has an entry in a directory that contains the file's name and the number of the inode that contains information about that file. Part of the information is the address (or addresses) of the blocks that actually hold the data that form the contents of the file. As mentioned earlier, the inodes are stored in a separate part of the filesystem from the data blocks. Every file has one inode allocated to it as soon as it is created. If the file has any contents, these will be stored in blocks within the data area. If the file is empty, it will not have any space in the data area allocated to it. If the file is not empty, the address of each data block allocated to that file is stored within the inode. The inode contains 15 slots for addresses (numbered 0 to 14). A quick calculation may lead you to believe that a file can only have a maximum size of 15 times the filesystem's block size. This certainly doesn't add up to anywhere near the maximum supported file size; that is because the 15 slots don't work quite as simply as the last sentence suggests. In fact, the first 12 address slots in the inode each hold the address of a single block that contains part of the file's data. Slot 12 also holds the address of a block in the data area, but this is called an "indirect block." Instead of it containing data that belong to the file, it contains more addresses of allocated blocks. If the file is so big that the indirect block can't accommodate it, then slot 13 will hold the address of a double indirect block. This block contains addresses of other indirect blocks. In the rare chance that the file is still too big to be accommodated, the final address slot is reserved for the address of a triple indirect block. The inode number associated with each file is unique within each filesystem. The inode number of the filesystem's top-level directory is always 2 (inode numbers 0 and 1 exist, but are reserved). When a directory is created, the entries dot and dot dot are placed inside it. The file called "." has the same inode number as the directory in which it resides and the file called ".." has the same inode number as the directory in which its directory resides (or the parent directory). It is not possible for two inodes to have the same inode number (within the same filesystem), so if two files have the same inode number they must be the same file but with two different names. A file that refers to an existing file's inode number is called a "link." There is no concept of one being the master and the other being linked to that file. They can be thought of literally as alternative names for the same file. This means that a directory will always start with two links (or two references), the first being its name in the parent directory and the second being "." (dot), which appears as an entry within itself. If a subdirectory is created within this directory then the number of links goes up to three as the entry called ".." (dot dot) in the subdirectory is another link to this directory. The directory tree is managed by the use of links. The dot dot entry in every directory is linked to the dot entry in the directory above, and that in turn is linked to its name in its parent directory. Files can also be linked using the ln command. When a file is created it will have one link, but you can effectively create another name that refers to the same file by creating another link: hydrogen# ln sulog link_to_sulog hydrogen# ls -l sulog link_to_sulog -rw------- 2 root root 157 Jan 20 16:19 sulog -rw------- 2 root root 157 Jan 20 16:19 link_to_sulog hydrogen# The file now has two names by which it can be referred, but both names have the same inode number so they share the inode and they share the data. If one of the files is deleted, the link count of the other will drop to one. If that file is deleted, the inode count drops to zero and the inode is added to the free inode list. Files can be linked in this way anywhere within the same filesystem. If you wish to create a link across filesystems you need to use a symbolic link (ln -s). A symbolic link is simply a file that contains the path to the file to which it is symbolically linked. You can tell it is a symbolic link since its file type will be "L" and the path it points to is also shown in the output from an ls -l command. If you wish to view the contents of an inode, it is possible using the fsdb utility (filesystem debugger). This is a very powerful tool that can be used to perform a number of low-level operations on a filesystem, so do not try anything other than the command listed here as it could cause damage if used incorrectly: hydrogen# umount /usr/local/utils hydrogen# fsdb /dev/rdsk/c0t2d0s4 fsdb of /dev/rdsk/c0t2d0s4 (Read only) -- last mounted on /usr/local/utils fs_clean is currently set to FSCLEAN fs_state consistent (fs_clean CAN be trusted) /dev/rdsk/c0t2d0s4 >:inode 2 i#: 2 md: d---rwxr-xr-x uid: 0 gid: 0 ln: 5 bs: 2 sz : 200 db#0: 330 accessed: Sun Apr 22 18:16:50 2001 modified: Mon Apr 16 18:06:37 2001 created : Mon Apr 16 18:06:37 2001 /dev/rdsk/c0t2d0s4 > :quit hydrogen# The fsdb prompt is the device containing the filesystem followed by a "greater than" symbol. Each fsdb command should be preceded by a colon. In the above example we have asked fsdb to display the contents of inode 2 (which is the root directory of the filesystem). We can see that the name of the file does not appear anywhere and we know the file is less than one block in size since only one data block address is shown. So we know that the contents of this directory are stored in block number 330 in the data storage area of the filesystem. One of the three times displayed is marked as "created"; this is not the time the file was created since this is not stored. This time is actually the time the inode was last updated, and is a well-known bug in fsdb. Devices Solaris provides a directory called /dev that contains a series of special files. Each file is linked to a device of some sort. We have already seen that each disk partition has two entries under /dev: a raw (or character) device and a block device. There are also entries for tape devices, floppy disks, and even the system's memory. The reason these exist is to provide a standard interface to all devices that acts in the same way as a normal Solaris file. Therefore, these entries have permissions, owners, and groups just like a normal file does. The Solaris kernel contains a device driver for each device that basically converts the file type operation performed on the file under /dev into instructions that the actual device understands. This is one of the strengths of the UNIX operating environment. Solaris Directories When Solaris is first installed, literally hundreds of directories are created. Until you have been using Solaris for some time, you will not remember all the important locations. Table 6.9 lists the directories you most likely need to know about from the root, usr, and var filesystems. Table 6.9. Standard Directory LocationsDirectory | Description |
|---|
/ | The very top-level directory. | /dev | Where all the special device files live. They are grouped into subdirectories. | /dev/rdsk | Location of raw special files for disk slices. | /dev/dsk | Location of block special files for disk slices. | /dev/rmt | Location of raw tape device special files. | /dev/mt | Location of block tape device special files. | /dev/term | Location of terminal special device files (for async connections). | /dev/pts | Location of pseudo TTY slave devices (for telnet sessions, etc.). | /etc | Houses the host-specific administrative configuration files. | /etc/default | Contains a number of files containing various default settings. | /etc/inet | Contains configuration files for Internet services. | /etc/init.d | Contains scripts that run when run levels change. The files located here are linked to files under /etc/rcX.d. | /etc/net | Location of configuration files for network services. | /etc/skel | Default location of master user profiles. | /export | Default root for exported filesystems. | /home | Default location of user home directories. | /kernel | Location of loadable kernel modules. | /mnt | Empty directory normally used as a temporary mount point. | /opt | Usual location of additional Solaris packages. | /sbin | Bin directory that contains the essential system programs required during bootup and manual system recovery procedures. | /stand | Default location of standalone programs. | /tmp | Temporary directory usually located on system swap area and cleared out during a reboot. | /usr | Mount point for the /usr filesystem. | /var | Mount point for the /var filesystem. (Var is short for "varying," since it contains files likely to change.) | /var/adm | Location of system logs and accounting files. | /var/mail | Location of user mail files. | /var/preserve | Contains backups of interrupted editor sessions. | /var/spool/cron | Location of cron and at control files. | /var/tmp | Temporary directory that does not get cleared at boot-time. | /usr/bin | Standard location of operating system commands. | /usr/include | Header files for C programs. | /usr/lib | Location of libraries. | /usr/local | Directory for in-house programs, etc. | /usr/sbin | Location of system administration programs. | /usr/ucb | Location of BSD variants of operating system commands. |
In earlier versions of UNIX the /var filesystem did not exist and these files were contained in the /usr filesystem. With the introduction of UNIX System V Release 4 (SVR4), upon which Solaris is based, the old /usr was split into two separate filesystems (/usr and /var). /usr housed the files that tended to remain static (such as programs and library files) and /var took all the volatile files (such as log files, configuration files, and temporary files). Links exist in /usr to provide backward compatibility. This can lead to a common problem when /usr fills up because of the system administrator thinking (s)he is clearing files from /usr, but df continues to report it is 100 percent full. This is because it is actually /var that is being cleared out. | 
