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.
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 :
[Defragment] / Toggling to disable defragmentation
And a listbox for status output – population should always use insert so newest additions
Part I – Load FileSystem
Your application will be allowed to create class level members for the following :
• List of File Allocation Units ( structure )
• 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.
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
• 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”