bcf0b8df1c
|
||
|---|---|---|
| .. | ||
| README.md | ||
| afs.py | ||
README.md
Overview
This program, afs.py, allows you to experiment with the cache consistency
behavior of the Andrew File System (AFS). The program generates random client
traces (of file opens, reads, writes, and closes), enabling the user to see if
they can predict what values end up in various files.
Here is an example run:
prompt> ./afs.py -C 2 -n 1 -s 12
Server c0 c1
file:a contains:0
open:a [fd:0]
write:0 value? -> 1
close:0
open:a [fd:0]
read:0 -> value?
close:0
file:a contains:?
prompt>
The trace is fairly simple to read. On the left is the server, and each column
shows actions being taken on each of two clients (use -C <clients> to specify
a different number). Each client generates one random action (-n 1), which is
either the open/read/close of a file or the open/write/close of a file. The
contents of a file, for simplicity, is always just a single number.
To generate different traces, use -s (for a random seed), as always. Here we
set it to 12 to get this specific trace.
In the trace, the server shows the initial contents of all the files in the system:
file:a contains:0
As you can see in this trace, there is just one file (a) and it contains the value 0.
Time increases downwards, and what is next is client 0 (c0) opening the file 'a' (which returns a file descriptor, 0 in this case), writing to that descriptor, and then closing the file.
Immediately you see the first question posed to you:
write:0 value? -> 1
When writing to descriptor 0, you are overwriting an existing value with the new value of 1. What was that old value? (pretty easy in this case: 0).
Then client 1 begins doing some work (c1). It opens the file, reads it, and closes it. Again, we have a question to answer:
read:0 -> value?
When reading from this file, what value should client 1 see? Again, given AFS consistency, the answer is straightforward: 1 (the value placed in the file when c0 closed the file and updated the server).
The final question in the trace is the final value of the file on the server:
file:a contains:?
Again, the answer here is easy: 1 (as generated by c0).
To see if you have answered these questions correctly, run with the -c flag
(or --compute), as follows:
prompt> ./afs.py -C 2 -n 1 -s 12 -c
Server c0 c1
file:a contains:0
open:a [fd:0]
write:0 0 -> 1
close:0
open:a [fd:0]
read:0 -> 1
close:0
file:a contains:1
prompt>
From this trace, you can see that all the question marks have been filled in with answers.
More detail is available on what has happened too, with the '-d' ('--detail') flag. Here is an example that shows when each client issued a get or put of a file to the server:
prompt> ./afs.py -C 2 -n 1 -s 12 -c -d 1
Server c0 c1
file:a contains:0
open:a [fd:0]
getfile:a c:c0 [0]
write:0 0 -> 1
close:0
putfile:a c:c0 [1]
open:a [fd:0]
getfile:a c:c1 [1]
read:0 -> 1
close:0
file:a contains:1
prompt>
You can show more with higher levels of detail, including cache invalidations, the exact client cache state after each step, and extra diagnostic information. We'll show these in one more example below.
Random client actions are useful to generate new problems and try to solve
them; however, in some cases it is useful to control exactly what each client
does in order to see specific AFS behaviors. To do this, you can use the -A
and -S flags (either together or in tandem).
The -S flag lets you control the exact schedule of client actions. Assume our
example above. Let's say we wish to run client 1 in entirety first; to achieve
this end, we simply run the following:
prompt> ./afs.py -C 2 -n 1 -s 12 -S 111000
Server c0 c1
file:a contains:0
open:a [fd:0]
read:0 -> value?
close:0
open:a [fd:0]
write:0 value? -> 1
close:0
file:a contains:?
prompt>
The -S flag here is passed "111000" which means "run client 1, then client 1, then 1 again, then 0, 0, 0, and then repeat (if need be)". The result in this case is client 1 reading file a before client 1 writes it.
The -A flag gives exact control over which actions the clients take. Here is
an example:
prompt> ./afs.py -s 12 -S 011100 -A oa1:r1:c1,oa1:w1:c1
Server c0 c1
file:a contains:0
open:a [fd:1]
open:a [fd:1]
write:1 value? -> 1
close:1
read:1 -> value?
close:1
file:a contains:?
prompt>
In this example, we have specified the following via -A oa1:r1:c1,oa1:w1:c1.
The list splits each clients actions by a comma; thus, client 0 should do
whatever oa1:r1:c1 indicates, whereas client 1 should do whatever the string
oa1:w1:c1 indicates. Parsing each command string is straightforward: oa1
means open file 'a' and assign it file descriptor 1; r1 or w1 means read
or write file descriptor 1; c1 means close file descriptor 1.
So what value will the read on client 0 return?
We can also see the cache state, callbacks, and invalidations with a few extra
flags (-d 7):
prompt> ./afs.py -s 12 -S 011100 -A oa1:r1:c1,oa1:w1:c1 -c -d 7
Server c0 c1
file:a contains:0
open:a [fd:1]
getfile:a c:c0 [0]
[a: 0 (v=1,d=0,r=1)]
open:a [fd:1]
getfile:a c:c1 [0]
[a: 0 (v=1,d=0,r=1)]
write:1 0 -> 1
[a: 1 (v=1,d=1,r=1)]
close:1
putfile:a c:c1 [1]
callback: c:c0 file:a
invalidate a
[a: 0 (v=0,d=0,r=1)]
[a: 1 (v=1,d=0,r=0)]
read:1 -> 0
[a: 0 (v=0,d=0,r=1)]
close:1
file:a contains:1
prompt>
From this trace, we can see what happens when client 1 closes the (modified) file. At that point, c1 puts the file to the server. The server knows that c0 has the file cached, and thus sends an invalidation to c0. However, c0 already has the file open; as a result, the cache keeps the old contents until the file is closed.
You can see this in tracking the cache contents throughout the trace
(available with the correct -d flag, in particular any value which
sets the 3rd least significant bit to 1, such as -d 4, -d 5, -d 6, -d 7, etc.). When client 0 opens the file, you see the following cache
state after the open is finished:
[a: 0 (v=1,d=0,r=1)]
This means file 'a' is in the cache with value '0', and has three bits of state associated with it: v (valid), d (dirty), and r (reference count). The valid bit tracks whether the contents are valid; it is now, because the cache has not been invalidated by a callback (yet). The dirty bit changes when the file has been written to and must be flushed back to the server when closed. Finally, the reference count tracks how many times the file has been opened (but not yet closed); this is used to ensure the client gets the old value of the file until it's been closed by all readers and then re-opened.
The full list of options is available here:
Options:
-h, --help show this help message and exit
-s SEED, --seed=SEED the random seed
-C NUMCLIENTS, --clients=NUMCLIENTS
number of clients
-n NUMSTEPS, --numsteps=NUMSTEPS
ops each client will do
-f NUMFILES, --numfiles=NUMFILES
number of files in server
-r READRATIO, --readratio=READRATIO
ratio of reads/writes
-A ACTIONS, --actions=ACTIONS
client actions exactly specified, e.g.,
oa1:r1:c1,oa1:w1:c1 specifies two clients; each opens
the file a, client 0 reads it whereas client 1 writes
it, and then each closes it
-S SCHEDULE, --schedule=SCHEDULE
exact schedule to run; 01 alternates round robin
between clients 0 and 1. Left unspecified leads to
random scheduling
-p, --printstats print extra stats
-c, --compute compute answers for me
-d DETAIL, --detail=DETAIL
detail level when giving answers (1:server
actions,2:invalidations,4:client cache,8:extra
labels); OR together for multiple
Read the AFS chapter, and answer the questions at the back, or just explore this simulator more on your own to increase your understanding of AFS.