Only available on StudyMode
  • Topic: File system, Inode, Path
  • Pages : 10 (3651 words )
  • Download(s) : 14
  • Published : April 1, 2013
Open Document
Text Preview
DRAFT as of November 19, 2010: Copyright 2009 Cox, Kaashoek, Morris

Chapter 7 File system data structures
The disk driver and buffer cache (Chapter 6) provide safe, synchronized access to disk blocks. Individual blocks are still a very low-level interface, too raw for most programs. Xv6, following Unix, provides a hierarchical file system that allows programs to treat storage as a tree of named files, each containing a variable length sequence of bytes. The file system is implemented in four layers: ------------pathnames ------------directories ------------inodes ------------blocks -------------

The first layer is the block allocator. It manages disk blocks, keeping track of which blocks are in use, just as the memory allocator in Chapter 2 tracks which memory pages are in use. The second layer is unnamed files called inodes (pronounced inode). Inodes are a collection of allocated blocks holding a variable length sequence of bytes. The third layer is directories. A directory is a special kind of inode whose content is a sequence of directory entries, each of which lists a name and a pointer to another inode. The last layer is hierarchical path names like /usr/rtm/xv6/fs.c, a convenient syntax for identifying particular files or directories.

File system layout
Xv6 lays out its file system as follows. Block 0 is unused, left available for use by the operating system boot sequence. Block 1 is called the superblock; it contains metadata about the file system. After block 1 comes a sequence of inodes blocks, each containing inode headers. After those come bitmap blocks tracking which data blocks are in use, and then the data blocks themselves. The header fs.h (3550) contains constants and data structures describing the layout of the file system. The superblock contains three numbers: the file system size in blocks, the number of data blocks, and the number of inodes.

Code: Block allocator


The block allocator is made up of the two functions: balloc allocates a new disk block and bfree frees one. Balloc (4104) starts by calling readsb to read the superblock. (Readsb (4078) is almost trivial: it reads the block, copies the contents into sb, and releases the block.) Now that balloc knows the number of inodes in the file system, it can consult the in-use bitmaps to find a free data block. The loop (4112) considers every block, starting at block 0 up to sb.size, the number of blocks in the file system, checking for a block whose bitmap bit is zero, indicating it is free. If balloc finds such a block, it updates the bitmap and returns the block For efficiency, the loop is split into two pieces: the inner loop checks all the bits in a single bitmap block—there are BPB—and the outer loop considers all the blocks in increments of BPB. There may be multiple processes calling balloc simultaneously, and yet there is no explicit locking. Instead, balloc relies on the fact that the buffer cache (bread and brelse) only let one process use a buffer at a time. When reading and writing a bitmap block (4114-4122), balloc can be sure that it is the only process in the system using that block. Bfree (4130) is the opposite of balloc and has an easier job: there is no search. It finds the right bitmap block, clears the right bit, and is done. Again the exclusive use implied by bread and brelse avoids the need for explicit locking. When blocks are loaded in memory, they are referred to by pointers to buf structures; as we saw in the last chapter, a more permanent reference is the block’s address on disk, its block number.

In Unix technical jargon, the term inode refers to an unnamed file in the file system, but the precise meaning can be one of three, depending on context. First, there is the on-disk data structure, which contains metadata about the inode, like its size and the list of blocks storing its data. Second, there is the in-kernel data structure, which contains a copy of the on-disk structure but adds extra metadata needed within...
tracking img