Topics

 File system structure

COS 318: Operating Systems  Disk allocation and i-nodes

 Directory and link implementations

 Physical layout for performance

File Layout and Directories

File System Components Steps to Open A File

 Naming  File name lookup and authenticate
 Copy the file descriptors into the in-memory data structure, if it is not in yet
 File and directory naming
 Create an entry in the open file table (system wide) if there isn’t one
 Local and remote operations File naming  Create an entry in PCB
Management

 File access  Link up the data structures

 Implement read/write and other File access  Return a pointer to user
File system
functionalities Buffer cache Open file info
Process File
 Buffer cache control table descriptors File
 Reduce client/server disk I/Os Disk allocation block (system-wide) (Metadata) descriptors
 Disk allocation
Volume manager Directories
 File data layout
 Mapping files to disk blocks
Open
 Management file File data
 Tools for system administrators pointer ..
to manage file systems array .
3 4

1
File Read and Write Disk Layout
 Read 10 bytes from a file starting at byte 2? Boot Super File descriptors
File data blocks
 seek byte 2 block block (i-node in Unix)
 fetch the block
 Boot block
 read 10 bytes  Code to bootstrap the operating system
 Write 10 bytes to a file starting at byte 2?  Super-block defines a file system
 seek byte 2  Size of the file system
 Size of the file descriptor area
 fetch the block  Free list pointer, or pointer to bitmap
 write 10 bytes in memory  Location of the file descriptor of the root directory
 write out the block  Other meta-data such as permission and various times
 Kernel keeps in main memory, and is replicated on disk too
 File descriptors
 Each describes a file
 File data blocks
 Data for the files, the largest portion on disk

5 6

Data Structures for Disk Allocation Contiguous Allocation

 The goal is to manage the  Request in advance for the size of the file
allocation of a volume  Search bit map or linked list to locate a space
 A file header for each file  File header
 First block in file
 Disk blocks associated with  Number of blocks
each file 11111111111111111000000000000000  Pros
 A data structure to represent 00000111111110000000000111111111  Fast sequential access
free space on disk
…

 Easy random access

 Bit map that uses 1 bit per 11000001111000111100000000000000  Cons
block (sector)  External fragmentation (what if file C needs 3 blocks)
 Linked list that chains free Free  Hard to grow files: may have to move (large) files on disk
blocks together  May need compaction
 … link
addr link File A File B File C
size addr …
size
7 8

2
Linked Files (Alto) File Allocation Table (FAT)
 File header points to 1st  Approach foo 217
block on disk File header  Table of “next pointers”, indexed by block
• Instead of pointer stored with block
 A block points to the next 0
 Directory entry points to 1st block of file
 Pros  Pros
 Can grow files dynamically  No need to traverse list to find a block
217 619
 Free list is similar to a file  Cache FAT table and traverse in memory
... Cons
 No external fragmentation 
399 EOF
or need to move files  FAT table takes lots of space for large disk
• Hard to fit in memory; so may need seeks
 Cons
 Pointers for all files on whole disk are interspersed
 Random access: horrible null in FAT table 619 399
 Even sequential access • Need full table in memory, even for one file
needs one seek per block • Solution: indexed files
 Unreliable: losing a block • Keep block lists for different files together,
and in different parts of disk FAT
means losing the rest
9 10

Single-Level Indexed Files DEMOS (Cray-1)

 A user declares max size  Idea
 A file header holds an array  Using contiguous allocation (base,size)
of pointers to point to disk  Allow non-contiguous ..
Disk . data
blocks  Approach
File header blocks
 Pros  10 (base,size) pointers
 Can grow up to a limit  Indirect for big files
(base,size)
 Random access is fast
.. ..
 Cons . . data
 Clumsy to grow beyond the
limit
 Still lots of seeks

11 12

3
Multi-Level Indexed Files (Unix) What’s in Original Unix i-node?
 13 Pointers in a header  Mode: file type, protection bits, setuid, setgid bits
 10 direct pointers  Link count: number of directory entries pointing to this
 11: 1-level indirect data  Uid: uid of the file owner
 12: 2-level indirect
 Gid: gid of the file owner
 13: 3-level indirect
1
data  File size
 Pros & Cons ...
2

 In favor of small files ..  Times (access, modify, change)

11
12 . data  No filename??
 Can grow 13

 Limit is 16G and lots of

.. ..
seek . . data  10 pointers to data blocks
.. .. ..
 Single indirect pointer
. . . data  Double indirect pointer
 Triple indirect pointer
13 14

Extents Naming
 Instead of using a fix-  Text name
