How are file systems implemented? How do we represent CSCI - PDF document

How are file systems implemented? � � How do we represent CSCI [4|6]730 » � Directories (link file names to file “structure”) Operating Systems » � The list of blocks containing the data » � Other information such as access control list or permissions, owner, time of access, etc? File System: Implementation � � How can we be smart about the layout? 2 Maria Hybinette, UGA Maria Hybinette, UGA File System Design Motivations File System Design Motivation (cont) � � Access patterns: � � Workloads influence design of file system » � Sequential: Data in file is read/written in order � � File characteristics (measurements of UNIX and – � Most common access pattern NT): » � Random (direct): Access block without referencing predecessors » � Most files are small (about 8KB) – � Difficult to optimize – � Block size can’t be too big (why not?) » � Access files in same directory together » � Most of the disk is allocated to large files – � Spatial locality – � (90% of data is in 10% of files) » � Access meta-data (i-node, FCB) when access file – � Need meta-data to find data – � Large file access should be reasonable efficient. � � Support various file access patterns… 3 4 Maria Hybinette, UGA Maria Hybinette, UGA File Operation Implementation File Operation Implementation � � Repositioning within a file: � � Create a file: » � Directory searched for appropriate entry & current file position » � Find space in the file system, add directory entry. pointer is updated (also called a file seek ) � � Writing in a file: � � Deleting a file: » � System call specifying name & information to be written. Given name, system searches directory structure to find file. System » � Search directory entry for named file, release associated file keeps write pointer to the location where next write occurs, space and erase directory entry updating as writes are performed. Update meta-data. � � Truncating a file: � � Reading a file: » � Keep attributes the same, but reset file size to 0, and reclaim file » � System call specifying name of file & where in memory to stick space. contents. Name is used to find file, and a read pointer is kept to point to next read position. (can combine write & read to current file position pointer ). Update meta-data. Thought Questions : How should files be accessed on reads and writes? How can we avoid reading/searching directory on every read/write access? 5 6 Maria Hybinette, UGA Maria Hybinette, UGA

Multi-Process File Access Opening Files Support � � Observation: Expensive to access files with full pathnames � � Two level of internal tables: » � On every read/write operation: » � Per-process open file table – � Traverse directory structure – � Check access permissions – � Tracks all files open by a process (process- � � Solution: open() file before first access centric information): » � User specifies mode: read and/or write � � Current position pointer (read/write), access » � Search directories once for filename and check permissions Rights � � Index in system-wide table » � Copy relevant meta-data to system wide open file table in memory » � Return index in open file table to process (file descriptor) » � System-wide open file table » � Process uses file descriptor to read/write to file – � Process Independent information � � Multi-process support: via a separate per-process-open file table � � Location of file on disk where each process maintains � � Access dates, file size » � Current file position in file (offset for read/write) � � File open count (# processes accessing file) » � Open mode 7 8 Maria Hybinette, UGA Maria Hybinette, UGA Example: Accessing Files (via Open) Goals � � Search directory structure (part may be cached in � � OS allocates logical block numbers (LBN) to meta-data, user space kernel space disk space memory) file data, and directory data � � Get meta-data, copy (if directory structure » � Workload items accessed together should be close in LBN open( *filename ) � needed) into system-wide space open file table ‘in-core’ directory structure file meta-data � � Implications � � Adjust count of #processes user space kernel space disk space » � Large files should be allocated sequentially that have file open » � Files in same directory should be allocated near each other � � Entry made in per-process file data blocks open file table, w/ pointer to read( fd ) � » � Data should be allocated near its meta-data per-process system-wide system wide table file meta data open file table open file table � � Meta-Data: Where is it stored on disk? � � Return pointer to entry in » � Embedded within each directory entry per-process file table to » � In data structure separate from directory entry application – � Directory entry points to meta-data 9 10 Maria Hybinette, UGA Maria Hybinette, UGA Allocation Strategies Contiguous Allocation � � Allocate each file to contiguous blocks on disk � � Progression of different approaches » � Meta-data: Starting block and size of file (base & bound) » � OS allocates by finding sufficient free space » � Contiguous – � Must predict future size of file; Should space be reserved? » � Extent-based » � Examples: IBM OS/360, CDROMS, DVDs. » � Linked � � Advantages: » � File-allocation Tables » � Little overhead for meta-data » � Indexed » � Excellent performance for sequential accesses » � Simple to calculate random addresses » � Multi-level Indexed � � Disadvantages: � � Questions » � Horrible external fragmentation (Requires periodic compaction) » � Amount of fragmentation (internal and external)? » � May not be able to grow file without moving it » � Ability to grow file over time? – � Solution: Extends -- pointer to extent(s) in inode » � Seek cost for sequential accesses? A A A E E B B B B C C C » � Speed to find data blocks for random accesses? » � Wasted space for pointers to data blocks? Free E A A A B B B B C C C 11 12 Maria Hybinette, UGA Maria Hybinette, UGA