File Systems

Dr. M. Brindha
Associate Professor
Department of CSE
NIT, Trichy-15
Two views of a file
system
protection
rw
attributes
system calls
x
Application View
Look & Feel

File system

Hardware view

2
 File
s
• From a user’s perspective,
– A byte array
– Persistent across reboots and power failures

• From OS perspective,
– Secondary (non-volatile) storage device
• Hard disks, USB, CD, etc.
– Map bytes as collection of blocks on storage device

3
Application View

4
Files

• Files: are logical units of information created by processes:

• Processes / Threads can read existing files and create
new ones;
L.
Tarrataca

• Information stored in files must be persistent, i.e.

• not affected by process creation and termination.

Files are managed by the operating system. How they
are
• structured...

• named...

• accessed...

• used... L.
Tarrataca

• protected...

• implemented...

• and managed

are major topics in operating system

design.
 File Systems
(1)
Essential requirements for long-term
information storage:

• It must be possible to store a very large amount

of information.
• The information must survive the termination of
the process using it.
• Multiple processes must be able to access the
information concurrently.
 File Systems
(2)
Think of a disk as a linear sequence of fixed-
size blocks and supporting reading and
writing of blocks. Questions that quickly
arise:

• How do you find information?

• How do you keep one user from reading another’s
data?
• How do you know which blocks are free?
 Files vs
Memory
• Every memory location has an address that can be directly
accessed
• In files, everything is relative
– A location of a file depends on the directory it is stored in
– A pointer must be used to store the current read or write position within
the file
– Eg. To read a byte in a specific file.
• First search for the file in the directory path and resolve the identifier
expensive for each access !!!
• Use the read pointer to seek the byte position

– Solution : Use open system call to open the file before any
access
(and close system call to close the file after all accesses are
complete)

9
File
Naming File Naming

Exact rules for file naming vary somewhat among OS:

• Current OS allow strings of various lengths as legal file

L.
10 / 161
Tarrataca

names;

• OS typically support two-part file names: (filename,

extension);
 File Naming

Some typical file extensions.

 File
Structure

Three kinds of files. (a) Byte sequence.

(b) Record sequence. (c) Tree.
 File File
s Structure

File Structure
Files can be structured in any of several ways
(1/3):

L.

Files are merely byte

13 / 161
Tarrataca

sequences:
• Maximum flexibility;
• Unix, Linux, OS X and
Windows use this model;

Figure: The memory hierarchy

(Source: [Tanenbaum and Bos,
2015])
Chapter 4 - File
 File File
s Structure

File
Structure
Files can be structured in any of several ways
(2/3):

File is a sequence of fixed-

length
L.
Tarrataca
14 / 161
records:
• Each record has a
certain number of
bytes;
• Read operation returns
one record;
• Write operation overwrites
or appends one record.
Figure: Record sequence file structure.
(Source: [Tanenbaum and Bos, 2015])
Chapter 4 - File
 File File
s Structure

File
Structure

Files can be structured in any of several ways (3/3):

File consists of a tree of records:
• Not necessarily all the
L.
Tarrataca
15 / 161
same length;
• Each record contains a key
field in a fixed position in
the record
Figure: Tree file structure • Tree is sorted on the key
(Source: [Tanenbaum and Bos, field:
2015])
• Allowing rapid key
search;

Chapter 4 - File
 File File Typ
s es

File
Types

OS support several types of files:

• Files: containing user information:

• Containing ASCII characters;
L.
16 / 161
Tarrataca

• Or containing binary information:

• Only readable by the computer;

• All programs are binary files;

• Directories: system files for maintaining the structure of the file

system;

Chapter 4 - File
 File File Acces
s s

File
Access

When magnetics disks appeared it became possible to:

• Read the bytes or records of a file out of order;

L.
17 / 161
Tarrataca

• Or to access records by key rather than by position;

Files whose bytes or records can be read in any order are

called
random-access files;

