File System Implementation: beyond the user’s view A possible file system layout on a disk.

How does the file system keep track of which blocks on the disk go with which file?

Contiguous Allocation of Disk Space (a) State of contiguous allocation for 7 files (b) State of the disk after files D and E have been removed

Storing a file as a linked list of disk blocks

Linked list allocation using a File Allocation Table in RAM

An example i-node

Implementing Directories (a) A simple directory fixed size entries disk addresses and attributes in directory entry (b) Directory in which each entry just refers to an i-node

Implementing Directories (2) Two ways of handling long file names in directory –(a) In-line –(b) In a heap

Shared Files A connection between a directory and a shared file is called a ‘link’. Is the following diagram a tree?

What problem can develop with shared files? When directories actually hold disk addresses, if one owner appends the file, these additional blocks appear in only that directory. Solutions: 1. Do not list disk blocks in the directory. Include a pointer to an I-node instead, as done in Unix. 2. Use ‘symbolic linking’, where the operating system controls the situation. A file has one ‘owner’ directory. When another directory wishes to share the file, a new type file called ‘LINK’ is created. This file contains the path name of the file and is put in the other directory.

Note: With symbolic links, files on machines around the world can be used by only providing the network address of the machine where the file resides and the path to where it resides on that machine. However, there is a great deal of overhead: 1. The file containing the path must be read. 2. The path must be parsed and followed one component at a time until the I-node is reached. All of which requires many, time consuming, disk reads.

Managing Disk Space Similar concerns to managing main memory: Store an n byte file in n consecutive bytes OR Split up the file into (some number) of not necessarily contiguous blocks of disk space. This is the same trade-off as pure segmentation and paging. However, which takes more time? When a segment grows, moving it to acquire more memory is much faster than moving a file on a disk.

Nearly all file systems use fixed-size, not necessarily contiguous, blocks. What are block size concerns? Small blocks (power of 2, less than 2KB) are bad for performance. Why? (each read takes seek time and has rotational delay) but small blocks are good for resource utilization (disk space) Large blocks (>2KB) have better data access time (more data is read with each seek)but space is wasted (most files will not fill the last block).

Keeping track of free disk blocks is similar to keeping track of main memory. Two methods are: 1. A linked list of blocks on the disk, each block holding the numbers of the free blocks. Example: 1 KB blocks could hold 256 free block numbers, if each is a 32 bit integer. Why? 1024 = bits = 4 bytes = / 2 2 = 2 8 Actually, only 255 free block numbers are held, because one slot holds a pointer to the next block. Does this work with 32 bits? Yes, if 32 bit addresses are used on the disk.

2. A bitmap is used. Each block on the disk is represented by 1 bit. (free = 1, allocated - 0, or vice versa) Bitmaps use less disk space, since only 1 bit per block rather than 32 bits for a block number is used.