Background

Before diving into this unit, it is helpful to refresh you understanding of these topics that were covered in CSCI 237:

• What is a process?
• What is an address space?
• What is a system call?

The File System API

FS System Calls

If we focus on Linux, there are many system calls (~300), but only some of them specifically relate to the storage subsystem. The system calls discussed in OSTEP Chapter 39 are enumerated below, and they are the ones that you will likely use most in this class. You should be familiar with all of them: both how to use them (or how to look up their usage using Unix man pages) and how they affect the state of the storage system’s key data structures. Memorization is much less important than thinking about why the interface is designed the way it is.

• open/creat
• close
• read
• write
• lseek
• pread/pwrite
• fsync
• rename
• stat/fstat
• unlink
• mkdir
• readdir
• rmdir
• unlink
• mount
• umount

Discussion Questions (syscalls)

• How do you look up the interface for any one of these system calls?
• How can you tell what system calls are performed when you run a program from the command line?

Types of Identifiers

There are multiple ways to refer to files, and each identifier has its own advantages and disadvantages. You should be familiar with the types of identifiers that are passed to each FS-related system call, and why that particular identifier is used.

What logical objects do each of the following types of identifiers refer to?

• inode number
• path (both “absolute paths” and “path components”)
• file descriptor

Discussion Questions (identifiers)

• Which of the three identifiers must be unique, and in what namespaces/contexts are they unique (e.g., within a process, within a file system directory hierarchy, and/or globally unique)?
• Are any of the identifiers human-friendly? Do any have intuitive interpretations?
• Do any of the identifiers express relationships among entities in our file system?
• How are inode numbers and paths related to the types of links: hard and symbolic?

files (the data structure)

Each process contains a private table that maps file descriptors (per-process integer identifiers) to file data structures. So we should try to be precise when we use the term file: colloquially, file has a meaning that is similar-to-but-very-different-from the file data structure that is part of the file system API in the OS. Unfortunately always being precise is difficult, so context should be helpful when determining what is meant by the word file.

Discussion Questions (files)

• What field(s) are stored in the file data structure?
• What system calls alter those fields, and in what ways?
  • Think of a task you would want to perform on a file (e.g., read 20 bytes). You should be able to describe how the file data structure’s state would change after successful completion of that task, and be able to describe the system call(s) that you would execute to produce those changes.
• What are the relationships among the file data structure, a process, and the notion of a file that we colloquially use (a named unit of persistent storage)?
• Thinking forward: what is the granularity of access to a file? What is the granularity of access to a typical storage device like an HDD? What challenges might arise as a result of this mismatch? The file system’s job is to impose structure over an unordered array of blocks; first we will study the block interface and block device characteristics, then how file systems handle these peculiarities.

directories

Directories do not store “data” in the typical sense. Directories are a particular type of file that contains a mapping from pathnames to inode numbers.

Discussion Questions (directories)

• All directories contain two files by default: . and ... What are these files and what is their purpose?
  • As a result of these special files, what is the “link count” of an empty directory?
• rmdir deletes a directory. What are the necessary preconditions for the successful deletion of a directory? Why do you think this decision was made?

open

If the process has sufficient permissions to access a file, the open() system call creates an entry in the process’s file table so that the process can interact with the file. The file desriptor returned by open is an index into that table. The same “colloquial file” can be opened multiple times, and each file structure instance keeps helpful state about the process’s interactions with that “colloquial file”, including a current offset and the “access mode” (e.g., read-only).

Discussion Questions (open)

• Which type of the three identifiers (i.e., inode number, pathname, or file descriptor, as described in the Names section above) do you pass as an argument to open?
• What type of identifier does open return?
• There are three types of identifiers listed above… why doesn’t open accept/return an inode number?
• What is the difference between open and creat? Given this relationship, how might you implement creat?
• What is a capability, and why does the book claim that a file descriptor is a capability?

links

Indirection is a very powerful tool. There are two useful types of indirection provided by links.

• Two paths can refer to the same inode object.
• A file can be a special type of file that stores the path of antoher file. In this way, a file can “point” to another file name.

Discussion Questions (links)

• What is meant by a hard link and a symbolic link?
• Reference counting is an important concept in file systems (and other systems for that matter). Which type of link (hard or symbolic) increases an inode’s reference count?
  • What system call lowers an inode’s reference count?
• What is meant by a dangling reference?
• In what scenarios would you use a hard link, and in what scenarios would you use a symbolic link?
• Name one common use of a symbolic link (hint: type which python at the command line, and then check the long listing (ls -l) of the resulting pathname)

File Systems and Trees

Directories give the file system namespace a hierarchical structure. This gives a powerful way to express relationships between objects. These relationships are often used by file systems to influence their low-level data placement/organization policies.

We use the mount and unmount system calls to create a unified namespace from a set of independent file systems: mount takes the root of a file system and attaches it to a directory in the global namespace. Unmounting a file system disconnects the root of that file system from the namespace, making that file system’s directory tree unreachable.

Discussion Questions (trees)

• What is a “tree” and why is it important that the file system namespace is a “tree”?
• How does Unix use a tree to let us combine multiple file systems?
• What is a “path lookup” and what are the steps involved in taking an absolute path and opening a file? (This isn’t described in detail in the assigned readings, and it is actually a very complicated process. Think about the file system tree, speculate about the high-level steps, and try to identify situations when a path lookup might fail.)
• What does it mean to mount a file system?
• What happens when you mount a file system on top of an existing subtree (what contents do you see when you navigate to the root of that subtree, i.e. the mount-point)?
• What happens when you unmount a file system?

fsync

Caching is an important tool for improving file system performance. Yet caching data exposes the system to data loss: what if the machine crashes before the cached data is written? It is important that applications have a way to enforce reliable guarantees so that they can protect themselves from corruption.

Discussion Questions (fsync)

• What is the outcome of calling fsync (i.e., can you describe possible initial and final states of a file before/after calling fsync)?
• Why do we need fsync at all? Why not immediately persist all data?
• Based on the existence of fsync, what guarantees does the write system call actually provide?
• Thinking forward to next class: Given the granularity of access supported by block devices, what types of things could go wrong if an application calls fsync and proper care is not taken in the application/file system implementations? What types of guarantees might be desirable for a system to support? Why are they not standard guarantees?

rename

Renaming a file is a seemingly simple task. Yet the deeper you dive into the rename system call, the more interesting it becomes. rename is the first time we encounter the concept of atomicity. An atomic operation is one that either happens completely and all at once, or it does not happen at all. In an atomic operation, no intermediate state is ever revealed. Fo rename, what that means is that the file either exists at its original location or at its new location—it is never in both places and it is never “gone”.

Discussion Questions (rename)

• What is the outcome of a successful rename?
• What are the ways that rename can fail?
  • What errors does rename report, and what are the possible states that can result in the system when there is a rename failure?
• Given the strict requirements of rename atomicity, rename is often used to update files. What combination of system calls could you use to perform a series of file modifications so that either all of your modifications are reflected in the final state of the file, or none of your modifications are reflected in the final state of the file?

lseek

The lseek system call updates a file data structure’s internal offset. This is useful for issuing non-sequential reads and writes (commonly referred to as random reads and writes, even when the operations are not random in the mathematical sense).

Discussion Questions (lseek)

• Does lseek modify any persistent file state?
• What is the relationship between lseek, read, pread, write, and pwrite?