Chapter 4 - File
File Attributes
• Name – only information kept in human-readable form
• Identifier – unique tag (number) identifies file within file system
• Type – needed for systems that support different types
• Location – pointer to file location on device
• Size – current file size
• Protection – controls who can do reading, writing, executing
• Time, date, and user identification – data for protection, security,
and usage monitoring
• Information about files are kept in the directory structure, which is
maintained on the disk
• Many variations, including extended file attributes such as file
checksum
• Information kept in the directory structure
 A File’s Metadata
(inodes)
• Name. the only information kept in human readable
form.
• Identifier. A number that uniquely identifies the file within
the file system. Also called the inode number
• Type. File type (inode based file, pipe, etc.)
• Location. Pointer to location of file on device.
• Size.
• Protection. Access control information. Owner, group
(r,w,x) permissions, etc. a
• Monitoring. Creation time, access time, etc.

Try ls –i on Linux to see the inode number for a file 16

File info Window on Mac OS X
 File File
s Attributes

File Attributes
OS keep track of a wide range of information regarding a
file:

L.
21 / 161
Tarrataca

Figure: Some possible file attributes (Source: [Tanenbaum and Bos,

2015])
Chapter 4 - File
 File
Operations
The most common system calls relating to files:
• Create • Append
• Delete • Seek
• Open • Get
• Close Attributes
• Read • Set Attributes
• Write • Rename
File Operations
• File is an abstract data type
• Create
• Write – at write pointer location
• Read – at read pointer location
• Reposition within file - seek
• Delete
• Truncate
• Open(Fi) – search the directory structure on disk for entry
Fi, and move the content of entry to memory
• Close (Fi) – move the content of entry Fi in memory to
directory structure on disk
 File File
s Operations

File
Operations

Most common system calls relating to files (1/5):

• Create: file is created with no data;

• Delete: When the file is no longer needed, it has to be deleted to

L.
Tarrataca
24 / 161

free up disk space

• Open: Before using a file, a process must open it in order to:

• fetch the attributes and list of disk addresses into main memory for
rapid access on later calls.

Chapter 4 - File
 File File
s Operations

File
Operations

Most common system calls relating to files (2/5):

• Close: When all the accesses are finished:

• attributes and disk addresses are no longer needed;
L.
25 / 161
Tarrataca

• file should be closed to free up internal table space;

• Read: Data are read from file:

• Bytes come from the current position;

• Caller must specify how many bytes to read and buffer to place
data;

Chapter 4 - File
 File File
s Operations

Most common system calls relating to files (3/5):

• Write: Data are written to the file using current position:

• If the current position is the end of the file, the file’s size increases;
L.
26 / 161
Tarrataca

• If the current position is in the middle of the file, existing data are
overwritten;

Chapter 4 - File
 File File
s Operations

Most common system calls relating to files (4/5):

• Append: restricted form of write. It can add data only to the end of
the file;
L.
27 / 161
Tarrataca

• Seek: repositions file pointer to a specific place in the file:

• After this call, data can be read from, or written to, that position

Chapter 4 - File
 File File
s Operations

Most common system calls relating to files (5/5):

• Get attributes: read file attributes;

• Set attributes: set some of the attributes;

L.
Tarrataca
28 / 161

• Rename: changes the name of an existing

file;

Chapter 4 - File
Example Program Using File System
Calls (1)

...
Figure 4-5. A simple program to copy a
file.
 Opening a
File
• Steps involved
– Resolve Name : search directories for file
names and check permissions
– Read file metadata into open file table
– Return index in the open file table (this is the
familiar file descriptor)

30
 Open file
tables
• Two open file tables used
– system wide table
• Contains information about inode, size, access
dates, permission, location, etc.
• Reference count (tracks number of processes that
have opened the file)
– per process table
• Part of PCBs proc structure
• Pointer to entry in the system wide table

31
 Open file
• tables
When a process calls open(), a new entry is created
in the System-wide open file table.
• A pointer to this entry is stored in the process's file
descriptor table.
• The file descriptor table is a simple array of pointers
into the open file table.
• The index into the file descriptor table - a file
descriptor.
• It is this file descriptor that is returned by open().
• When a process accesses a file, it uses the file
descriptor to index into the file descriptor table and
locate the corresponding entry in the open file table.
32
Open file
tables

