Simplified File System CS 3SH3: Operating Systems Concepts

Simplified File SystemCS 3SH3: Operating Systems Concepts Husam Ibrahim Taghreed Al Ramahi CS 3SH3 - Operating System Concepts - Winter 2006 (McMaster University)

Outline • Motivation • Structure • How it all works • Limitations • Questions

Motivation • Every user is unique • Some users store mostly large files • E.g. A user with many media files • Others store mostly small files • E.g. A company computer used for tracking databases • If most files are large, there will be few files • Need only a few inodes • If most files are small, there will be many files • Need many inodes

Why not fixed inodes? • With N fixed inodes • Assumes the number/size of files user needs • If N is too small • Users who create mostly small files will run out of inodes • If N is too big • Users who create mostly large files will have empty inodes wasting space

Solution? • Our design allocates inodes dynamically • Every time a file is created, an inode is allocated to it • Very flexible • Also works well for users that have a mix of small and large files • Maximum utilization of available space

StructureSuperblock • Uses a bit vector • Each block is represented by one bit • Uses an array of type char • Char disk_bitmap[512] uses exactly 512 bytes • Each 4 bits are grouped into a number between 0 and 15 • The compressed array is also of type char • This results in an array of exactly 128 bytes • Can fit in one block!

StructureiNode Table • First 2 bytes used for File Pointer • File pointer is part of the inode • Each block index uses 2 bytes • Six direct indices • Next 14 bytes used for direct block indexing • An entire inode takes up 16 bytes • Can have 128/16 or 8 inodes per disk block

StructureiNumbers • Virtually every block can contain either an inode or data • If it contains an inode, how do we differentiate between them? • Need a universal inumber scheme • Since each block can contain up to 8 inodes, there are 512x8 or 4096 possible iNumbers • E.g. Where is inode w/ inumber 210? • 210/8 = 26 R 2 • It is the 3rd Inode in Block #26 • Inumber-to-block-number translation handled by simple division and modulus operations

StructureDirectories • First 2 bytes are for the inumber of the entry • Next 6 bytes are for the Filename • Final byte is always null character • Each entry takes up 8 bytes • Can fit 128/8 or 16 bytes in a block

StructurePathname Parsing • Pathnames are parsed in a similar way to given model • As the name is read, it is placed into a 2D array. • E.g. /new/file is parsed into

Normal Operation • When the system is newly initialized (and under any other condition), the following blocks are always occupied: • Block #0: Superblock • Block #1: Inode of Root Dir and next 7 files • Block #511: Directory Data of Root Dir

How it Works… • When a file is created • The system calls empty_inode_search to get an inode • All the inode tables are searched (starting from the first) • If an empty one is found, its inode number is returned • The system then calls get_empty_block to get a new data block for it • Note: get_empty_block has an extra argument for direction • 1 From the top • 0 From the bottom • For an inode table, it uses 1 • For a data block, it uses 0

How it Works…(cont’d…) • This ensures that inode tables and data blocks don’t overlap • If the inode that is returned is the last one in its table, a new table is created in the next block • Therefore, as long as there’s space, empty_inode_search will always find a free inode • This will continue until disk is full

Limitations(Number of Files) • If the system consists of small files only • Each block holds 8 inodes • Each inode occupies 1/8th of a block • Each data block occupies 1 block • So when it’s full, the system can hold 454 files/directories consisting of one data block each

Limitations(Number of Files cont’d…) • If the system consists of large files only • Each file has 7 data blocks • So when it’s full, the system can hold 71 files/directories consisting of one data block each • The average case is somewhere between there • Still >150 files

Limitations(Other limitations) • File size • Maximum file size = • Number of Files Open Simultaneously • Limited by amount of memory allocated to file descriptor array. • Currently set to 128, but easily changeable. • Maximum Number of Directory Entries • Each directory (like a file) can have up to 7 direct address blocks. • Each directory data block can hold up to 16 entries. This means that each directory can hold up to 112 entries. • Block-boundary crossing is allowed

XFS • Are there any file systems similar to this in practice? • In 1996, SGI came up with XFS [1] • Focused on Scalability [1] • Dynamic inode allocation, logging volume manager, … [1] • Inodes are placed closer to files • Facilitates greater performance [2]

Different Unix File Systems [2]

Experience & Improvements • Experience • Found modularization to be very helpful • Spending more time/thorough testing of lower level libraries paid off • Future Improvements • Learn about other File Systems used in Unix • Provide tutorials earlier • Makefiles • Linux • Design proposal instead of documentation specifications

Any Questions?

Resources • [1] http://infohost.nmt.edu/~val/fs_slides.pdf • [2] http://www.uoks.uj.edu.pl/resources/flugor/IRIX/xfs-whitepaper.html

Simplified File System CS 3SH3: Operating Systems Concepts