Lab Assignment #3-mdadm Linear Device (Writes and Testing)CMPSC311 - Introduction to Systems ProgrammingSummer 2022 - Prof. Suman SahaDue date: July 8, 2022 (11:59 PM) ESTLike all lab assignments in this class, you are prohibited from copying any content from the Internet including (discord or other group messaging apps) or discussing, sharing ideas, code, configuration, text, or anything else or getting help from anyone in or outside of the class. Failure to abide by this requirement will result in penalty as described in our course syllabus.Your internship is going great. You have gained experience with C programming, you have experienced your first segmentation faults, and you’ve come out on top. You are brimming with confidence and ready to handle your next challenge.Implementing mdadm_writeYour next job is to implement write functionality for mdadm and then thoroughly test your implementation. Specifically, you will implement the following function:int mdadm_write(uint32_t start_addr, uint32_t write_len, const uint8_t write_buf)As you can tell, it has an interface that is similar to that of the mdadm_read function, which you have already implemented. Specifically, it writes write_len bytes from the user-supplied write_buf buffer to your storage system, starting at address start_addr. You may notice that the write_buf parameter now has a const specifier. We put the const there to emphasize that it is an in parameter; that is, mdadm_write should only read from this parameter and not modify it. It is a good practice to specify const specifier for your in parameters that are arrays or structs. Similar to mdadm_read, writing to an out-of-bound linear address should fail. A read larger than 1,024 bytes should fail; in other words, write_len can be 1,024 at most.There are a few more restrictions that you will find out as you try to pass the2tests. Once you implement the above function, you have the basicfunctionality of your storage system in place. We have expanded the tester toinclude new tests for the write operations, in addition to existing readoperations. You should try to pass these write tests first.Testing using trace replayAs we discussed before, your mdadm implementation is a layer right aboveJBOD, and the purpose of mdadm is to unify multiple small disks under aunified storage system with a single address space. An application built ontop of mdadm will issue a mdadm_mount and then a series of mdadm_writeand mdadm_read commands to implement the required functionality, andeventually, it will issue mdadm_unmount command. Those read/writecommands can be issued at arbitrary addresses with arbitrary payloads andour small number of tests may have missed corner cases that may arise inpractice.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 mdadmimplementation can issue. We have also added to the tester a functionality toreplay the trace files. Now the tester has two modes of operation. If yourun it without any arguments, it will run the unit tests:$ ./tester3If you run it with -w pathname arguments, it expects the pathname to point to atrace file that contains the list of commands. In your repository, there are threetrace 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, whichshows the first 10 lines of its argument:$ head traces/simple-inputMOUNTWRITE 0 256 0READ 1006848 256 0WRITE 1006848 256 93WRITE 1007104 256 94WRITE 1007360 256 95READ 559872 256 0WRITE 559872 256 139READ 827904 256 0WRITE 827904 256 162The first command mounts the storage system. The second command isa write command, and the arguments are similar to the actual mdadm_writefunction arguments; that is, write at address 0, 256 bytes of bytes withcontents 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-inputIf one of the commands fails, for example because the address is out ofbounds, then the tester aborts with an error message saying on which lineSIG(disk,block) 0 0 : 0xb3 0x76 0x88 0x5a 0xc8 0x45 0x2b 0x6c 0xbf 0x9c 0xed 0x81SIG(disk,block) 0 1 : 0xb3 0x76 0x88 0x5a 0xc8 0x45 0x2b 0x6c 0xbf 0x9c 0xed 0x81SIG(disk,block) 0 2 : 0xb3 0x76 0x88 0x5a 0xc8 0x45 0x2b 0x6c 0xbf 0x9c 0xed 0x81SIG(disk,block) 0 3 : 0xb3 0x76 0x88 0x5a 0xc8 0x45 0x2b 0x6c 0xbf 0x9c 0xed 0x81...4the error happened. If the tester can successfully replay the trace until theend, it takes the cryptographic checksum of every block of every disk andprints them out on the screen, as above. Now you can use this informationto tell if the final state of your disks is consistent with the final state of thereference implementation, if the above trace was replayed on a referenceimplementation. You can do that by comparing your output to that of thereference implementation. The files that contain the correspondingcryptographic checksums from reference implementation are also undertraces directory and they end with - expected-output. For example, here’show you can test if your implementation’s trace output matches with that ofreference implementation’s output for the simple-input trace:$ ./tester -w traces/simple-input >my-output$ diff -u my-output traces/simple-expected-outputThe first line replays the trace file and redirects the output to my-outputfile in the current directory, while the second line runs the diff tool, whichcompares to files contents – when the files are identical, no output isdisplayed, which means your implementation’s final state after thecommands in the trace file matches the reference implementation’s state. Ifthere is a difference in the diff command output, then there is a bug in yourimplementation; you can see which blocks contents differ and that mayhelp you with debugging.Grading rubric The grading would be done according to the following rubric:• Passing test cases 70%• Passing trace files 15%• Adding meaningful descriptive comments 5%• Successful “make” and execution without error and warnings 5%• Submission of commit id 5%Penalties: 10% per day for late submission (up to 3 days). The labassignment will not be graded if it is more than 3 days late.