1. 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

2. 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

3. 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

4. Data Structures
Hash Table
Cache blocks
Free block list
LRU List

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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. 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!!!

13. File System Mounting
mount point

14. 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

15. 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

16. 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

17. 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.

18. 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

19. 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

20. 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?

21. A Solution
Process Page Table
Hash Table
Cache blocks

22. 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