Files, inodes, and processes


Speaking in a generic sense, the "inode" or index node is the source of all knowledge about a file. There are actually different types of inodes, used for different types of files. In addition, a "virtual" layer was imposed in the middle to remove the necessity for identifying various file types. In the beginning, the inode was used to describe a UFS local file, and it held all the data defining where that file lived, its attributes, ownership, and other vital information. When other file system types were introduced, it became necessary to define a vnode (a virtual inode) that would point to the actual inode with the real file system and type-specific access information. Thus, we now may have a vnode that points to an inode (UFS), an rnode (a remote file system ”NFS), an snode (indicating a special file, or a device), a tmpnode (used for tmpfs), or (new in Solaris 2.3) a cnode (for cachefs file systems). Most layers of the system deal with vnodes until they really need to access the file data pointed to by that vnode.

UFS directory entries on disk really contain just an inode number and a name , which allows multiple names to refer to the same file by using the same inode (index, or file) number. (The format of a directory entry for both SunOS 4.x and Solaris 2 is described in /usr/include/sys/dirent.h .) The filename is used only when opening a file; from then on a "handle" (file descriptor) is used by the program to refer to the file and read to the vnode.

Several tables in the kernel keep information about open files in one way or another. As usual, all these tables and structures are linked. The links are set up to make finding the vnode easy for the user process. Let's assume the user wants to read data from a file. The following figure shows the various structures that are referenced and the pointers that are followed, in order for a program to open a file, get a file descriptor, and use that descriptor to retrieve some data from the file.

Figure 19-4. Kernel Tables and Structures

graphics/19fig04.gif

As you can see, the kernel must pass through the following structures before it can find the real location of the data that the user wants to read.

  • The U-area ( user structure) keeps an array of pointers for file references. There is one pointer (one array element) per open file. The file descriptor that the user program gets from an open() system call is an index into this array. These array elements really just contain pointers to:

  • A file table entry, which contains the modes with which a file was opened (read-only, read-write) and the current "position" within that file where the next I/O operation will take place. Every separate open() request generates a new file table entry. There is only one file table in the system. Each file table entry contains a pointer to:

  • A vnode , which identifies some generic characteristics of the file and points to:

  • the real inode (for UFS files), snode (for special device files) or rnode (for remote networked files), which tells you, finally, how to get to the actual data.

At the bottom of the picture, directory entries (out on disk) also indicate the inode by means of an index or file number kept in the directory itself. These would be used during an open() request to translate the name of the file into an inode. You should note that no table in the kernel actually contains the filename once that file has been successfully opened.

There are pointers from user structures (U-areas) down to vnodes and inodes, but there are no pointers back up from vnodes to U-areas. You also find pointers (index numbers ) from a directory entry to an inode, but not from the inode back out to the directory. Essentially, this is a many-to-one relationship at each stage ” and there is no way to establish a single link back the other way. A commonly asked question is "How can I tell who has this file open?" Unfortunately, it's not an easy question to answer. You can identify a vnode associated with the file, but then you need to search every file table entry to see if it points to that vnode. Once you have a list of file table entries that refer to that particular file, then you need to search every U-area in the system to find all the pointers to those file table entries. The fuser program in Solaris 2 will locate processes that are using certain files, but it does require super-user access to search the kernel tables. The same thing holds for finding filenames on disk. If you know the inode, you must search every directory entry to see if that name refers to the desired inode. A program called ncheck helps you do this for disk files on a single file system.



PANIC. UNIX System Crash Dump Analysis Handbook
PANIC! UNIX System Crash Dump Analysis Handbook (Bk/CD-ROM)
ISBN: 0131493868
EAN: 2147483647
Year: 1994
Pages: 289
Authors: Chris Drake

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net