fs-caching
fs-caching
File system
etc bin sbin home lib SSD
layer
code file.txt
Others
fd = open(“/home/user/test.c”, O_RDWR);
File system and caching
- Accessing data and metadata from disk impacts performance
- Many file operations require multiple block access
- Examples:
- Opening a file
fd = open(“/home/user/test.c”, O_RDWR);
/home/user$ ls
File system and caching
- Accessing data and metadata from disk impacts performance
- Many file operations require multiple block access
- Executables,
Examples: configuration files, library etc. are accessed frequently
- Many directories
- Opening a filecontaining executables, configuration files are also accessed
very frequently. Metadata blocks storing inodes, indirect block pointers are
fd = open(“/home/user/test.c”, O_RDWR);
also accessed frequently
- Normal shell operations
/home/user$ ls
File system and caching
- Accessing data and metadata from disk impacts performance
- Can
Manywefilestore frequently
operations accessed
require diskblock
multiple data in memory?
access
- - What is the storage and lookup mechanism? Are the data and metadata
Examples:
- caching
Openingmechanisms
a file same?
- Are there any complications because of caching?
fd = open(“/home/user/test.c”, O_RDWR);
- How the cache managed? What should be the eviction policy?
- Normal shell operations
/home/user$ ls
Block layer caching
Cached I/O - Lookup memory cache using the
block number as the key
User processes
- How does the scheme work for data
read, write, stat
and metadata?
File system
lookup
read
write
blk_read
Disk cache Disk
blk_write
Block layer caching
Cached I/O - Lookup memory cache using the
block number as the key
User processes
- How does the scheme work for data
read, write, stat
and metadata?
File system - For data caching, file offset to block
lookup
read
address mapping is required before
write
blk_read using the cache
Disk cache Disk
blk_write
Block layer caching
Cached I/O - Lookup memory cache using the
block number as the key
User processes
- How does the scheme work for data
read, write, stat
and metadata?
File system - For data caching, file offset to block
lookup
read
address mapping is required before
write
blk_read using the cache
Disk cache
blk_write
Disk - Works fine for metadata as they are
addressed using block numbers
File layer caching (Linux page cache)
Cached I/O - Store and lookup memory cache
using {inode number, file offset} as
User processes
the key
read, write, stat
- For data, index translation is not
File system required for file access
lookup
read
- Metadata may not have a file
write
blk_read association, should be handled
Disk cache
blk_write
Disk differently (using a special inode
may be!)
File system and caching
- Accessing data and metadata from disk impacts performance
- Can
Manywefilestore frequently
operations accessed
require diskblock
multiple data in memory?
access
- - What is the storage and lookup mechanism? Are the data and metadata
Examples:
- caching
Openingmechanisms
a file same?
- File layer caching is desirable as it avoids index accesses on hit, special
fd = open(“/home/user/test.c”, O_RDWR);
mechanism required for metadata.
- Are thereshell
Normal anyoperations
complications because of caching?
- How the cache managed? What should be the eviction policy?
/home/user$ ls
Caching and consistency
- Caching may result in inconsistency, but what type of consistency?
Caching and consistency
- Caching may result in inconsistency, but what type of consistency?
- System call level guarantees
- Example-1: If a write( ) system call is successful, data must be written
- Example-2: If a file creation is successful then, file is created.
- Difficult to achieve with asynchronous I/O
Caching and consistency
- Caching may result in inconsistency, but what type of consistency?
- System call level guarantees
- Example-1: If a write( ) system call is successful, data must be written
- Example-2: If a file creation is successful then, file is created.
- Difficult to achieve with asynchronous I/O
- Consistency w.r.t. file system invariants
- Example-1: If a block is pointed to by an inode data pointers then,
corresponding block bitmap must be set
- Example-2: Directory entry contains an inode, inode must be valid
- Possible, require special techniques
File system inconsistency: root causes
- No consistency issues if user operation
Update contents of disk
blocks translates to read-only operations on
Disk block caching
the disk blocks
(delayed write)
Possible
inconsistent
file system
System crash (software,
power failure)
- Always keep in mind: device level
Storage medium failure atomicity guarantees
(sector(s) damaged)