33
 Open file
tables
The open file table contains several pieces of information
about each file:
•the current offset (the next position to be accessed in the
file)
•a reference count
•the file mode (permissions),
•the flags passed into the open() (read-only, write-only,
create, &c),
•a pointer to an in-RAM version of the inode (a slightly light-
weight version of the inode for each open file is kept in RAM
-- others are on disk),
•A pointer to the structure containing pointers to the
functions that implement the behaviors like read(), write(),
close(), lseek(), &c on the file system that contains this file.
34
 Open file
Each entry in tables
the open file table maintains its own
read/write pointer for three important reasons:
•Reads by one process don't affect the file position in
another process
•Write are visible to all processes, if the file pointer
subsequently reaches the location of the write
•The program doesn't have to supply this information
each call.

35
 inode
• Every inode in the Linux structure has a unique
number identified with it. It is also called the index
number and has the following attributes:
• Size
• Owner
• Date/time
• Permissions and access control
• Location on the disk
• File types
• Number of links
• Additional metadata about the file
36
 File System
Operations
Directory operations:
• modify the names space of files.
• Examples include mkdir(), rename(), creat(), mount(),
link() and unlink()
File operations:
• obtain or modify the characteristics of objects.
• Examples include stat(), chmod(), and chown()
I/O operations
• access the contents of a file
• I/O operations, unlike file operations, modify the
actual contents of the file, not metadata associated
with the file.
• Examples include read(), write(), and lseek().
• These operations are typically much longer than the
other two. 37
 A File System
Organization

• A volume is a partition that has been formatted into a filesystem.

• A partition is of little use unless formatted. And when we format a partition
• into NTFS, FAT32, ext4 etc, it becomes a volume and is usable.
•Volume used to store a file system
•A volume could be present in partitions, disks, or across disks
•Volume contains directories which record information about name,
location, size, and type of all files on that volume 38
 Directori
es
• Maps file names to location on disk
• Directories also stored on disk
• Structure
– Single-level directory
• One directory for all files -- simple
• Issues when multiple users are present
• All files should have unique names
– Two-level directory
• One directory for each user
• Solves the name collision between users
• Still not flexible enough (difficult to share files between users)

39
 Directori Hierarchical Directory
es Systems

Directori
es

L.
Tarrataca

• File systems normally have directories or folders, which are

themselves files:
• Allows the file system to have a hierarchy of files;

• Grouping related files together;

• Tree of directories;
 Directori Hierarchical Directory
es Systems

L.
41 / 161
Tarrataca

Figure: A hierarchical directory system. (Source: [Tanenbaum and Bos,

2015])

Chapter 4 - File
 Directori Path
es Names

Path
Names

When the file system is organized as a directory tree:

• Some way is needed for specifying file names;

• Usually there are two solutions:

L.
Tarrataca
42 / 161

• Absolute Pathname: E.g. ‘‘/usr/ast/mailbox’’

• Relative Pathname: makes use of the current

directory:
• E.g. current directory is ‘‘/usr/ast’’ which can have file
‘‘mailbox’’

Chapter 4 - File
 Directori Path
es Names

Usually, OS also have two special directories:

• Directory . - represents the current

directory;L.
Tarrataca
43 / 161

• Directory .. - represents the parent

directory;

Chapter 4 - File
 Directori Directory
es Operations

Directory
Operations

Most common system calls relating to directories (similar to file

since directory is a file)(1/3):
L.
44 / 161

• Create: creates an empty directory;

Tarrataca

• Delete: removes an empty directory;

• Opendir: to open a directory;

Chapter 4 - File
 Directori Directory
es Operations

Directory
Operations

Most common system calls relating to directories (2/3):

• Closedir: . When a directory has been read, it should be closed to

free up internal table space.
L.
45 / 161
Tarrataca

• Readdir: to list the contents of a directory;

• Rename: to rename an existing directory;

Chapter 4 - File
 Directori Directory
es Operations

Directory
Operations

Most common system calls relating to directories

(3/3): L.
46 / 161
Tarrataca

• Link: creates a link for a file in a given

directory;

