This chapter looks at UNIX \u001cfile systems<\/a> from the programmer’s perspective. The primary objective is to be able to write programs that use the part of the UNIX API<\/a> concerning the fi\u001cle system and its components. Of necessity, we will begin with an overview of what the \u001cle system is, and to a limited extent, how it is implemented. Although it is not necessary to understand how it is implemented to write programs that use it, a basic understanding of the typical implementation can help in understanding performance considerations and limitations.<\/p>\n A \u001cfile system<\/a> is an abstraction that supports the creation, deletion, and modification of files, and organization of files into directories. It also supports control of access to \u001cfiles and directories and manages the disk space accorded to it. We tend to use the phrase fi\u0010\u001cle system\u0011 to refer to a hierarchical, tree-like structure whose internal nodes are directories and whose external nodes are non-directory-\u001cfiles (or perhaps empty directories), but a \u001cfile system is actually the \u001dat structure sitting on a linear storage device such as a disk partition. The layout of Linux<\/a>, for example, is shown in Figure 3.1. This \u001dat structure is completely hidden from the user, but not entirely from the programmer. The user sees this as a hierarchically organized collection of \u001cfiles and directories, which is more properly called the directory hierarchy or file hierarchy.<\/p>\n Multiple storage devices are usually attached to a modern computer. Some operating systems treat the \u001cfile systems on these devices as independent entities. In Microsoft’s DOS, and systems derived from it, for example, each separate disk partition has a drive letter, and the \u001cfile hierarchy on each separate drive or partition is separate from all others attached to the computer. In e\u001bffect, DOS has multiple trees whose roots are drive letters. For example, a typical Windows<\/a> machine may have a directory E:\\users on the “E:” drive and a directory “C:\\Temp” on the “C:” drive<\/a> but these directories are in two separate trees, not a single tree.<\/p>\n In UNIX there is a single \u001cfile hierarchy. It is a tree if you think of the leaf nodes as \u001cfilenames, but it is not a tree if you think of the leaf nodes as actual \u001cfiles, since a single \u001cfile can have more than one name, existing as a directory entry in multiple directories, making the topology a directed acyclic graph1. We will take the liberty of referring to it as a tree, knowing that this is inaccurate.<\/p>\n In UNIX, every accessible \u001cfile is in this single fi\u001cle hierarchy, no matter how many disks are attached. There is no such thing as the “C” drive” or “E” drive” in UNIX. This is because of the concept of mounting, which will be described in more detail later. In short, in UNIX, a fi\u001cle system may be mounted onto the single \u001cfile hierarchy by attaching that fi\u001cle system’s root to some directory in the hierarchy. It is like grafting a branch onto a tree. By mounting a fi\u001cle system onto the fi\u001cle hierarchy, the fi\u001cle system becomes a subtree of the hierarchy, making it possible to navigate into the \u001cfile system from the rest of the fi\u001cle hierarchy. The mount command without arguments displays a list showing all of the file systems currently mounted on the fi\u001cle hierarchy. As an example, the output of the mount command could be:<\/p>\n \/dev\/mapper\/root.vg-root.lv on \/ type ext3 (rw) Each line is of the form,<\/p>\n \u001cfile_system_name on place_where_it_is_mounted type \u001cfile_system_type other_options<\/em><\/p>\n The sixth line states that there is a fi\u001cle system named \/dev\/sda1 of type ext3 that is mounted on the directory \/boot. You may wonder about the meaning of the line<\/p>\n proc on \/proc type proc (rw)<\/p>\n In a subsequent chapter we will explore the \/proc fi\u001cle system, which is not a fi\u001cle system that manages disk space, but an interface to the kernel’s memory. Further interpretation of this output will be delayed until after a discussion of \u001cfile systems and mounting in greater depth. At this point, the signi\u001cficance of mounting is that di\u001bfferent fi\u001cle systems can be, and usually are, part of a single conceptual \u001cfile hierarchy, making it possible to partition a disk into separate fi\u001cle systems that all become part of a single fi\u001cle hierarchy.<\/p>\n","protected":false},"excerpt":{"rendered":"3.2 File System Abstraction<\/h2>\n
3.3 File System Mounting<\/h2>\n
\nproc on \/proc type proc (rw)
\nsysfs on \/sys type sysfs (rw)
\ndevpts on \/dev\/pts type devpts (rw,gid=5,mode=620)
\ntmpfs on \/dev\/shm type tmpfs (rw,rootcontext=”system_u:object_r:tmpfs_t:s0″)
\n\/dev\/sda1 on \/boot type ext3 (rw)
\nnone on \/proc\/sys\/fs\/binfmt_misc type binfmt_misc (rw)<\/p>\n