CMPE2300 – Lab01 - Defrag-o-maticIn this lab you will create a simulator to implement a file system defragmentation. Prior toSSDs, file systems benefited from ensuring files that were comprised of m

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.

Program Specification

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”