DiskSim OutlineNote: Go read the users manual and the appendices before reading thisdocument. The material in those docs will not be repeated here. Thisdocument is intended for people who want to understand the codeinternals. If you don't understand what functionality the code isimplementing, then you won't understand the code or this descriptionof how it is implemented.Information stored inside of the disk modulesWhen a request enters the disk module, it is a ioreq_event containingbasic information about the request. Once inside the module it isconverted to the structure below in order to keep track of activity inthe simulated disk.      seg -----> diskreqlist (linked list)       |             |       v             v     access      ioreqlist       |         (original, unmodified request)       v     bcountaccess = (copy of) active request on this segment, it's arguments maybe changed.access->bcount = does not mean block count, see the comments in	disksim_diskctlr.c:disk_buffer_sector_done().diskreqlist requests are stored in ascending block order.Event based SystemThere are various types of events: timer, io, etc.. All events arestored in a global queue in time order. Time jumps to the next eventtime when the current one completes.The disk module is woken up by events from io_event_arrive() and thebus module. disk_event_arrive() fields all events and takesappropriate action. Events are passed down to io_event_arrive from theglobal event handler. addtointq() and removefromintq() are used toaccess the global queue.Memory managementFunctions dealing with extraq are for memory management.Nothing (well, as little as possible) is dynamically allocated. Memoryis reserved when disksim starts. A pool of event structures ismaintained by disksim. To create a new event, call getfromextraq(), tofree up an event call addtoextraq(). If you want a disk event,typecast the return event struct pointer from getfromextraq to adisk_event structure pointer.Event Flow in Disk moduleBelow are common paths of function calls taken when the disk module isaccessed. Each arrow represents a different path. Stacked functionswithin a given path are executed in order. Not all paths are listed,only the more common ones which benefit from explanation. An event isnot a function call, but it is crucial enough to how the simulatorworks that the event submissions are listed here. The submitted eventis the access member of the structure described above, assuming that asegment has been set.disk_event_arrive    `-> disk_request_arrive             `-> disk_send_event_up_path                 disk_active_read/write                   `-> (various cases exist, depending on whether                            another request is active and the disk                            parameters, see the code for detailed                            comments) disk_check_hda                               `-> disk_initiate_seek    `->   disk_buffer_seekdone             `->   (DISK_BUFFER_SECTOR_DONE event)    `->   disk_buffer_sector_done             `->   disk_buffer_request_complete                   (DISK_BUFFER_SECTOR_DONE event)             `->   disk_buffer_request_complete                   disk_initiate_seek             `->   disk_buffer_request_complete                   (DISK_DATA_TRANSFER_COMPLETE event)Brief Explanation of Functions:disk_event_arrive:All disk events enter the disk module through this function. Theproper function for the given event is called.disk_request_arrive:Sets up structure described above. Since this is not always possible,parts may set up and given information about where the other parts areso that it can be completed later. Most commonly a segment cannot beset. In this case, the ioreq_event which will become access has it'stmpptrs set to point to the disk and the diskreq.Adds request to disk queue.Finds appropriate cache segment for request (or determines that noneare currently available.)  Adds processing delay if the request can beserviced right away.disk_activate_read/write:Figures out whether request can be serviced immediately, otherwisethey will be activated when their turn comes up in the disk queue.Tries to put a more permanent claim on a cache segment, if possible.disk_check_hda:Big, ugly function that I never really touched.  Can also be calledfrom an ongoing request, seems to duplicate some functionality fromthe functions above it, possibly for this reason.  If a requestcompletes it may call this function, a new request is pulled off ofthe queue.disk_initiate_seek:Enters a DISK_BUFFER_SEEKDONE event for when the seek + rotationallatency will finish.disk_buffer_sector_done:As mentioned above, the bcount member of the access request containsstrange values. This function is somewhat difficult to understandbecause of this. Aside from that, this function is just generallycomplicated, I don't completely understand it.Checks to see if request is complete.If not complete, and this is the end of a track, seek to next track.If not the end of a track, enter sector_done event for next block intrack.disk_buffer_request_complete:Returns true if either the request is done or if the watermarkconditions are right.  If watermark conditions are right then it disconnects from the bus andpossibly may issue a request_complete event. In this case the requestis not actually complete and will continue after reconnecting to thebus.Modifications to disksimAdded layout variable to disk structureValid layouts are 0 (LAYOUT_NORMAL)LAYOUT_NORMAL preserves the old behavior of the simulator.Switch statements were added to almost every function indisksim_diskmap.c to accomodate different layouts. It should be easyto add new layouts now.There are several places in the code that make assumptions about thelogical to physical mappings and vice versa. They should all becommented. They assume that the lowest numbered logical block on atrack corresponds to the lowest numbered physical block. Ditto for thehighest.  If you want to do a mapping that violates this, there are 3or 4 places in disksim_diskctlr.c that should be changed. Skew iscurrently determined by a seperate pbn_skew function that lives indisksim_diskmap.c.Extension of "synthio"The mechanism for feeding in traces was found to be lacking. I haveextended the "synthio" module so it is no longer restricted tosynthetic I/O. Let me explain. The trace input mechanism requiresplacing a timestamp on every event passed in. This can lead toproblems if the modeled system runs slower then the one on which thetraces were taken. Organization of the code makes it difficult tostamp events as time-critical or time-limited, etc.. Synthio hasfacilities for doing this. It also has a concept of multiple processesrunning at a high level, so theoretically disk events can be tagged intrace files as belonging to a particular process #. With the currentstate of the code it would be a bad idea to try to use this extensionwith more than one synthio generator. If a tracefile is given on thecommand line (other than "0") and the synthio flag is specified thenall events will come from the named file.Removal of trackacc stuffdisksim1.0 was released with code that was previously used to speed upthe simulator but was not active or working at the time of release. Itdid so by reducing the number of events by handling entire tracks at atime, instead of doing things a sector at a time. I have removed thiscode and everything related to it as I feel the added complexity isnot worth the gain.ATA bus, postgres and IPEAK tracesAdded support for the ascii format of the winbench traces (ATA bus) Iwas given, as well as the postgres traces from the PDL and Intel IPEAKtraces. An explanation of how to add new trace formats is in themanual. It is very easy to do. The IPEAK structure was copied out of aheader file in the IPEAK package and will probably only work on 32bit, little endian machines.The time fields in these traces is set for the synthio method of traceinput, rather than the original method. Time is therefore a think-timesince last request instead of an absolute timestamp. It is probablypossible to clean this up so the traces can work either way.Port to windowsSome bunch of disksim.* Files are now in the src dir. To compile usingmicrosoft vc++, open the workspace file and build all. A few changeswere made to disksim_global.h, look for #ifdef's with win32 inthem. Windows is also missing the rand48 family of functioncalls. disksim_rand48.[ch] contains versions of these calls that havebeen ripped from the gnu libc. DO NOT REDISTRIBUTE THIS PACKAGE withthose files. syssim will not be built under windows as it is stillmissing the lrand48 call, which I didn't bother to rip with theothers.Parsing updatesThe disk and logorg parsing and override functions have been partiallyripped apart. Almost all of the safety checking and calculations havebeen moved into postpass functions. Postpass functions are calledafter all parsing of parameter files and command line has beencompleted for all modules. Overriding parameters is now much cleanerand safety checks are performed on these overrides. The same should bedone for all other parsing functions. Many more things can now beoverridden as well (in theory, I have not added all the parameterswith which it is possible to do this.) Several of the disk geometrynumbers that are spit into the output file are now incorrect, though,because they are printed before the calculation takes place.Extra tidbitsIn the valid dir there are a few new files. Graphall and grapher willuse the information in par.graph and the plots dir to generate a fewgraphs, assuming you have perl and gnuplot installed. Graphall is whatyou want to run. It will do some runs using disksim and then callgrapher to plot the results. Postscript files will appear in the plotsdir. New directories will be created under valid to store data fromthe runs, as well as a bunch of files in plots with names beginningwith "foo-". These and the perlplot file and all the files beginningwith "out" can be safely deleted.  Some exit() calls were changed toassert(0) calls. Forces the program to dump core. Convenient fordebugging purposes.  Disk models for an Eclipse and a Trident drivehave been added to the diskspecs file. Cache management for a realEclipse drive cannot be accurately modeled by disksim, since theEclipse uses dynamically sized cache segments. I have used what seemedto be a reasonable approximation. If updating, keep in mind that theEclipse has an internal queue of 24 commands (lazy writes and oneread, it's an ATA drive.) I cannot comment much on the Trident modelsince I did not create the model and it didn't work in the one or twotests I tried to run using it.Disk modulesThe modules listed below are the ones which implement the disk model.Most of the complexity seems to be in disksim_diskctlr; that seems tobe where nearly all of the disk event handling resides.  The othermodules provide routines which are called from diskctlr, or perhapsother modules.disksim_diskRoutines to initialize the disk section and print statistics. IE,parsing parameters from a specfile or command line, outputtingaccumulated statistics to the output file.disksim_diskcacheHave to look more closely at this one.disksim_diskctlrThe main entry point is disk_event_arrive, called by disksim_bus anddisksim_iosim. This submodule does all the thinking, other modulesprovide very simple interfaces that make this modules job easier. Zerolatency reads, sector remapping, prefetching, scheduling, etc. are allhandled in here.disksim_diskmapHandles mappings from LBNs (Logical Block Numbers) to PBNs (PhysicalBlock Numbers) and vice versa. Takes into account a few sparing andlayout schemes.  disksim_diskmechDoesn't take into account ZLR/ZLW.  It does very little, infact. Since the events are on a sector-by-sector basis, all thismodule does is provide lengths of time for seeks andtransfers. Occasionally it will set up a few variables for a callingfunction as well.* * * * * * * * * * * * * * Other modulesDisksim_busPasses events between compontents, notably disk and controller.Known Bugs/Brokenness/etc.Some of these items are mentioned elsewhere, but I want to have all ofthese listed together as well.LAYOUT_SERPENTINE (layout 3) is currently non-functional. Serpentinelayout has only hooks without any code whatsoever.Trace formats that I have implemented do not set the time fieldproperly for normal trace input. See the comments under the tracesheading for more details.I could not get the trident disk model to work. It seems that after afew requests, one would simply not report completion, causing thesynthio generator to idle for more than 50 seconds, thus ending thesimulation.Several pieces of information about disk geometry in the output mayappear to be wrong. This is a result of the the updated parsing. Seecomments under that heading for more details.FutureAdd ability to turn on debug statements (preferrably at run-time, butat least at build-time) on a component-by-component basis.  (Currentlyone must uncomment individual fprintf statements.)  Maybe parametersin the parv file (like the PRINTED I/O SUBSYSTEM STATISTICS section)would be a good method.