Disk Cache Main memory buffer contains most recently accessed disk sectors Cache is organized by blocks, block size = sector’s A hash table is used to give O(1) access to a disk sector Cache replacement algorithm: LRU Disk cache competes for memory with user processes and kernel On some systems, cache size may be variable, and blocks are taken from the main memory list

Cache Operation: Read Read: Sector in cache? Copy the data from cache, else find a free cache block if no free cache block pick the block in LRU order, if modified, write it to disk Schedule a read from disk sector into cache block copy data from cache

Cache Operation: Write Two major policies: Write through Write back (or write behind) In write back: If sector is in cache, write to it Else, allocate a free frame (like in the Read case) Write to the cache block In write through: Add Schedule a write to disk

Data Structures Hash Table Cache blocks Free block list LRU List

Cache Block Bits M B S U M: Modified B: Busy (I/O pending) S: Semaphore (multithreaded kernels) U: Used bit

Additional File System Structures To support and simplify file system operation: Keeping track of open files globally/per process Concurrency control information To allow a client to access files seamlessly, regardless of where they are or what they are Ability to mount file systems on demand Management of resource usage: Quotas Unconventional file access: Memory-mapped file

Per-Process Open File Table For each process, we allocate a table an entry is allocated for each open file entry contains: current read/write pointer Used to track where the next read/write operation occurs access mode: read/write/append Used to enforce access mode restrictions an index into a global open file table Used to access the actual information about the file

Global File Table A system-wide table such that: An entry is allocated for each open table entry contains: How to locate the file? (e.g. pointer to inode) Information about the file itself (e.g. text vs. binary) Number of processes that have the file open Concurrency control information (e.g. read/write locks) Permissions

Concurrency Control Information If several processes are having the file open simultaneously, then: We may have: read-write conflicts write-write conflicts write-read conflicts

Solutions Do nothing: It is up to the applications to synchronize Pretend to do something: Advisory locks Two calls (lock/unlock) read/write/range Independent of the files themselves To work, it is up to the processes to adhere to the discipline of using these locks A process may read or write from a “locked” file

Solutions (Cont’ed) Use real locks: In GOFT, include information about ranges of the locks locking types (read/write) owners of locks Each read/write operation on the file is checked against the locks File system enforces the locking mechanism Independent processes can safely share the files Implementation issues: Overhead/complexity/network

Seamless File Access A file system name space may span: different disks different machines We may need to reorganize the file system on disk/machines We may need to add more disk space/disks/… User program should not know about any of this!!!

File System Mounting mount point

Virtual Node Layer Client file system uses vnode as much as it would use inodes Abstract file location & details of access Virtual Node Layer Special device Local disk 1 Network file system Local disk 0

Logical Volumes A layer that abstracts the low-level devices No notion of disks or location visible above that layer, just an array of blocks A logical volume manager (LVM) implements and optimizes the abstraction underneath A logical volume can: span multiple disks be replicated for performance or availability increased/decreased in size

Quotas To control and account for disk usage (necessary to keep accountants and lawyers employed) Example: UNIX Administrator may impose two limits Number of files/user Total size of disk space charged/user Each limit has two variants: Soft Hard

Quota Operation During a login session, user may exceed his soft limits (allows files to grow beyond soft limits within session, for flexibility) A warning is issued if user logs out after exceeding his soft limits After several warnings, account is disabled User may never exceed hard quota limits Quotas may lead to funny problems.

Quota Implementation Global Open File Table File entry Number of files, size of files, soft file limit, soft size limit, hard file limit, hard size limit File entry File creation and appending must go through user quota table User quota table

Memory-Mapped Files Instead of open/read/write interface, the file is mapped directly into user space Why? Flexibility: can store complex data structures on disk Performance: No need to cross the open/read/write interface No data copying Can share information through files without too much overhead

Implementation Issues A file can be opened through the conventional interface, yet mapped by another processes How to reflect updates done through each interface so that both are consistent and coherent? How to reflect updates if several processes are mapping the file simultaneously? How about locking? What about if a file is truncated while it is being mapped?

A Solution Process Page Table Hash Table Cache blocks

Possible Restrictions File blocks must be aligned on page boundaries in disk cache in process map If the file shrinks or grows: Don’t reflect on process maps (they may continue to use the stale data) Allow processes to map files in different modes: private versus shared maps anonymous regions