操作系统导论课后作业代码

# Overview Welcome to `ssd.py`, yet another wonderful simulator provided to you, for free, by the authors of OSTEP, which is also free. Pretty soon, you're going to think that everything important in life is free! And, it turns out, it kind of is: the air you breathe, the love you give and receive, and a book about operating systems. What else do you need? To run the simulator, you just do the usual: ```sh prompt> ./ssd.py ``` The simulator models a few different types of SSDs. The first is what we'll call an "ideal" SSD, which actually isn't much an SSD at all; it's more like a perfect memory. To simulate this SSD, type: ```sh prompt> ./ssd.py -T ideal ``` To see how this one works, let's create a little workload. A workload, for an SSD, is just a series of low-level I/O operations issued to the device. There are three operations supported by ssd.py: read (which takes an address to read, and returns the data), write (which takes an address and a piece of data to write, in this case, a single letter), and trim (which takes an address). The trim operation is used to indicate a previously written block is no longer live (i.e., the file it was in was deleted); this is particular useful for a log-based SSD, which can reclaim the block's space during garbage collection and free up space in the FTL. Let's run a simple workload consisting of just one write: ```sh prompt> ./ssd.py -T ideal -L w10:a -l 30 -B 3 -p 10 ``` The `-L` flag allows us to specify a comma-separated list of commands. Here, to write to logical page 10, we include the command "w10:a" which means "write" to logical page "10" the data of "a". We also include a few other specifics about the size of the SSD with the flags `-l 30 -B 3 -p 10`, but let's ignore those for now. What you should see on the screen, after running the above: ```sh FTL (empty) Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii iiiiiiiiii iiiiiiiiii Data Live FTL 10: 10 Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State viiiiiiiii iiiiiiiiii iiiiiiiiii Data a Live + ``` The first chunk of information shows the initial state of the SSD, and the second chunk shows its final state. Let's walk through each piece to make sure you understand what they mean. The first line of each chunk of output shows the contents of the FTL. This simulator only models a simple page-mapped FTL; thus, each entry within it shows the logical-to-physical page mapping for any live data items. In the initial state, the FTL is empty: ```sh FTL (empty) ``` However, in the final state, you can see that the FTL maps logical page 10 to physical page 10: ```sh FTL 10: 10 ``` The reason for this simple mapping is that we are running the "ideal" SSD, which really just acts like a memory; if you write to logical page X, this SSD will just (magically) write the data to physical page X (indeed, you don't even really need the FTL for this; we'll just use the ideal SSD to show how much extra work a real SSD does, in terms of erases and data copying, as compared to an ideal memory). The next lines of output just label the blocks and physical pages of the underlying Flash the simulator is modeling: ```sh Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 ``` In this simulation, you can see that the SSD has 3 physical Flash blocks, and that each block has 10 physical pages. Each block is numbered (0, 1, and 2), as is each page (from 00 to 29); to keep the display compact (width-wise), the page numbering is shown across two lines. Thus, physical page "10" is labeled with a "1" on the first line, and a "0" on the second. The next line shows the state of each page, i.e., whether it is INVALID (i), ERASED (E), or VALID (v), as per the chapter: ```sh State viiiiiiiii iiiiiiiiii iiiiiiiiii ``` The states for the "ideal" SSD are a bit weird, in that you can have "v" and "i" mixed in a block, and that the block is never "E" for erased. Below, with the more realistic "direct" and "log" SSDs, you'll see "E" too. The final two lines show the "contents" of any written-to pages (on the "Data" row) and whether that data is currently live (that is, referred to in the FTL) in the "Live" row: ```sh Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 Data a Live + ``` Here, we can see that on Block 2 (i.e., Page 10), there is the data "a", and it is indeed live (shown by the "+" symbol). Let's expand our workload a little bit, before getting to the more realistic types of SSDs. After writing the data, let's read it, and then let's use trim to delete it: ```sh prompt> ./ssd.py -T ideal -L w10:a,r10,t10 -l 30 -B 3 -p 10 ``` If you run this, you'll see two identical states: the initial (empty) state, and the final (also empty!) state. Not too exciting! To see more of what is going on, you'll have to use some more flags. Yes, this SSD simulator uses a lot of flags; sorry, all lovers of parsimony! But alas, there is some complexity here we must explore. One useful flag is `-C`, which just shows every command that was issued, and whether is succeeded or not. ```sh prompt> ./ssd.py -T ideal -L w10:a,r10,t10 -l 30 -B 3 -p 10 -C FTL (empty) Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii iiiiiiiiii iiiiiiiiii Data Live cmd 0:: write(10, a) -> success cmd 1:: read(10) -> a cmd 2:: trim(10) -> success FTL (empty) Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii viiiiiiiii iiiiiiiiii Data a Live prompt> ``` Here, you can see the write, read, and trim, and you can also see what each command returned: success, the data read, and success, respectively. This will be more interesting later, when the simulator generates the operations randomly. Similarly, the `-F` flag shows the state of the Flash between each operation, instead of just at the end. Note the subtle changes at each step: ```sh prompt> ./ssd.py -T ideal -L w10:a,r10,t10 -l 30 -B 3 -p 10 -F FTL (empty) Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii iiiiiiiiii iiiiiiiiii Data Live FTL 10: 10 Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii viiiiiiiii iiiiiiiiii Data a Live + FTL 10: 10 Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii viiiiiiiii iiiiiiiiii Data a Live + FTL (empty) Block 0 1 2 Page 0000000000 1111111111 2222222222 0123456789 0123456789 0123456789 State iiiiiiiiii viiiiiiiii iiiiiiiiii Data a Live prompt> ``` Of course, you can use `-C` and `-F` in concert to show everything (an exercise left to the reader). The simulator also lets you generate random workloads, instead of specifying operations yourself. Use the "-n" flag for this, with an associated number (we also specify a random seed with "-s" to get a particular workload): ```sh prompt> ./ssd.py -T ideal -l 30 -B 3 -p 10 -n 5 -s 10 ``` If you run this with `-C`, `-F`, or both, you'll see either the exact commands, the intermediate states of the Flash, or both. However, you can also use the "-q" flag to quiz yourself on what you think the commands are. Thus, run the following: ```sh prompt> ./ssd.py -T ideal -l 30 -B 3 -p 10 -n 5 -s 10 -q (output omitted for brevity) ``` Now, by examining the intermediate states, see if you can discern what the commands must have been (writes and trims are left completely unspecified, w