6.824 Lab 5: caching extents

Introduction

In this lab you will modify Yfs to cache extents, cing ing the load on the extent server and improving Yfs performance. The main challenge is to ensure consistency of extents cached at differentYfs_clientS: to make sure that eachYfs_clientSees extent data that reflects the latest modifications by other clients. To achieve consistency we will use the caching lock service from Lab 4.

First you'll add a localWrite-backExtent cache to each extent client. the extent client will serve all extent operations from this cache; the extent client will contact the extent server only to fetch an extent (or the attribute of the extent) that is not present on the client. then you'll make the caches at different clients consistent by forcing write-back of the dirty cached extent associated with a filehandle (and deletion of the clean extent) when you release the lock on that filehandle.

Your client will be a success if it manages to operate out of its local extent and lock cache when reading/writing files and directories that other hosts aren't looking, but maintains Correctness When the same files and directories are concurrently read and updated by multiple clients.

Getting started

Begin by initializing your lab 5 branch with your implementation from Lab 4. There is no new code for this lab, cannot be updated to the makefile to build this lab.

% cd ~/lab% git commit -am ‘my solution to lab4‘Created commit ...% git pullremote: Generating pack......% git checkout -b lab5 origin/lab5Branch lab5 set up to track remote branch refs/remotes/origin/lab5.Switched to a new branch "lab5"% git merge lab4

Testing Performance

Our measure of performance is the numberPutAndGetRpcs that your extent server has es. You can tell the extent server to print out a line every 25 rpcs telling you the current totals as you did for the lock server in Lab 4, by settingRpc_countTo 25.

Then you can start the servers, runTest-lab-3-cTester, and look inExtent_server.logTo see how many rpcs have been already ed.

% export RPC_COUNT=25% ./start.sh% ./test-lab-3-c ./yfs1 ./yfs2Create/delete in separate directories: tests completed OK% grep "RPC STATS" extent_server.log...RPC STATS: 1:2 6001:804 6002:2218 6003:1878 6004:198% ./stop.sh

TheRPC statsLine indicates the numberBind,Put,Get,Getattr, AndRemoveRpcs stored ed by the extent server. The above line is the output of our solution for lab 4. Your goal is to reduce those numbers to about a dozenPutS and at most a few hundredGetS.

Step one: extent Cache

In step one you'll add caching to your extent client, without cache consistency. This cache will make yourYfs_clientFast but inconsistent.

Your newExtent_client: GetShocould check if the extent is cached, and if so return the cached copy. OtherwiseGet ()Shocould fetch the extent from the extent server, put it in the local cache, and then return it.Put ()Shocould just replace the cached copy, and not send it to the extent server. You'll find it helpful for the next section if you keep track of which cached extents have been modifiedPut ()(I. e .,Are "dirty ").Remove ()Shocould Delete the extent from the local cache.Extent_clientShoshould maintain cached attributes for each extent so thatExtent_client: getattr ()Returns reasonable values.

When you're done, SetRpc_countAnd runTest-lab-3-cGiving the same directory twice, and watch the RPC stats printed by the extent server. You shoshould see zeroPutS and somewhere between zero and a few hundredGetS (or perhaps no numbers at all, if the valueRpc_countIs more than the numberGetS). Your server shocould passTest-lab-3-a.plAndTest-lab-3-bIf you give it the same directory twice, but it will probably failTest-lab-3-bWith two different directories because it has no cache consistency.

You can modifyExtent_client.ccAndExtent_client.h, Or if you 'd like, you can add the code to a sub-class in a separate file. RememberGit addAny new files you create.

Step two: cache consistency

In step two you'll ensure that eachGet ()Sees the latestPut (), Even whenGet ()AndPut ()Are from different Yfs clients. The extent client and lock client will cooperate to do this, helped byYfs_clientUsing the same ID for a file/directory I-number, lock, and extent. when your lock client releases a lock back to the lock server, you shoshould ensure that the extent client first flush the extent to the server, and then remove it from local cache. A flush requires putting the corresponding extent (if dirty) to the extent server, or removing the extent (if locally removed) from the extent server.

Suppose Client A acquires the lock on an I-number, get () s the file's data from the extent server and modifies it in its extent client cache, and keeps the lock and extent cached. client B then asks for the lock, so that the lock server sends client a revoke message. client A will send the dirty data back to the extent server before releasing the lock. then B will acquire the lock and get () The I-number's extent. since B cannot have the extent in its cache (if it ever cached it, it must have deleted it when it gave up the lock ), and a wrote the modified extent to the extent server before releasing the lock, B will see a's modifications.

You will now be using locks for two different purposes: first, to ensure that each file system operation is atomic; second, to drive the extent cache consistency scheme. this may mean that you have to add acquires and releasesYfs_clientThat were not necessary to pass the tests for the previous labs. Ensure thatEvery Yfs_clientCall to get (EID), put (EID), getattr (EID), and remove (EID) is wrapped in acquire (EID)/release (EID ).

Add a method to the extent client to eliminate an extent from the cache. ThisFlush ()Method shocould first check whether the extent is dirty in the cache, in which case it shocould send it to the extent server. If the extent has been removed (with the extent client'sRemove ()Method ),Flush ()Shocould send a remove RPC to the server.Extent_clientShocould cache attributes fetched from the server, and invalidate the relevant attributes inFlush (). You need not explicitly send dirty attributes to the extent server; instead, it is enough to let the server update the attributes as a side-effectFlush ()Sending a put RPC for a dirty extent.

Your Yfs server shocould callFlush ()Just before releasing a lock back to the lock server. You coshould just addFlush ()CalltoYfs_client.ccBefore eachRelease (). However, now that your lock client handles the caching of locks, flushing an extent inLock_client: release ()Is overkill; you only have to flush an extent when the lock server revokes the corresponding lock.

We provide you with a bit of glue to connect the lock client to the extent client in the form ofLock_release_userClass, defined inLock_client_cache.h. This is a virtual class supporting only one method:Dorelease (lock_protocol: lockid_t). Your job is to subclassLock_release_userAnd implement that subclass'sDoreleaseMethod to callFlush ()On your extent client for whatever data is about to lose its lock. Then, create an instance of this class and pass it intoLock_client_cacheObject constructed inYfs_client.cc. Finally, yourLock_client_cacheMust callDorelease ()Method of itsLuObject before it releases a lock back to the lock server. (Note thatLuWas defined and initialized in the code we provided you for lab 4.) This will ensure thatLock_client: flush ()Is called before the lock is released.

When you're done with step two your server shocould pass all the correctness tests (Test-lab-3-a.pl,Test-lab-3-b, AndTest-lab-3-cShocould execute correctly with two separate Yfs Directories), And You shoshould see a dramatic drop in the numberPutS andGetS specified ed by the extent server.

Hints

• Make sure you use a pthreads mutex to protect the extent cache, In case multiple threads access it at once.
• Make sure that, if you only read an extent (or its attributes), You don't flush it back on a release. you shoshould keep a flag in your cache that records if an extent (or its attributes) have been modified.
• You may be able to implement the caching In the extent client without modifying yfs_client.cc, could t for instantiating (if you implemented your caching extent client as a separate class) and passing the object that implementsLock_release_userInterface inYfs_client: yfs_client. However, as noted above, you may have to add acquire and release calltoYfs_client.

 

Problem:

1. What is the program architecture. Why do lock_release_user and yfs_client become very complicated and the relationship between variables is not clear?