1. CS 6560 Operating System Design Lecture 13 Finish File Systems Block I/O Layer

2. 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

3. Process Descriptor Scheduling info Process hierarchy info files fs mm sig … signal_structfs_structfiles_struct (Open Files) mm_struct (Memory Descriptor)

4. 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).

5. Process Descriptor’s fs_struct Process Descriptor Scheduling info Process hierarchy info files fs mm sig … fs_struct dentry object superblock object vfsmount structure vfsmount structure root current

6. 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.

7. Open Files of a Process Process Descriptor Scheduling info Process hierarchy info files fs mm sig … files_struct (Open Files) fd file object dentry objectinode object file object dentry objectinode object file object dentry objectinode object file object dentry objectinode object … open files (has f_pos) directory link represents actual files

8. 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.

9. 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.

10. 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; /* }

11. Mounted Filesystems by Type File_system_type object superblock object superblock object File_system_type object superblock object superblock object File_system_type object superblock object superblock object dentry of mount dentry of mount dentry of mount dentry of mount dentry of mount dentry of mount

12. Block I/O

13. 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

14. 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.

15. Abstraction of Block Devices The kernel abstracts block devices with an “one size fits all” approach.

16. Components of the FS VFS EXT2VFATNFSEXT3NTFSproc Buffer Cache Disk Driver Directory Cache Inode Cache

17. 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)

18. 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.

19. 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

20. New and Old See page 242 for comparison

21. Request Queues Block devices maintain request queues Each request is represented by a structure (called request) that references a set of bio structures.

22. 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

23. 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