CS 474 HW6 Solutions

5-24:

In FCFS, the requests will be satisfied in the order given. The number of cylinders between the requests will be (20-10) + (22-10) + (22-20) + (20-2) + (40-2) + (40-6) + (38-6) = 146. At 6 msec/cylinder (that's really slow, by the way) the total time is 876 msec.

In closest-next, we sort the requests as follows: 20 22 10 6 2 38 40. Now the number of cylinders between requests is (20-20) + (22-20) + (22-10) + (10-6) + (6-2) + (38-2) + (40-38) = 60, so the total time is 360.

Using elevator, the requests get sorted as 20 22 38 40 10 6 2. Now the number of cylinders is (20-20) + (22-20) + (38-22) + (40-38) + (40-10) + (10-6) + (6-2) = 58, so the total time is 348.

6-7

Yes, there are significant differences. First, the rename is much more efficient than the copy, since you aren't copying all the data. Second, you can copy the data from one filesystem to another, but a rename has to be in the same filesystem. Third, if you crash in the middle of a rename you may end up with 0 or 2 names for the file (in a Unix-like filesystem, anyway); if you crash in the middle of the copy you may end up with a partial copy of the file. And I'm sure there are more....

6-9

It can be simulated easily: just use a distinguished character (like /) to separate names in a path. But you don't want to forget this is only a simulation; that's likely to be one gargantuan directory, and trying to do things like finding a file could take a long time!

6-36

The ten direct entries let us access 10KB.

One data block can hold 1024/4 = 256 disk pointers. So, the single indirect entry allows us to access another 256KB.

The double indirect entry allows us to point at 256 indirect blocks, getting us access to another 256*256KB = 64MB.

Finally, the triple indirect entry allows us to point at another 256 double indirect blocks, getting us access to another 256*64MB = 16GB.

So, the "correct" answer is 16GB + 64MB + 256KB + 10KB. To all practical purposes, the answer is 16GB.

The maximum size of the file system is given by the 32 bit pointer, letting us point at 4 billion file blocks combined with the file block being 1K. Multiplying sets the total size of the file system at 4TB.

6-37

We need one read to get the contents of /, at which point we can look up the inode number for usr. A second read reads the inode, so we can know where on disk usr is. A third read gets us the contents of usr, so we can look up the inode for ast. Continuing, we get a total of 10 reads (the problem ends with fetching the inode for the text file, not its data).

6-43

If I had assigned it, I don't know where I'd test your code...