• Unlink: removes a file present in the

directory;

Chapter 4 - File
 Protectio
n
• Types of access
– Read, write, execute, …

• Access Control
– Which user can use which file!

• Classification of users
– User, group, others

47
 Mounting a File
System
• Just like a file needs to be opened, a file system needs
to be mounted
• Mounting a file system attaches that file system to a
directory (mount point -root) and makes it available to
the system.
OS needs to know
– The location of the device (partition) to be mounted
• – The location in the current file structure where the file system is
to be attached
$ mount /dev/sda3 /media/xyz -t ext3
OS does,
– Verify that the device has a valid file system
– Add new file system to the mount point (/media/xyz)
48
Implementing a File System

49
 FS
Layers
Application View

Logical file system

through system calls Manages file metadata
information. Directory structure,
File organization module inodes

Translates logical view (blocks)

Basic File System
to physical view
(cylinder/track) Manages free
I/O Control (device drivers) space
Generic read/write to device
Buffers/Caches for data blocks
Hardware View
Interrupts / IO etc.
Layered architecture helps prevent Interrupt handling, low level
duplication of code I/O, DMA management
50
 File System : disk
contents
• Boot control block (per volume)
– If no OS, then boot control block is empty
• Volume control block (per volume)
– Volume(or partition details) such as number of blocks in the
partition, size of blocks, free blocks, etc.
– Sometimes called the superblock
• Directory structure
– To organize the files. In Unix, this may include file names and
associated inode numbers. In Windows, it is a table.
• Per file FCB (File control block)
– Metadata about a file. Unique identifier to associate it with a
directory.

51
 file system : in-memory
contents
• Mount table : contains information about each mounted
volume
$ cat /etc/fstab

• In memory directory structure cache holds recently

accessed directories
• System wide open file table
• Per process open file table
• Buffer cache to hold file
system blocks

52
File System
Implementation
Now that we know all the main file system concepts:

How are such concepts implemented in an OS? Any

ideas? L.
Tarrataca
53 / 161

• How are files and directories stored?

• How is disk space managed?

• How to make everything work efficiently and

reliably?

Chapter 4 - File
 File System File
Implementation System Layout

File systems are stored on disks:

• Most disks can be divided up into one or more

partitions:
• with independent file systems on each partition;
L.
54 / 161
Tarrataca

• Sector 0 of the disk is called the MBR (Master Boot

Record):
• Used to boot the computer;

• End of MBR contains the partition table

Chapter 4 - File
 File System File
Implementation System Layout

Partition Table contains:

• Starting and ending addresses of each partition;

• One of the partitions in the table is marked as

active;

• When computer is booted:

L.
Tarrataca
55 / 161

• BIOS reads in and executes the MBR

program;

• Active partition is located;

• Active partition boot block is read and

executed;

• Boot block program loads OS;

Chapter 4 - File
 File System File
Implementation System Layout

Layout of a disk partition varies a lot from file system to file

system:

• Usually it goes something like this:

L.
56 / 161
Tarrataca

Figure: A possible file-system layout (Source: [Tanenbaum and Bos,

2015])

Chapter 4 - File
 File System File
Implementation System Layout

From the previous figure (1/2):

• Superblock: contains all the key parameters about the file

system;
• File-system type identification;

• Number of blocks;
L.
57 / 161
Tarrataca

• Etc...

• Free space mgmt: information about the file system free

blocks;
• E.g. Bitmap or list of pointers

Chapter 4 - File
 File System File
Implementation System Layout

From the previous figure (2/2):

• I-nodes: array of data structure, one per file, detailing

the file;
L.
58 / 161
Tarrataca

• Root directory: contains the top of the file-system-tree;

• Files and directories: containing all the real

information;

Chapter 4 - File
 File operations
(create)
• File Creation
1. Create FCB for the new file
2. Update directory contents
• .3. Write new directory contents to disk (and may cache it as well)

59
 File Operations
