Non-volatile storage is much slower than DRAM, also, access must be done in coarse grained units, 512 bytes or more at a time.
\nGoal: High performance
\nGoal: Named data
\nGoal: Controlled Sharing
\nGoal: Reliable Storage
\nAn OS abstraction that provides persistent named data.
\nCreate() creates a new file that has initial metadata but no other data and it creates a name for the file in a directoryLink() creates a hard link(new path name for existing file). After calling link(), there should be multiple path names that refer to the same underlying file. You cannot call link() on a directoryUnlink() removes a file from its directory. If there are multiple links to a file, unlink() removes the specified name. If there is only one link to a file, unlink() also deletes the underlying file and frees the resources.mkdir() and rmdir() creates and deletes directories.open() a process calls open() to get a file descriptor it can use to refer to the open file.close() releases the open file record in the OSread() starts from the process’s current file position and advances it by the number of bytes successfully read or written. Reads byteswrite()starts from the process’s current file position and advances it by the number of bytes successfully read or written. Writes bytesseek() changes a process’ current position for a specified open filemmap() establish a mapping between a region of the process’s virtual memory and some region of the file so that memory loads and stores to that virtual memory region will use the kernel’s file cache or triggers a Page fault exception which causes the kernel to fetch the desire page from the file system to memorymunmap() remove mapping created by mmap()fsync() Ensures all pending updates for a file are written to persistent storage before the call returns. Used to ensure that updates are durable and will not be lost in case of crash. If fsync() is called twice, the first is written to persistent storage before the second.Application libraries wrap syscalls mentioned above in the file system API to add additional functionality such as buffering.
\nSince storage devices are much slower than DRAM, the OS has a block cache that caches recently read blocks and buffers recently written blocks.
\nWhen a process reads the first two blocks of a file, the OS may prefetch the first 10 blocks. When the predictions are accurate, it can reduce latency from future reads(by returning the contents in the cache), reduce device overhead(by replacing a large number of small requests with one large one), and improve parallelism(by allowing hardware to process multiple requests at once in parallel).
\nSome disadvantages of prefetching include cache pressure(each prefetched block might displace another block in the block cache which might be more useful), I/O contention(prefetching costs IO, other requests might need to wait behind prefetch requests), and wasted effort(the prefetched blocks are not actually used).
\nMotivation: How do we go from a file name and offset to a block number?\nNaive Approach: The file system is a dictionary that maps keys(file name and offset) to values(block number)
\nMost file systems have directories, index structures, free space maps, and locality heuristics.
\n/home/albert/hi.txt we search the root directory by reading the file associated with file number 2. In file2 , we search for the name home and find that /home is stored in file number 880. In file 880, we search for the name albert and find /home/albert is stored in 526. In file 526, we search for hi.txt, we find /home/albert/hi.txt is in file number 469mkdir, link, unlink, and rmdir. Mkdir and rmdir create and delete the directory, link(\"hi.txt\", \"new.txt\") creates a hard link to an existing file, unlink(\"hi.txt\") removes that hard link.link() increases the reference count by 1 and each call to unlink() decreases the reference count by 1Purpose: Translate a file number to the blocks that belong to the file\nGoals:
\n| File System | \nIndex Structure | \nFree Space Management | \nLocality Heuristics | \nIndex Structure Granularity | \n
|---|---|---|---|---|
| FAT(USB drives) | \nLinked List | \nFAT array | \nDefragmentation | \nBlock | \n
| FFS(Unix) | \nTree(fixed, assymmetric) | \nBitmap(fixed) | \nBlock groups, reserve space | \nBlock | \n
| NTFS(Windows) | \ntree(dynamic) | \nBitmap in file | \nBest fit, defragmentation | \nExtent | \n
| ZFS(Copy on write) | \ntree(copy on write, dynamic) | \nSpace map(log-structured) | \nWrite anywhere, block groups | \nBlock | \n
Techniques FFS uses a carefully structured tree that locates any block of a file that is efficient for both large and small files. Each file is a tree with fixed size blocks as its leaves. Each file’s tree is rooted in an inode that contains the file metadata.
\nLocality Heuristics FFS uses block group placement and reserved space
\nblock group placement divides the disk into block groups so the seek time between any blocks in a block group will be small
\n\nInstead of using fixed trees like FFS, NTFS uses extents and flexible trees
\n\nFour stages of file growth
\nWhen updating an existing file, COW file systems do not overwrite existing data or metadata, instead, they write new versions to new locations.
\nMotivations
\nSince old data isn’t overwritten, we can support versioning
\n\nGoal: Read the file /foo/bar/baz\nSteps:
\n/ to determine /foo’s inumber/foo has inumber 231/foo’s inumber, we read inode 231 to find where /foo’s data blocks are stored-block 1094 in this example./foo directory to find that the directory file /foo/bar has inumber 731./foo/bar’s inode and data block 30991 to find /foo/bar/baz’s inumber is 402/foo/bar/inode to get the data blocks 89310, 14919, 23301