CS 6560 Operating System Design

Lecture 13

Finish File Systems

Block I/O Layer

VFS File Objects and Structures• superblock object

– Represents an entire mounted filesystem

• inode object– Represents a particular file in a mounted filesystem

• file object– Represents an instance of an opened file

• dentry object– Represents a path component = name, indoe

• vfsmount– Represents a mount point

• file_system_type– Represents a filesystem type

Process Descriptor

Process Descriptor

Scheduling info

Process hierarchy info

filesfs

mmsig

…

signal_struct

fs_struct

files_struct(Open Files)

mm_struct(Memory Descriptor)

fs_struct

• This table specifies the dentry objects of the process’ root and current directory.

• It also contains the process’ umask (a bit mask used to automatically turn off permissions when creating files).

Process Descriptor’s fs_struct

Process Descriptor

Scheduling info

Process hierarchy info

filesfs

mmsig

…

fs_struct

dentry object

dentry object

superblock object

superblock object

vfsmountstructure

vfsmountstructure

root

current

files_struct

• This table specifies the opened files of a process• It contains a pointer to an array of file objects,

indexed by the file descriptor, returned from creating the file or inherited.

• It contains bit maps to indicate which file objects are active and which are to be closed on exec.

• It also contains the current and max number of file objects and the number of processes sharing this table.

Open Files of a Process

Process Descriptor

Scheduling info

Process hierarchy info

filesfs

mmsig

…

files_struct(Open Files)

fd

file object dentry object inode object

file object dentry object inode object

file object dentry object inode object

file object dentry object inode object

…

open files

(has f_pos)

directory

link

represents

actual files

Relationships• The open files table may be shared by several processes. This happens

when processes share their address space (threads).

• Each open files table has a list of open files (file objects), indexed by file descriptor (returned from opening the file)

• Each open file (file object) can be shared by several open files tables and hence by several processes. This happens when a process forks. Parent and child share the same open files.

• Each open file (file object) has one dentry object.

• Each dentry object can be shared by several file objects. This happens with dup and some redirection.

• Each dentry object has one inode object.

• Each inode object can be shared by several dentry objects. This happens because of hard and symbolic links.

• Each inode has one superblock object, making it belong to one mounted filesystem.

file_system_type objects

• The system maintains a (linked) list of valid file types. Each file type is represented by a file_system_type object.

• This object has a name for the file system type.• This object has a method for creating a superblock

object. • It also points to the module that governs this file

type (if modulerized)• This object heads a list of superblock objects that

belong to this file type.

File system types

The file_system_type Structure

struct file_system_type { struct super_block *(*read_super) (struct super_block *, void *, int); const char *name; int requires_dev; /* there's a linked list of types */ /* struct file_system_type * next; /*}

Mounted Filesystems by Type

File_system_typeobject

superblockobject

superblockobject

File_system_typeobject

superblockobject

superblockobject

File_system_typeobject

superblockobject

superblockobject

dentry

of mount

dentry

of mount

dentry

of mount

dentry

of mount

dentry

of mount

dentry

of mount

Block I/O

Block and Character Devices

• Character device– Provides a stream of byte-sized data- – Examples: keyboards and serial ports

• Block device– Provides random access to blocks of data– Example: hard disks and CDROMs

Physical Organization of Block Devices

– Physically organized in cylinders, tracks, and sectors

• Cylinder = one position of read/write head • Sector = one unit of data• Linear array of cylinders on device• 2D array of sectors in each cylinder• Takes a long time to move read/write head among

cylinders (This is called head seeking.)• Takes a shorter time to wait for sector transfer

within cylinder.

Abstraction of Block Devices

• The kernel abstracts block devices with an “one size fits all” approach.

Components of the FS

VFS

EXT2 VFAT NFSEXT3 NTFS proc

Buffer Cache

Disk Driver Disk Driver

DirectoryCache

InodeCache

Sectors, Blocks, Pages

• Data granularity for physical devices, their common abstraction in the kernel, and the virtual memory management are:– Sector = granularity of data on block device– Block = granularity of data for kernel

abstraction of block devices (must be a multiple of sector size)

– Page = granularity of data for virtual memory (must be a multiple of block size)

Buffer Heads

• The block I/O system of the kernel maintains a pool of buffer that are described by structs called buffer heads.

• Each buffer head serves as the representation of one block. It is a data structure that has fields for– State - bit flags in a long int (see page 238)– Usage counter– Reference to a page of virtual memory– Logical block number– Block size– Pointer to the data in the block– Pointer to a structure that represents the device where the block is stored– And more

• In previous versions of Linux, buffer heads were the primary unit for handling buffer I/O.

The bio structure

• With Linux 2.5 the basic container structure for block I/O is the bio.

• Each bio structure represents on I/O request (read a block or write a block to storage device)

• The bio structures are organized in linked lists• The bio structure contains

– Sector identification– Reference to the next bio structure in the list– Reference to the structure representing the storage device– Status and command flags as bits in an unsigned int– Operation (read or write)– Management data

New and Old

• See page 242 for comparison

Request Queues

• Block devices maintain request queues

• Each request is represented by a structure (called request) that references a set of bio structures.

I/O Scheduling

• The I/O scheduler merges and sorts requests to give optimal performance. (minimizing head seeks).

• Job of scheduler (See page 244)– Goals: optimal global throughput

• Minimize head seeks

– Operations: merge and sort

Linux Schedulers

• Linus Elevator (Linux 2.4)

• Four scheduler available in Linux 2.6– Deadline Scheduler– Anticipatory I/O Scheduler– Complete Fair Queuing I/O Scheduler– Noop Scheduler