•
(open)
File Open
1. Application passes file name through open system call
2. sys_open searches the system-wide open file table to see if the file is
already in use by another process
• If yes, then increment usage count and add pointer in per-process open
file table
• If no, search directory structure for file name (either in the cache or disk)
add to system-wide open file table and per-process open file table
3. The pointer (or index) in the per-process open file table is returned to
application. This becomes the file descriptor

60
 File operations
(close)
• file close
– Per process open table entry is removed
– System wide open table reference count
decremented by 1.
• If this value becomes 0 then updates copied back
to disk (if needed)
• Remove system wide open table entry

61
 File Operations
(read/write)
• File Read

62
 File Access
Methods
• Sequential Access
– Information processed one block after the
other
– Typical usage
• Direct Access
– Suitable for database systems
– When query arrives, compute the
corresponding block number, and directly
access block

63
 Tracking Free
Space
• Bitmap of blocks
– 1 indicates used, 0 indicates free
• Linked list of free blocks

• File systems may use heuristics

– eg. A group of closely spaced free
blocks

64
 Allocation
Methods
• How does the OS allocate blocks in the
disk?
– Contiguous allocation
– Linked allocation
– Indexed allocation

65
 Contiguous
Allocation
• Each file is allocated contiguous blocks on the disk
• Directory entry keeps the start and length
• Allocation
– First fit / best fit ?
• Advantages
– Easy / simple

• Disadvantages
– External fragmentation
(may need regular defagmentation)
– Users need to specify the
maximum file size at creation
(may lead to internal fragmentation – a file may request a much large space
and not use it)

66
 File System Implementing the
Implementation files

Contiguous
Allocation
Idea: Store each file as a contiguous run of disk
blocks:

• E.g. 50-KB file would be allocated to

• 50 consecutive blocks using a disk with 1-KB
blocks:L.
67 / 161
Tarrataca

• 25 consecutive blocks using a disk with 2-KB

blocks:

Figure: Contiguous allocation of disk space for seven files (Source: [Tanenbaum and Bos,
2015])

Chapter 4 - File
 File System Implementing the
Implementation files

From the previous figure:

• First 40 disk blocks are shown;

• Initially, the disk was empty;

• Then a file A, of length four blocks, was written:

L.

• If file A was 3 1/2 blocks, some space is wasted at the end of the last
68 / 161
Tarrataca

block;

• After that a three-block file, B, was written;

• In the figure, a total of seven files are shown:

• Each one starting at the block following the end of the previous one.

Chapter 4 - File
 File System Implementing the
Implementation files

In your opinion what are the advantages of contiguous allocation?

Any ideas?

Advantage 1: Simple to implement:

L.
69 / 161
Tarrataca

• Keeping track of where a file’s blocks are is reduced to:

• remembering disk address of the first block and number of blocks
in the file;

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any other advantage of contiguous allocation? Any

ideas?

Advantage 2: Read performance:

• Entire file can be read from the disk in a single

L.
Tarrataca
70 / 161

operation;

• Only one seek is needed for the first block;

• After that, no more seeks or rotational delays are

needed:
• data come in at the full bandwidth of the disk;

Chapter 4 - File
 File System Implementing the
Implementation files

In your opinion what are the disadvantages of contiguous

allocation? Any ideas?

Major disadvantage: over time, disk becomes

fragmented L.
71 / 161
Tarrataca

Figure: The state of the disk after files D and F have been removed. (Source: [Tanenbaum and Bos,
2015])

Chapter 4 - File
 File System Implementing the
Implementation files

From the previous figure:

• Files D and F were removed:

• Respective blocks were then freed;

• Leaving a run of free blocks on the disk;

• Disk would have to be compacted

L.
72 / 161
Tarrataca

immediately:
• Potentially millions of blocks to compact...

• Disastrous perfomance;

• As a result: disk consists of files and holes;

Chapter 4 - File
 File System Implementing the
Implementation files

Initially: fragmentation is not a problem:

• Each new file can be written at the end of disk:

• following the previous one;

• However, eventually the disk will fill up, then two solutions
exist: L.
Tarrataca
73 / 161

• Compact the disk: prohibitively expensive;

• Reuse free space:

• When a new file is created choose a hole big enough;

• Requires maintaining a list of holes;

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any other disadvantages of contiguous allocation?

