Presentation is loading. Please wait.

Presentation is loading. Please wait.

Week 9 March 4, 2004 Adrienne Noble.

Similar presentations


Presentation on theme: "Week 9 March 4, 2004 Adrienne Noble."— Presentation transcript:

1 Week 9 March 4, 2004 Adrienne Noble

2 Important Dates Homework 9 due Monday, March 8
Project 4 due Wednesday, March 10 Final Exam on Tuesday, March 16, 2:30-4:20pm

3 Questions? Lecture Homework 9 Project 4

4 Review from last week /foo/hello.c

5 EXT2 is basically what we’ve been talking about in class
But MINIX is what your file system is based off of VFS and Buffer Manager code are both located in fs/, but they are different entities VFS defines structs Buffer Manager defines functions

6 The VFS Not written in C++, so we can’t use an abstract class
Defines structs for superblocks and inodes File system must store all this information Includes an extra field that the file system can use however it wants Defines a struct with functions that the file system needs to implement The file system can add additional helper functions But we set a lot of things to 0 or null inode is a VFS structure, cse451fs_inode is your structure Don’t change anything in the linux source code

7 The Buffer Manager Linux source is large, so these tools can help you find what you need Cross Referencing Linux: grep Two pieces of the buffer manager Data structures (struct buffer_head) Actual data (pointed to by the b_data field in buffer_head)

8 For any given disk block, the buffer manager may be
Completely unaware of the block Aware of the block’s information, but the block is not it memory Have the block’s information and data in memory One other possibility: unaware of block’s information, but has data in memory – hope that never happens

9 Buffer Manager functions
bh = bread(dev, block, size) Get the buffer_head for the given disk block, ensuring that the data is in memory and ready for use. Increments the ref count; always pair with a brelse. bh = getblk(dev, block, size) Get the buffer_head for the given disk block. Does not guarantee anything about the state of the actual data. Increments ref count; always pair with a brelse. bh = get_hash_table(dev, block, size) Find the buffer_head for the given block in the hash table. Does not guarantee anything about the state of the actual data. Increments ref count; always pair with a brelse. Bread is a wrapper around get_blk – ensures that data is in memory uses getblk to get buffer head checks that data is actually in memory (by calling uptodate) reads it in from disk if it isn’t getblk is a wrapper around get_hash_table – frees up memory when it can’t be found in the hash table Brelse decrements the reference count – reference count keeps track of how many pointers are pointing at bh

10 More functions ll_rw_block(rw, numbufs, bh[]) wait_on_buffer(bh)
Lock buffer, begin IO (either read of write), schedule a callback that will unlock buffer when IO finishes, and return (does not wait for IO completion – see wait_on_buffer). wait_on_buffer(bh) Wait for the buffer to be unlocked (e.g. read from disk to complete)

11 Still More… mark_buffer_dirty(bh) mark_buffer_uptodate(bh)
Mark the buffer modified mark_buffer_uptodate(bh) Indicate that the data pointed to be bh is valid is_valid = buffer_uptodate(bh) Return whether the bh points to valid data brelse(bh) “buffer release” - decrement the ref count of the given buffer Mark_buffer_modified – needs to be written to disk at some point

12 cse451fs functions bh = cse451_bread(inode, block, create)
Similar to bread, but takes an inode and block number relative to the inode instead bh = cse451_getblk(inode, block, create) Similar to getblk, but takes an inode and block number err = get_block(inode, block, &bh, create) Fills in b_blocknr field in bh, allocating a new data block if necessary Bread calls getblk, getblk calls get_block


Download ppt "Week 9 March 4, 2004 Adrienne Noble."

Similar presentations


Ads by Google