How are file systems implemented? • How do we represent CSCI [4|6]730 – Directories (link file names to file “structure”) – The list of blocks containing the data Opera2ng Systems – Other informa2on such as access control list or permissions, owner, 2me of access, etc? File System: Implementa2on • How can we be smart about the layout? Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA File System Design Mo2va2on (cont) File System Design Mo2va2ons • Access pacerns: • Workloads influence design of file system – Sequen2al: Data in file is read/wricen in order • File characteris2cs (measurements of UNIX and • Most common access pacern – Random (direct): Access block without referencing the predecessor NT): block • Difficult to op2mize – Most files are small (about 8KB) – Access files in same directory together • Block size can’t be too big (why not?) • Spa2al locality • Is this s2ll true? Why? – Access meta-data (i-node, FCB) when access file – BUT - Most of the disk is allocated to large files • Need meta-data to find data • (90% of data is in 10% of number of files) • Large file access should be reasonable efficient. • Support various file access pacerns… Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA
File Opera2on Implementa2on File Opera2on Implementa2on • Seek: Reposi2oning within a file: • Create a file: – Find space in the file system, and add a directory entry. – Directory searched for appropriate entry & current file • Wri2ng in a file: posi2on pointer is updated (also called a file seek ) – System call specifying name & informa2on to be wricen. • Dele2ng a file: • Given name, system searches directory structure to find file. System keeps write pointer to the loca2on where next write occurs, upda2ng as writes are performed. Update meta-data. – Search directory entry for named file, release associated file • Reading a file: space and erase directory entry – System call specifying name of file & where in memory to s2ck contents. • Trunca2ng a file: Name is used to find file, and a read pointer is kept to point to next read posi2on. (can combine write & read to current file posi3on pointer ). Update meta-data. – Keep acributes the same, but reset file size to 0, and reclaim file space. Thought Questions : How should files be accessed on reads and writes? How can we avoid reading/searching directory on every read/write access? Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Opening Files • Observa2on: Expensive to access files with full pathnames • Need to caches open file pointers – On every read/write opera2on: • Traverse directory structure – HINT: we have file descriptors in UNIX, it is a reason for this. • Check access permissions • How do we do this procedurally? • Idea!: Separate open() before first access – User specifies mode: read and/or write – Search directories once for filename and check permissions – Copy relevant meta-data to system wide open file table in memory – Return index in open file table to process (file descriptor) – Process uses file descriptor to read/write to file • Mul2-process support: via a separate per-process-open file table where each process maintains – Current file posi2on in file (offset for read/write) – Open mode Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA
Example: Accessing Files Mul2-Process File Access Support (Steps via open() ) 1. Search directory structure (part • Two level of internal tables: may be cached in memory) user space kernel space disk space 2. Get meta-data, copy (if needed) – Per-process open file table into system-wide open file table • Tracks all files open by a process (process-centric directory structure 3. Adjust count of #processes that open( *filename ) informa2on): have file open in the system ‘in-core’ directory structure file meta-data – Current posi2on pointer (on read/write) where did it read/ wide table. write last, and access Rights disk space user space kernel space 4. Entry made in per-process open – Indexes into the system-wide table for other info. file table, w/ pointer to system – System-wide open file table file data blocks wide table read( fd ) • Process Independent informa2on per-process system-wide 5. Return pointer to entry in per- file meta data open file table open file table – Loca2on of file on disk process file table to applica2on – Access dates, file size – File open count (# processes accessing file) Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Goals Alloca2on Strategies • Progression of different approaches (reminiscent of memory • OS allocates logical block numbers (LBN) to meta-data, file data, structure ‘progression’ of approaches) and directory data – Con2guous – Workload items accessed together should be close in LBN space – Extent-based • Implica2ons – Linked – Large files should be allocated sequen2ally – File-Alloca2on Tables – Files in same directory should be allocated near each other – Indexed – Data should be allocated near its meta-data – Mul2-level Indexed • Meta-Data: (though ques2on) Where is it (or should it be) stored • Ques2ons/Issues: on disk? – Amount of fragmenta2on (internal and external)? – Embedded within each directory entry – Ability to grow file over 2me? – Seek cost for sequen2al accesses? – In data structure separate from directory entry – Speed to find data blocks for random accesses? • Directory entry points to meta-data – Wasted space for pointers to data blocks? Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA
Con2guous Alloca2on Extent-Based Alloca2on • Allocate mul2ple con2guous regions (extents) per file (e.g., Veritas File • Allocate each file to con2guous blocks on disk System). – Meta-data: (1) Star2ng block and (2) size of file (base & bound) – Meta-data: Small array (2-6) designa2ng each extent – OS allocates by finding sufficient free space • Each entry: star2ng block and size • Must predict future size of file; Should space be reserved? – Examples: IBM OS/360, CDROMS, DVDs. • Improves con2guous alloca2on • Advantages: – File can grow over 2me (un2l run out of extents) – Licle overhead for meta-data – Helps with external fragmenta2on – Excellent performance for sequen2al accesses • Advantages: – Simple to calculate random addresses – Limited overhead for meta-data • Disadvantages: – Very good performance for sequen2al accesses Horrible external fragmenta3on (Requires periodic compac2on) – – Simple to calculate random addresses – May not be able to grow file without moving it • Disadvantages (Small number of extents): • Solu2on: Extends -- pointer to extent(s) in meta-data (i-node)… See next – External fragmenta2on can s2ll be a problem – Not able to grow file when run out of extents A A A E E B B B B C C C D A A A D D B B B B C C C B B Free E A A A B B B B C C C Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Linked Alloca2on File-Alloca2on Table (FAT) • Allocate linked-list of fixed-sized blocks • Varia2on of Linked alloca2on (e.g., MS-DOS, OS/ 0 2) – Meta-data: Loca2on of first (fixed size) block of file 1 2 10 – Keep linked-list informa2on for all files in on-disk File A starts here • Each block also contains pointer to next block 3 11 FAT table – Examples: TOPS-10, Alto 4 7 File B starts here – Meta-data: Loca2on of first block of file 5 • Advantages: 6 3 • And then lookup rest in FAT table 7 2 No external fragmenta2on – – FAT located at beginning of each par22on 8 – Files can be easily grown, with no limit 9 • indexed by block number • Disadvantages: 10 12 • entry contains block number of next entry 11 14 Cannot calculate random addresses w/o reading previous blocks – 12 -1 • Comparison to Linked Alloca2on 13 – Sequen2al bandwidth may not be good 14 -1 – Advantage: Random access improved because disk • Try to allocate blocks of file con2guously for best performance 15 Reliability - loose pointer (1) cluster blocks (2) user double linked list head can read loca2on in FAT – • Trade-off: Block size (does not need to equal sector size) – Disadvantage: Read from two disk loca2ons for File A: Links of Physical Blocks every data read (FAT + actual block) – Larger ⇒ ?? , Smaller ⇒ ?? [Thought Ques2on] 4 7 2 10 12 – Op2miza2on: Cache FAT in main memory • Advantage: Greatly improves random accesses • S2ll very hard to access random file blocks ): File B: Links of Physical Blocks 6 3 11 14 D D A A A D B B B B C C C B B D B D Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA Maria Hybinette, UGA
Recommend
More recommend