sized block, use a Block offset  Need to map it to index
number of blocks
length  Index (i-node number)
 XFS uses 8Kbyte block
 Max extent size is 2M Starting block  Ask users to specify i-node number
blocks  Icon
 Index nodes need to have  Need to map it to index or map it to text then to index
 Block offset ...
 Length
 Starting block
 Is this approach better
than the Unix i-node
approach?

15 16

4
Directory Organization Examples Mapping File Names to i-nodes
 Flat (CP/M)  Create/delete
 All files are in one directory  Create/delete a directory
 Hierarchical (Unix)  Open/close
 /u/cos318/foo  Open/close a directory for read and write
 Directory is stored in a file containing (name, i-node) pairs  Should this be the same or different from file open/close?
 The name can be either a file or a directory  Link/unlink
 Hierarchical (Windows)  Link/unlink a file
 C:\windows\temp\foo  Rename
 Use the extension to indicate whether the entry is a directory  Rename the directory

17 18

Linear List Tree Data Structure

 Method  Method
 <FileName, i-node> pairs are /u/jps/  Store <fileName, i-node> a tree data
linearly stored in a file structure such as B-tree
foo bar …
 Create a file Create/delete/search in the tree data
veryLongFileName 
• Append <FileName, i-node> structure
 Delete a file
 Pros
• Search for FileName <foo,1234> <bar, …
 Good for a large number of files
• Remove its pair from the 1235> … <very
directory LongFileName,  Cons
• Compact by moving the rest 4567>  Inefficient for a small number of files
 Pros  More space
 Space efficient  Complex
 Cons
 Linear search
 Need to deal with fragmentation
19 20

5
Hashing Disk I/Os to Read/Write A File
 Method  Disk I/Os to access a byte of /u/cos318/foo
 Use a hash table to map  Read the i-node and first data block of “/”
FileName to i-node  Read the i-node and first data block of “u”
 Space for name and  Read the i-node and first data block of “cos318”
metadata is variable sized foo 1234  Read the i-node and first data block of “foo”
 Create/delete will trigger bar 1235
space allocation and free  Disk I/Os to write a file
 Read the i-node of the directory and the directory file.
Pros

…

foobar 4567  Read or create the i-node of the file
 Fast searching and relatively
simple  Read or create the file itself
 Write back the directory and the file
 Cons
 Not as efficient as trees for
very large directory (wasting  Too many I/Os to traverse the directory
space for the hash table)  Solution is to use Current Working Directory

21 22

Links Original Unix File System

 Symbolic (soft) links  Simple disk layout
 A symbolic link is just the name of the file  Block size is sector size (512 bytes)
 i-nodes are on outermost cylinders
 Original owner still owns the file, really deleted on rm by owner
 Data blocks are on inner cylinders
 Use a new i-node for the symbolic link  Use linked list for free blocks
ln –s source target
 Issues
 Hard links  Index is large
 A link to a file with the same i-node  Fixed max number of files
ln source target  i-nodes far from data blocks
 Delete may or may not remove the target depending on  i-nodes for directory not close together
whether it is the last one (link reference count)  Consecutive blocks can be anywhere
 Poor bandwidth (20Kbytes/sec even for
 Why symbolic or hard links? sequential access!)
 How would you implement them? i-node array

23 24

6
BSD FFS (Fast File System) FFS Disk Layout
 Use a larger block size: 4KB or 8KB  i-nodes are grouped together
 Allow large blocks to be chopped into foo  A portion of the i-node array on each
cylinder
fragments
 Do you ever read i-nodes without
 Used for little files and pieces at the
reading any file blocks?
ends of files
 Overcome rotational delays
 Use bitmap instead of a free list bar
 Skip sector positioning to avoid the
 Try to allocate contiguously context switch delay
 10% reserved disk space  Read ahead: read next block right
after the first

i-node subarray

25 26

What Has FFS Achieved? Summary

 Performance improvements  File system structure
 20-40% of disk bandwidth for large files (10-20x original)  Boot block, super block, file metadata, file data
 Better small file performance (why?)  File metadata
 We can still do a lot better  Consider efficiency, space and fragmentation
 Extent based instead of block based  Directories
• Use a pointer and size for all contiguous blocks (XFS, Veritas  Consider the number of files
file system, etc)
 Synchronous metadata writes hurt small file performance
 Links
• Asynchronous writes with certain ordering (“soft updates”)  Soft vs. hard
• Logging (talk about this later)  Physical layout
• Play with semantics (/tmp file systems)  Where to put metadata and data

27 28