Any ideas?

Major disadvantage: file size needs to known at time of

creation
L.

• This is not always possible to know in advance:

74 / 161
Tarrataca

• File size may change with time...

Conclusion: contiguous allocation is problematic...

Can you think of any other type of method for implementing files?

Chapter 4 - File
 Linked
Allocation
• Directory stores link of start and end block
(optionally)
• Pointer in block store link to next block
• Advantages
– Solves external fragmentation
• problems
– Not suited for direct access of files (all
Disadvantages
pointers need to be accessed)
– Pointer needs to be stored ..
overheads!!
• Overheads reduced by using clusters (ie. cluster of
– sequential blocks associated with one pointer)
Reliability.
• If a pointer is damaged (or lost), rest of file is lost.
• A bug in the OS may result in a wrong pointer
being picked up.

75
 File System Implementing the
Implementation files

Linked-List Allocation

Idea: keep each file as a linked list of disk

blocks:

L.
76 / 161
Tarrataca

Figure: Storing a file as a linked list of disk blocks. (Source: [Tanenbaum and Bos,
2015])

Chapter 4 - File
 File System Implementing the
Implementation files

From the previous figure:

• First word of each block is used as a pointer to the next one:

• Rest of the block is for data.

• Unlike contiguous allocation:

• Every disk block can be used in this method;
L.
Tarrataca
77 / 161

• No space is lost to disk fragmentation:

• This does not mean that fragmentation does not occur!

• Directory entries merely need to store the disk address of the first
block:
• Rest can be found starting there.

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any other disadvantages of Linked-List Allocation?

Any ideas?

• Contiguous allocation allows for sequentially file reads:

• Very efficient =)
L.
Tarrataca
78 / 161

• Linked-list allocation implies random block accesses:

• To get to block n, OS has to:
• Start at the beginning and read n - 1 blocks prior;

