Once you implement the above function, you have the basic functionality of your

storage system in place. We have expanded the tester to include new tests for the

write operations, in addition to existing read operations. You should try to pass

these write tests first.

Implementing mdadm$\_$write permissions

The cryptocurrency startup that you are interning at is also very concerned about

the security of their storage systems. To ensure that data is written by the correct

people and at the correct times, you will also be required to write the following

functions to set the write permissions of the storage system:

int mdadm$\_$write$\_$permission$($void$)$;

int mdadm$\_$revoke$\_$write$\_$permission$($void$)$;

As you can see, there are no parameters for these functions. Each of these will tell

your storage device whether writing is allowed at that point.

mdadm$\_$write$\_$permission will tell the system that writing is now allowed.

mdadm$\_$revoke$\_$write$\_$permission will $$turn off$$ write permissions to the

system; that is$,$ it will tell the system that writing is no longer allowed.

As you might expect, you must turn write permission ON before writing to the

system. You should also always check if this permission is on each time you write

to the system.

Just as all other functions that you have been required to implement, you will need

to use jbod$\_$operation$($op$,*$block$)$ to interact with the storage system.

The following ENUM commands are provided to you:

JBOD$\_$WRITE$\_$PERMISSION: sets the write permission to $1$ so that writing will

be allowed. When the command field of op is set to this, all other fields in op are

ignored by JBOD driver. The block argument is passed as NULL.

JBOD$\_$REVOKE$\_$WRITE$\_$PERMISSION: sets the write permission to $-1$ so that

writing will no longer be allowed. When the command field of op is set to this, all

other fields in op are ignored by JBOD driver. The block argument is passed as

NULL.

$**$HINT: check your write permission in your code before writing.

Testing using trace replay

As we discussed before, your mdadm implementation is a layer right above JBOD,

and the purpose of mdadm is to unify multiple small disks under a unified storage

system with a single address space. An application built on top of mdadm will

issue a mdadm$\_$mount, mdadm$\_$write$\_$permission and then a series of

mdadm$\_$write and mdadm$\_$read commands to implement the required

functionality, and eventually, it will issue mdadm$\_$unmount command. Those

read$/$write commands can be issued at arbitrary addresses with arbitrary payloads

and our small number of tests may have missed corner cases that may arise in

practice.

Therefore, in addition to the unit tests, we have introduced trace files, which

contain the list of commands that a system built on top of your mdadm

implementation can issue. We have also added to the tester a functionality to replay

the trace files. Now the tester has two modes of operation. If you run it without any

arguments, it will run the unit tests:

$ $./$tester

If you run it with $-$w pathname arguments, it expects the pathname to point to a

trace file that contains the list of commands. In your repository, there are three

trace files under the traces directory: simple$-$input, linear$-$input, random$-$input.

Let$$s look at the contents of one of them using the head command, which shows

the first $10$ lines of its argument:

$ head traces$/$simple$-$input

MOUNT

WRITE$\_$PERMIT

WRITE $02560$

READ $10068482560$

WRITE $100684825693$

WRITE $100710425694$

WRITE $100736025695$

READ $5598722560$

WRITE $559872256139$

READ $8279042560$

The first command mounts the storage system. The second command is a write

command, and the arguments are similar to the actual mdadm$\_$write function

arguments; that is$,$ write at address $0,256$ bytes of bytes with contents of $0.$ The

third command reads $256$ bytes from address $1006848($the third argument to

READ is ignored$).$ And so on$.$

You can replay them on your implementation using the tester as follows:

$ $./$tester $-$w traces$/$simple$-$input

SIG$($disk$,$block$)00$ : $0$xb$30$x$760$x$880$x$5$a $0$xc$80$x$450$x$2$b $0$x$6$c $0$xbf $0$x$9$c

SIG$($disk$,$block$)01$ : $0$xb$30$x$760$x$880$x$5$a $0$xc$80$x$450$x$2$b $0$x$6$c $0$xbf $0$x$9$c

SIG$($disk$,$block$)02$ : $0$xb$30$x$760$x$880$x$5$a $0$xc$80$x$450$x$2$b $0$x$6$c $0$xbf $0$x$9$c

SIG$($disk$,$block$)03$ : $0$xb$30$x$760$x$880$x$5$a $0$xc$80$x$450$x$2$b $0$x$6$c $0$xbf $0$x$9$c

$...$

If one of the commands fails, for example because the address is out of bounds,

then the tester aborts with an error message saying on which line the error

happened. If the tester can successfully replay the trace until the end, it takes the

cryptographic checksum of every block of every disk and prints them out on the

screen, as above. Now you can use this information to tell if the final state of your

disks is consistent with the final state of the reference implementation, if the above

trace was replayed on a reference implementation. You can do that by comparing

your output to that of the reference implementation. The files that contain the

corres