Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
An overview of file systems, discussing how to implement file system abstraction on top of raw disks, approaches to organizing file blocks such as contiguous allocation, linked list allocation, and indexed files, and the unix file header (i-node) and naming and directories. It also covers topics such as protection, performance issues, and access control.
Typology: Slides
1 / 14
This page cannot be seen from the preview
Don't miss anything!
n How to find the blocks of data corresponding to a given file? n How to organize files? n How to enforce protection?
n Try to keep related information together on the disk
n Contiguous allocation n A file is stored on a contiguous set of blocks n Prevents incremental growth and complicates allocation n Linked list allocation n A file header points to the first block of the file n Each block of the file points to the next block n If blocks are dispersed across disk Ë horrible performance for both sequential access and random access n Random access can be made faster by separating the next block pointers from the data and storing it at a centralized place (FAT) n Indexed files n File header stores pointers to file blocks n Multi-level indexing required for large files
n 10 direct pointers n 11: 1-level indirect n 12: 2-level indirect n 13: 3-level indirect
n In favor of small files n Can grow n Limit is 16G (assuming 1K blocks)
1 2
data
data
11 12 13 data
n Use index (ask users specify inode number). Easier for system, not as easy for users. n Text name (need to map to index) n Icon (need to map to index; or map to name then to index)
n Directory map name to file index (where to find file header) n Directory is just a table of file name, file index pairs.
n Each directory is stored as a file, containing a (name, index) pair. n Only OS permitted to modify directory
n put directory at known location on disk n directory contains <name, index> pairs n if one user uses a name, no one else can n many older personal computers work this way.
n still clumsy. And ls on 10,000 files is a real pain
n allow directory to map names to files or other dirs n file system forms a tree (or graph, if links allowed) n large name spaces tend to be hierarchical (ip addresses, domain names, scoping in programming languages, etc.)
n Unix picked up and used really nicely.
n inode contains special flag bit set n users can read just like any other file n only special programs can write
n file pointed to by the index may be another directory n makes FS into hierarchical tree (what is needed to make a DAG?)
n Root directory n inode #2 on the system n 0 and 1 used for other purposes
n Root directory: “/” (bootstrap name system for users) n Current directory: “.” n Parent directory: “..”
n Data blocks n File headers n Directories n File system superblocks
n Hard and soft links n Permissions
n Unix stores count of pointers (“hard links”) to inode
n to make: “ln foo bar” creates a synonym (‘bar’) for ‘foo’
n also point to a file (or dir), but object can be deleted from underneath it (or never even exist). n normal file holds pointer to name, with special “sym link” bit set
n When the file system encounters a symbolic link it automatically translates it (if possible).
n Prevent accidental and maliciously destructive behavior n Ensure fair resource usage
n Policy : what is to be done n Mechanism : how something is to be done
n Access/usage rights associated with particular domain n Example: user/kernel mode Ë two domains n Unix: each user is a domain; super-user domain; groups of users (and groups)
n For files: read/write/execute n For directories: list/modify/delete n For access rights themselves n Owner (I have the right to change the access rights for some resource) n Copy (I have the right to give someone else a copy of an access right I have) n Control (I have the right to revoke someone else’s access rights)
Process control block
Open file pointer array
Open file table (systemwide)
File headers (Metadata)
File headers
File system info
Directories
File data
n File name lookup and authenticate
n Copy the file descriptors into the in-memory data structure, if it is not in yet
n Create an entry in the open file table (system wide) if there isn’t one
n Create an entry in PCB
n Link up the data structures
n Return a pointer to user
Open file table
Metadata
Allocate & link up data structures
File name lookup & authenticate
Open file table
Metadata
Find open file descriptor
Logical → phyiscal
Get physical block to sysBuf copy to userBuf
Disk device driver
Buffer cache
n From “fd” find the file pointer; n Based on the file system block size (let’s say 1 KB), find the blocks where the bytes (file_pointer, file_pointer+length) lies; n Read the inode n For (each block) { n If the block is new, allocate a new disk block; n Based on the block no, enter the block’s address to the appropriate places in the inode or the indirect blocks; (the indirect blocks are allocated as needed) n Copy the bytes in buffer to the appropriate location in the block } n Change the file size field in inode if necessary
