Classic Shell Scripting - Arnold Robbins [236]
Since the inode structure, and other low-level details of storage devices, are system-dependent, it is generally not possible to mount a disk containing a Unix filesystem from one vendor on a system from another vendor. However, through a software layer called the Network File System (NFS), across networks it is virtually always possible to share Unix filesystems between computers from different vendors.
Because the inode table has a fixed size, it is possible for a filesystem to fill up even when there is plenty of free space on the storage device: there is room for the file's data, but not for its metadata (data about the data).
As shown in Figure B-2, the inode entry contains everything that the system needs to know about the file, except for one thing: its filename. This might seem surprising, and indeed, several other operating systems with a similar filesystem design do include the filename in their analogues of inodes.
Figure B-2. Inode table contents
In Unix, the filename is stored in the directory, together with its inode number, and not much else, as illustrated in Figure B-3. Early Unix systems on the small computers of the 1970s allocated only 16 bytes in a directory for each file: 2 bytes gave the inode number (limiting the number of files to 216 = 65,536), and 14 bytes gave the filename, only marginally better than the 8+3 limit of some other systems.
Figure B-3. Directory table contents
Modern Unix filesystems allow longer filename lengths, although there is typically a maximum length, as we showed earlier in this Appendix with the getconf example in Section B.4.1.
Directories can be read, but not written, by their owners, and some early Unix software opened and read directories to find filenames. When a more complex directory design was introduced in the 1980s, the opendir( ), readdir( ), and closedir( ) library calls were created to hide the structure from programmers, and those calls are now part of POSIX (see the manual pages for opendir(3)). To enforce library access, some current Unix implementations prohibit read operations on directory files.
* * *
Tip
Why is the filename separated from the rest of the file metadata in Unix? There are at least two good reasons:
* * *
Users commonly list the contents of directories simply to remind themselves of what files are available. If filenames were stored in inodes, finding each filename in the directory might take one or more disk accesses. By storing the names in the directory file, many names can be retrieved from a single disk block.
If the filename is separate from the inode, then it is possible to have multiple filenames for the same physical file, simply by having different directory entries reference the same inode. Those references need not even be in the same directory! This notion of file aliases, called links in Unix, is extremely convenient, and is widely used. On six different flavors of Unix, we found that 10 percent to 30 percent of the files under /usr were links.
A useful consequence of the Unix filesystem design is that renaming a file or directory, or moving it within the same physical Unix filesystem, is fast: only the name needs to be changed or moved, not the contents. Moving a file between filesystems, however, does require reading and writing all of the file's blocks.
If files can have multiple names, what does it mean to delete a file? Should all of them disappear at once, or should only one of them be removed? Both choices have been made by designers of filesystems that support aliases or links; Unix made the second choice. The Unix inode entry contains a count of the number of links to the file contents. File deletion causes the link count to be decremented, but only when it reaches zero are the file blocks finally