• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

[O/C]Realities of Hard Drive Fragmentation

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.
HDTune ignores file fragmentation

I hate to rain on your parade, but using HDTune to measure performance is pointless, since it completely ignores the layout of the files, fragmented or not, and just does a direct read from the drive. This test can be run on a drive that has not even been partitioned or formatted.

So, unfortunately, your test results prove nothing other than the margin of error involved in measuring a hard drive performance when there are other system processes running.

I have not used VirtualBox, and you have not explained how Virtualbox maps its image sectors to the drive image it created; or whether the 15GB image, once restored in each case, was fragmented or not.

HDTune was not designed to be run inside a virtual environment, so I don't see how you could rely on it for accurate measurements.

Your tests need to read the speed with which a FILE can be read, not a hard drive sector. HDTune reads sectors.
 
What about PerfectDisk?

One other important omission: PerfectDisk has for some time been touting its ability to do a defrag INSIDE a virtual environment. I'm not sure if VirtualBox is supported, but you should at least have tried it out.
 
I hate to rain on your parade, but using HDTune to measure performance is pointless, since it completely ignores the layout of the files, fragmented or not, and just does a direct read from the drive. This test can be run on a drive that has not even been partitioned or formatted.

So, unfortunately, your test results prove nothing other than the margin of error involved in measuring a hard drive performance when there are other system processes running.

I have not used VirtualBox, and you have not explained how Virtualbox maps its image sectors to the drive image it created; or whether the 15GB image, once restored in each case, was fragmented or not.

HDTune was not designed to be run inside a virtual environment, so I don't see how you could rely on it for accurate measurements.

Your tests need to read the speed with which a FILE can be read, not a hard drive sector. HDTune reads sectors.

I agree, that this is an important part of what would have been considered here. It's a low level benchmark that ignores the filesystem near as i can tell.

Any test that actually reads files, writes files etc using a batch script or some other type of benchmark would have been better. PCMark tests the disc, doesn't it?
 
Donn, thanks for your input, its clearly helpful to draw these concerns out.

I haven't personally investigated this, but trusting your word as I don't have time to verify right now, let's assume we should use something else. Do you suggest a more appropriate tool?

