CMPE2300 – Lab01 – Defrag-o-matic
In this lab you will create a simulator to implement a file system defragmentation. Prior to SSDs, file systems benefited from ensuring files that were comprised of multiple disk partition units were allocated and adjacent on disk. This ensured minimum head movement for read/write of specific files.
Our goal is to read in a text file formatted as one file allocation unit per row with a data component indicating the file name, a sequence number indicating part N ( of M ) units, and a next value indicating where the next unit resides. Once loaded and displayed the simulator will allow a basic defragmentation to be done, attempting to group files into adjacent allocation blocks.
Your project will require use of the CDrawer. You will need to define a structure to represent file allocation units, comprised of :
• a string – representing the filename ( it will be one character for our simulation ) • an integer – representing the sequence number of this allocation unit • an integer – representing the allocation unit of the next part of the file.
Assumptions : A next value of -1 indicates that this allocation unit is empty A next value of -2 indicates that this is the last allocation unit of this file Any file system load will always have > 0 empty units
Your UI will have 3 buttons : [Load FileSystem] [Verify FileSystem] [Defragment] / Toggling to disable defragmentation And a listbox for status output – population should always use insert so newest additions are first.
Part I – Load FileSystem
Your application will be allowed to create class level members for the following : • List of File Allocation Units ( structure ) • CDrawer • integer representing CDrawer File Allocation Scale ( not CDrawer scale ) • constant integer representing the maximum width for the CDrawer in pixels = 1000
Bind your [Load FileSystem] click event to a method in your form constructor.
[Load FileSystem] Dynamically create an OpenFileDialog, and using System.IO.Path.GetFullPath and the appropriate Environment variable, set the Initial directory to the root source ( this will allow easy loading of the test files in your project ). Using System.IO.File.ReadAllLines(), read the user selected file in. For each line read, you may use split() to separate the 3 expected elements to be processed. Process as required to make and add a structure entry to your List for each.
Upon completion, add a status line in the form : “Load FileSystem: Loaded N units”
Now that the load is complete, it needs to be displayed in the CDrawer. We want our displayed grid to be square – in number ( ie. 6 x 6 ). Given the load number, determine the smallest dimension that can be used. The “scale” is the file unit cell height, it will be 4 times wider than tall to fit our output requirements. Given the fixed CDrawer width, determine the “scale”, and close any existing CDrawer before allocating a new CDrawer of our calculated dimensions.
To actually display the file units, create a some new helper methods :
MakeColors() – returns nothing and accepts nothing. It will be invoked from the constructor and will populate a form member List<Color> with a new list then fill the list with colors derived from r, g and b values of 64, 128, 192 ( notice the pattern – a triple nested loop is required ). The list will now be comprised of ?? colors, matching our alphabet filename needs.
RenderUnits() – returns nothing, accepting a List of file units, a CDrawer and the file unit height. Clear() the CDrawer, and iterate through all the file units. For each, construct a Rectangle object with the appropriate X, Y coordinates ( Grid work ? ), a width 4 times the height. If the file unit is empty, fill the rectangle with gray. Otherwise, use the letter as the offset ( ie. a is 0, b is 1,.. z = 25 ) fill the rectangle with the indexed color from our colors list. Then using the same Rectangle, use AddText to populate the rectangle with file unit’s information in the form : file_name:sequence_number:next_value, ie. h:3:34 Remember to render your CDrawer.
Now include RenderUnits as the last thing in your load function to see your filesystem.
Part II – Verify File System
Just because our file system loaded it does not mean it is valid. We need to validate the loaded system to ensure all file units ( and supposed empty space ) are error free. This step is of your own design, with these basic requirements :
• Every file unit will start having a sequence number of 0. A file unit chain must end with a next value of -2. A file may consist of a single file unit ( sequence = 0 and next of -2 ).
• Verification requires that every file unit chain is in sequence and terminates correctly.
• Verification may discontinue on the first error found – as many possible errors could potentially create an avalanche of cascading and compounding errors.
• Any error found should result in a status addition in the following form : Validation:Error:error_condition with appropriate values.
Error conditions would include, but not be limited to : • File_name : termination missing • File_name : out of sequence • File_name : start unit missing
Your instructor will discuss possible approaches.
Part III – Defragmentation
We need some helper functions to implement defragmentation.
FirstEmpty() – returns an integer representing the found empty index, accepts a list of file units and a bool representing if the search should start halfway through the list – set a default value of false. This method is used to find an available spot to move an existing file unit for defragmentation. Depending on the bool flag, start searching the list returning the index of the first empty spot encountered in the supplied list. Starting halfway must still cycle around through to the start looking for an empty spot. Only a single loop and remembering our assumptions is required.
MoveUnit() – returns void, accepts a list of file units, a list index to move and a list index to move the file unit to. In order to move a file unit, there may be an existing file unit that has a next value referencing the move location. This unit must be modified in order to maintain order in the move. Therefore, using the file name and move index determine ( if any ) prior unit exists – save this index ( or -1 for no prior unit found ). Now perform the move – the order is critical here – copy the unit to be moved to the new empty location, modify ( if required ) the prior unit, lastly set the move index unit to empty. Why is this important if this were real defragmentation ?
NeedDefrag() – returns an index indicating a unit that should be defragged. It accepts a list of file units. We will use a “lazy” evaluation of whether defragmentation is required. It involves 2 distinct passes through the list. The first pass determines if we have a “starter” unit ( seq = ? ) and if the next unit is not next in line. If so, we want this unit defragged, return this index. The second pass, if the first pass found nothing, determine if a unit is found where the next unit is not the next in line. If so, we want to this unit defragged, return the index. This method is biased to try to defragment units which are the start of a file unit chain.
Thread method Defrag(), accepts an object ( the list of units to defragment ) and returns nothing. This method will be used as a Thread target, created and started when the user clicks the Defragmentation button. The thread reference should be created as a form member and will be used by the thread to monitor for termination.
Repeat forever while the thread reference is valid :
Render your file system, have short sleep ( 25ms for checkoff, 500ms or more for debug ) Invoke your NeedDefrag() method saving the returned unit index. If no units need debug break your loop, set your thread reference to null and let the method complete.
Otherwise we have a unit whose next adjacent unit is wrong. There is a special case here, if the last unit is indicated, we can’t move ANY adjacent units. So, if the unit indicated is the last node and is not the last node in the file chain, invoke MoveUnit with the unit index and the index returned by FirstEmpty() retrieving the true first empty index. If this special case occurred, this pass is complete, continue.
Normal processing is to determine the swap index for our move of the adjacent next unit
that is out of place. Invoke FirstEmpty() with a midway start saving the returned index as our swap index. Now we have a unit to move and a place to move it to, but we are moving the next unit to make room for the unit that belongs there ! MoveUnit() the adjacent unit to our swap index, ie. move it out of the way. MoveUnit() the unit that belongs next, to the next index spot. ( use next value )
The cycle is complete, one down, many to go. Prior to exiting your thread method, ensure you set the thread member to null, indicating the thread is complete.
You will need to update the main UI as to the progress made by Defrag(). Determine an appropriate delegate type, and using Invoke() ( not Dispatcher.Invoke() ), invoke a string message back to the main UI thread to update the status listbox for each MoveUnit operation in the form “Defrag: Moved [N] to [M]”.
To finish wiring up the UI, implement a toggle action on the button so it toggles between [Defragment] and [Cancel Defrag], using the thread member as both the indicator for the button text and the flag for your thread termination. Your thread should Invoke a message back prior to exiting in the form “Defrag:Thread terminated”
Mark completion rubric.
Part I : Basic UI, Load and Render to spec 30
Part II : Verify filesystem, functional, correctly identifies test files 30
Part III : Defragmentation, functional for supplied test files 40
Do not code more than a few lines before testing / debugging.
Do ask questions about functionality, operation, assumptions on your part.
- CMPE2300 – Lab01 – Defrag-o-matic
- Program Specification