• Painfully slow =’(

Chapter 4 - File
 File System Implementing the
Implementation files

Linked-list file implementation is also problematic...

Can you think of any other methods for implementing a file? Any
ideas?
L.
79 / 161
Tarrataca

Chapter 4 - File
 Indexed
Allocation
• Advantages,
– Supports direct access
– No external fragmentation
– Easy to grow files
• How large should the index block be?
– Files typically, one or two blocks long
• The index block will therefore have only one or two
entries
• A large index block  huge wastage
– A small index block will limit the size of
file
• Need an additional mechanism to deal with large
files
• Disadvantage, Use disk blocks as index blocks
– Sequential access may be that don't hold file data, but hold
• May use clusters
slow pointers to the disk blocks that
hold file data.

80
 FAT
File
(a variation linked allocation scheme)
• Invented by Marc McDonald and Bill Gates
• FAT is a table that
– contains one entry for each block
– and is indexed by block number.
• Files represented by linking pointers in
the FAT
• FAT table generally cached
• Advantages,
– Solves direct access
problems of linked
allocation
– Easy to grow files
– Greater reliability
•
• A bad block implies only
one block is corrupted

Disadvantages,
– Volume size determined
by FAT size

81
 File System Implementing the
Implementation files

Linked-List Allocation Using a Table in

Memory
Disadvantages of the linked-list allocation can be eliminated by:

• Storing the pointer word from each disk block in a table in

memory;

L.
82 / 161
Tarrataca

Chapter 4 - File
 File System Implementing the
Implementation files

In the previous two figures we have two files:

• File A uses disk blocks 4, 7, 2, 10, and 12;

• File B uses disk blocks 6, 3, 11, and 14;

• Using the table:

• File A: start with block 4 and follow the chain until the
L.
Tarrataca
83 / 161

end;
• Chain is terminated with a special marker (e.g., -1)

• File B: start with block 6 and follow the chain until the
end;
• Chain is terminated with a special marker (e.g., -1)

Such a table in main memory is called a FAT (File Allocation

Table);

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any any advantages with linked-list allocation using a
table in memory? Any ideas?
L.
84 / 161
Tarrataca

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any any advantages with linked-list allocation using a
table in memory? Any ideas?

Random access is much easier, however chain:

L.
Tarrataca
85 / 161

• Must still be followed to find a given offset

within the file;

Despite this the chain is entirely in memory:

• Can be followed without making any disk references;

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any any disadvantages with linked-list allocation

using a table in memory? Any ideas?

• Entire table must be in memory all the time to make it

work;

• Example: 1-TB disk and a 1-KB block size:

L.
Tarrataca
86 / 161

• Table needs to be 240 /210 = 230 entries;

• one for each of the ≈ 1 billion disk blocks

• Each entry needs a minimum of 30 bits:

• In order to properly identify the block;

• Thus the table requires a total of 230 × 30 ≈ 3GB...

• Conclusion: FAT does not scale well to large disks

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any any disadvantages with linked-list allocation

using a table in memory? Any ideas?

• When computer is shut down:

L.
87 / 161
Tarrataca

• Table must be stored in non-volatile memory;

• This implies disk acesses and writes;

• Table is only used to get the block number:

• Reading / Writing block still requires disk acesses and
writes;

Chapter 4 - File
 File System Implementing the
Implementation files

I-
Nodes

The previous methods had some problems...

How can we keep track efficiently of which blocks belong to which

file? Any ideas?
L.
88 / 161
Tarrataca

Our last method: I-nodes, short for index-node:

• Lists the attributes and disk addresses of the file’s

blocks

• Each i-node has a fixed position on the disk;

Chapter 4 - File
 File System Implementing the
Implementation files

I.nodes, short for index-node:

• Lists the attributes and disk addresses of the file’s blocks

• Given i-node, it is then possible to find all the blocks of

the file:

L.
89 / 161
Tarrataca

Figure: An example i-node. (Source: [Tanenbaum and Bos,

2015])
Chapter 4 - File
 File System Implementing the
Implementation files

How does this scheme compare against linked files using an in-
memory table? Any ideas?

L.

I.node needs be in memory only when the corresponding

90 / 161
Tarrataca

file is open:

• If each i-node occupies n bytes and k files may be open:

• Array holding the i-nodes for the open files is only kn bytes;

Chapter 4 - File
 File System Implementing the
Implementation files

I.node array:

• Usually far smaller than the space occupied by the file table
approach;

• Reason is simple:
• Table holding all disk blocks is proportional in size to the disk itself;
L.
Tarrataca
91 / 161

• If the disk has n blocks, the table needs n entries;

• As disks grow larger, this table grows linearly with them.

• In contrast, i-node scheme requires array size:

• Proportional to the maximum number of files that may be
open at once

Chapter 4 - File
 File System Implementing the
Implementation files

Can you see any problem with the i-nodes approach? Any
ideas?

If each i-nodes has room for a fixed number of disk

addresses:
L.
92 / 161
Tarrataca

What happens when a file grows beyond this limit? Any

ideas?

One solution: reserve the last disk address not for a data block:

• But for the address of a block containing more disk-block

addresses;

Chapter 4 - File
 File System Implementing the
Implementation files

What happens when a file grows beyond this limit? Any ideas?

One solution: reserve the last disk address not for a data block:

• but for the address of a block containing more disk-block

addresses;

L.
93 / 161
Tarrataca

Figure: An example i-node. (Source: [Tanenbaum and Bos,

2015])
Chapter 4 - File
 File System Implementing the
Implementation files

An even more advanced solution:

1 Two or more such blocks containing disk addresses;

2 Disk blocks pointing to other disk blocks full of

L.
Tarrataca
94 / 161

addresses; This is known as indirection blocks.

Chapter 4 - File
 File System Implementing the
Implementation files

L.
95 / 161
Tarrataca

Figure: Indirection blocks example (Source: [Tanenbaum and Bos,

2015])

Chapter 4 - File
 Multi Level
Indexing
• Block index has multiple levels

96
 File System Implementing Directo
Implementation ries

Implementing
Directories
Before a file can be read:

• File must be opened;

• OS uses the path name to locate the directory entry on the

disk:
• Directory entry provides information needed to find the disk
L.
Tarrataca
97 / 161

blocks:

• Depending on the system may be:

• Disk address of the entire file (with contiguous allocation);

• Number of the first block (both linked-list schemes);
• I-Node number;

• Main function of directory system is to:

• Map file name onto the information needed to locate the data.
Chapter 4 - File
 File System Implementing Directo
Implementation ries

Every file system maintains various file attributes

(1/3):

• E.g file’s owner and creation time;

• These attributes need to be stored

somewhere;

• One possibility: store them in the directory

L.
Tarrataca
98 / 161

entry:

Figure: Simple directory containing fixed-size entries with the disk addresses and attributes in the
directory entry. (Source: [Tanenbaum and Bos, 2015])

Chapter 4 - File
 File System Implementing Directo
Implementation ries

Every file system maintains various file attributes

(2/3):

Figure: Simple directory containing fixed-size entries with the disk addresses and attributes in the
directory entry. (Source: [Tanenbaum and Bos, 2015])
L.
99 / 161
Tarrataca

Directory consists of a list of fixed-size entries, one per file,

containing:

• A (fixed-length) file name;

• Attributes:
• Creator, Time, etc.

• File disk blocks

Chapter 4 - File
 File System Implementing Directo
Implementation ries

Every file system maintains various file attributes (3/3):

• Another possibility: for systems that use i-nodes:

• Store attributes in the i-nodes;

• Each directory entry can be shorter: {File name, I-node

number}

L. 100 /
Tarrataca 161

Figure: A directory in which each entry just refers to an i-node. (Source: [Tanenbaum and Bos,
2015])

Chapter 4 - File
Magnetic Disks

101
 Magnetic
Disks Tracks and Sectors in a platter

Structure of a magnetic disk

10
 Disk
Controllers
Processor Processor Processor Processor
1 2 3 4

front side bus

Memory bus Hard Disk

DRAM North Bridge
Controller
(SATA)
PCI Bus 0
us
DMI b
South Bridge PCI-PCI Ethernet USB
VGA
Bridge Controller Controller

Hard Disk PCI Bus 1

Controller
(ATA)
More
PCI
Legacy devices
Devices PS2
(keyboard, mouse,
PC speaker)

10
 Access
Time
• Seek Time
– Time it takes the head assembly to travel to the desired track
– Seek time may vary depending on the current head location
– Average seek time generally considered.(Typically 4ms high end
servers to 15ms in external drives)
• Rotational Latency
– Delay waiting for the rotation of the disk to bring the required disk
sector under the head
– Depends on the speed of the spindle motor
• CLV vs CAV

• Data Rate
– Time to get data off the
disk

10
 Disk
Scheduling
• Objectives Access time and bandwidth can be
– Access time managed by the order in which
Disk I/O requests are serviced
• Two components
– Minimize Seek time
– Minimize Rotational latency
– Bandwidth
• Bytes transferred / (total time taken)

• Reduce seek time by minimizing head

movement

10
 Disk
Scheduling
• Read/write accesses have the following cylinder
queue :
95, 180, 34, 119, 11, 123, 62, 64
• The current position of the head is 50
• FCFS Track number
time

Wild Oscillations

Total head movments = |(95 – 50)| + |(180 – 95)| + |(34 – 180)| + …

= 644
10
 Shortest Seek Time First
(SSTF) 95, 180, 34, 119, 11, 123, 62, 64
Starting at 50

Track number

Total head movments = 236

time

• Counterpart of SJF
• Could lead to starvation

10
 Elevators
95, 180, 34, 119, 11, 123, 62, 64at 50
Starting
SCAN
• Start scanning toward the nearest end
and goes till 0
• Then goes all the way till the other
end
Total head movements = 230
C-SCAN
• Start scanning toward the nearest end
and go till the 0
• Then go all the way to the other end
Total head movements = 187
•Useful if tracks accessed with uniform
distribution
•Shifting one extreme not included in
head movement count

11
 C-LOOK
• 95, 180, 34, 119, 11, 123, 62, 64
• Starting at 50
• Like C-SCAN, but don’t go to the extreme.
• Stop at the minimum (or maximum)

Total head movements = 157

11
Thank
you