Also, everything considered here is free, does perfectdisk offer a free version? (EDIT: It appears a 30day trial is available, I'm not familiar if any of the items considered in this article are trialware)

The great part about having community input is that we get good review of our articles. Hashing it out and making the corrections is not a problem - our goal is to relay good information. Overclockers has always been about free speech and publishing reader and member generated content, so anyone can respond in comments or in article form to keep everyone on their toes.
 
Last edited:
Ah. Seems there is something I missed by using HDTune. I am more than open to anything that improves my testing methods. I still have the base testing image ready to go. Of course, it will take a full night per defragger to re-run the tests... but anything worth doing is worth taking the time to do it right.
 
It might not be as bad as that. If I understood your methodology correctly then you ran HDTune inside the VM. If this is the case then it doesn't have access to the underlying hard drive, only to the virtual hard drive. And since the virtual drive is a file on the real drive, then the fragmentation of the virtual-drive-file would have an impact on the results of HDTune.

What I am not sure of it how the fragmentation inside the virtual drive relates to the fragmentation of the virtual-drive-file and what exactly the defragmenters do when they defragment inside a VM.
 
right now.... all I can say is there is work going on behind the scenes to see if there is a way to improve the tests. I am more than willing to scrap these results if there is a better method to do the tests and get what I want: which is to prove if defragmenting/optimizing has an affect on raw read speed.

Just so any future readers know, I know that access time is a crucial part of defragmentation. However, i felt that a few milliseconds would be unnoticed compared to how fast it takes to read the file once it is found on the drive.

But again, if my methods are flawed, or if they are good but the tests are flawed, I am willing to accept that I made a big boo-boo and redo the tests after a method that can be agreed upon by me and a few others behind-the scenes can be found.

I don't feel it would ruin anything to say that Puran already contacted me with suggestions to improve my methods, to which I replied with some questions of my own. Even if this takes a while before I can retest, I will do the tests again if it is decided there is a better method to do this.
 
It might not be as bad as that. If I understood your methodology correctly then you ran HDTune inside the VM. If this is the case then it doesn't have access to the underlying hard drive, only to the virtual hard drive. And since the virtual drive is a file on the real drive, then the fragmentation of the virtual-drive-file would have an impact on the results of HDTune.

What I am not sure of it how the fragmentation inside the virtual drive relates to the fragmentation of the virtual-drive-file and what exactly the defragmenters do when they defragment inside a VM.


This may be true. I am not quite sure how it does so, but I know the image is 3 parts. 1 part is a config file (just a few kb in size), the other i'm not sure what it is, but it's just a few kb is size, and then the image file which is 14.9gb in size, as it's own seperate file on the drive.
 
Thanks for the article.

I am curious to see how UltraDefrag does in this test, since I keep hearing people mention it lately due to it being open source: http://ultradefrag.sourceforge.net/

Issues with the testing:

- The test setup seems a artificial, but was definitely a good and well-documented attempt to at least set up *something* useful.

- I don't see how deleting and restoring one large file over and over is going to have any effect on fragmentation of other files.

I've been using MyDefrag, but it's slow and doesn't do boot-time defragging. Maybe Defraggler or UltraDefrag would be a better choice.
 
What i noticed happening to my HD as i kept deleting the images and restoring it was the system reserve files ended up getting thrashed. I believe that was where most of my fragmentation on my 250gb main drive happened.

these tests were in an artificial environment. This was designed as semi-theorycrafting and mostly to see which defragger 'put humpty dumpty back together again'.

Currently am researching other tools to test HD performance to see if I can get more useful data and update the article.
 
Definately a great article!!! Good work!

One thing I would personally like to see is what are the real life benefits of this? The easiest to test would be boot times. Another idea that came to mind are file transfers before and after.
 
What i noticed happening to my HD as i kept deleting the images and restoring it was the system reserve files ended up getting thrashed. I believe that was where most of my fragmentation on my 250gb main drive happened.

these tests were in an artificial environment. This was designed as semi-theorycrafting and mostly to see which defragger 'put humpty dumpty back together again'.

Currently am researching other tools to test HD performance to see if I can get more useful data and update the article.
Definitely appreciate the effort, it's an interesting read.
 
earthdog said:
Definately a great article!!! Good work!

One thing I would personally like to see is what are the real life benefits of this? The easiest to test would be boot times. Another idea that came to mind are file transfers before and after.

You see? This is the sort of thing that should have occurred to me to test, yet did not! Thanks for the question Earthdog! In the next round of tests, these will definitely be added to the pool of tests. I guess the big thing on file transfer though, is how to properly do it. Do you mean copying a file from the drive back to the drive? Do you mean through the virtual network link from my machine to the VM? Or do you mean file transfer across the network?
 
The file transfer is going to be a tough one to measure consistently...Im not sure how to do it honestly. I would say have a huge movie or something, but presumably that would be contiguous and may not get defragemented...I dont know. I would say drive to drive would give you the best results though. With the network and VM's involved, I would imagine that would play a role in anomalous results with their overhead and how they function in general.

If I were in your shoes, I would look to see, somehow, how those things are tested and apply that.
 
You see? This is the sort of thing that should have occurred to me to test, yet did not! Thanks for the question Earthdog! In the next round of tests, these will definitely be added to the pool of tests. I guess the big thing on file transfer though, is how to properly do it. Do you mean copying a file from the drive back to the drive? Do you mean through the virtual network link from my machine to the VM? Or do you mean file transfer across the network?

Open-source filesystem benchmark: IOzone

IOzone will do that type of testing for you, although reading more it may be overkill. Not seeing many similar tools that are free, though.
 
Back