Defrag inside a VM. Would there be any point?

D

DevilsPGD

In message <[email protected]> Bo Berglund
<[email protected]> was claimed to have wrote:

>I tried Contig on an 80 Gb drive with a 25 Gb VHD file and an ISO and
>some other files (in total about 10-15 files totalling 14 Gb).
>So I have 41 Gb free.
>Unfortunately even though I have run Contig several times and also
>used the WinXP dfragger on the drive my VHD will not glue together....
>It is now sitting with 4 fragments and when I view the graphics in the
>WinXP defragger I see big chunks spread out evenly across the drive.
>:-(

This is typical. Vista's defragger doesn't even touch huge files, and
for good reason, the reality is that it's a very minor performance
impact to seek four times while reading 25GB of contiguous data.

For special cases (VHDs being a prime example) it would be beneficial,
but in the general case, this type of fragmentation doesn't really hurt
performance at all.

>Why is none of these products able to consolidate the data towards the
>start of the drive so the free space is contiguous and a big area?

That one is easy -- When you're writing small files to disk it's usually
advantageous to group directories together. As a result it's generally
not a bad idea to leave gaps, and NTFS does tend to group new files
appropriately, more or less.

Again, there are special purposes, a drive devoted to VHDs, or system
backups, or ISOs or machine images or whatever where this doesn't make
sense, but unfortunately most defragmenters aim for the general case
exclusively.
 

My Computer

B

Bob Campbell

"DevilsPGD" <[email protected]> wrote in message
news:[email protected]

> In message <[email protected]> Bo Berglund
> <[email protected]> was claimed to have wrote:
>

>>I tried Contig on an 80 Gb drive with a 25 Gb VHD file and an ISO and
>>some other files (in total about 10-15 files totalling 14 Gb).
>>So I have 41 Gb free.
>>Unfortunately even though I have run Contig several times and also
>>used the WinXP dfragger on the drive my VHD will not glue together....
>>It is now sitting with 4 fragments and when I view the graphics in the
>>WinXP defragger I see big chunks spread out evenly across the drive.
>>:-(
>
> This is typical. Vista's defragger doesn't even touch huge files, and
> for good reason, the reality is that it's a very minor performance
> impact to seek four times while reading 25GB of contiguous data.

Again, I don't understand this obsession some folks seem to have with
defragging!?!? It made sense 20 years ago when I had Seagate ST-225
drives, but with today's fast drives and large caches, worrying about a 25GB
file in 4 pieces is borderline Monk obsessive/compulsive behavior.

However, if you MUST have 100% contiguous big files, copy them off to
another drive, format the original drive, then copy the files back. Of
course, as soon as you grow/shrink the files one or all will be "fragmented"
again.

Don't worry about it, it is not a big deal.
 

My Computer

D

DevilsPGD

In message <[email protected]> "Bob
Campbell" <[email protected]> was claimed to have wrote:

>Again, I don't understand this obsession some folks seem to have with
>defragging!?!? It made sense 20 years ago when I had Seagate ST-225
>drives, but with today's fast drives and large caches, worrying about a 25GB
>file in 4 pieces is borderline Monk obsessive/compulsive behavior.

The obsession is simple: Drives are often *the* bottleneck on modern
computers.

You can tweak the last few percentage points of CPU speed out, for those
few seconds a day where your CPU is maxed out, but otherwise it doesn't
matter. Paying double the money for faster RAM only takes you from
"good" to "great".

Hard drives are often the one major performance bottleneck and they're
not one that can be trivially upgraded.

I agree with you regarding a 25GB file in several pieces, and I
expressed that agreement in the very post you're responding to, but for
those of us working nearly full time in virtual machines it's a fun
hobby to squeeze every little bit of performance out of the hardware
that you can.
 

My Computer

D

DevilsPGD

In message <[email protected]> "Bob
Campbell" <[email protected]> was claimed to have wrote:

>"DevilsPGD" <[email protected]> wrote in message
>news:[email protected]

>> Hard drives are often the one major performance bottleneck and they're
>> not one that can be trivially upgraded.
>
>But if you are doing things that are hard drive bound (actual data
>processing where you are taking 1 big file or several small files,
>updating/combining/sorting them and writing them out as new files) then a
>better solution is a 2nd or even 3rd hard drive.

Agreed. However, this solution doesn't scale very far.

>I did this for years in the 80s and 90s when I was
>creating/updating/reformatting/sorting mailing lists. These would be lists
>of many sizes, from 10,000 names to 500,000 names. The input file is on
>one drive, the output file goes to another physical drive. This minimizes
>head movement and speeds the process up *tremendously*. Try sorting
>500,000 records on a single drive, then do it on 2 drives. No contest.
>
>I do the same thing today. I normally have 2 or 3 VMs (XP, Vista Business
>and Server 2003) running on this Vista 64 host machine. I have 3 physical
>hard drives (each 500 GB SATA II). Each VMs VHD file is on a separate
>drive.

For the scenario where you have a small number of VMs, this is
definitely the way to go, but not all usage patterns fit this model
nicely.

I have a collection of about 8 VMs prebuilt that I fire up upon demand,
several with a variety of snapshots to let me rapidly deploy a test
environment and I can easily use 4-6 of them at once. Installing 8
additional hard drives isn't impossible, but it's not practical.

Heck, even four more drives would probably require a pretty significant
investment in terms of the controller cards, physical mounts and power
and power supply requirements.

Another example, at $DAYJOB our VMWare based testlab currently has 122
VMs running spread across two physical machines. In this environment
fragmentation is a very big deal.

Also consider that all other things being equal, the higher the density,
the better the performance.

A 1TB drive will run proverbial circles around a 320GB drive if you
create a single 320GB partition on each. Both drives (if they're in the
Seagate 7200.11 family) have an average seek time of around 8ms and a
maximum seek time of about 11ms, but if you have two 140GB files each
stored contiguously and being read simultaneously, the seek times on the
320GB will average around 8ms, but on the 1TB drive will average under
4ms due to the higher density.

(Note that I am assuming identical number of platters, cache sizes, etc)

In other words, under certain circumstances and an optimum fragmentation
scenario you'll actually see better performance running two VMs on one
larger drive then you will from two smaller drives for random access
read/write scenario (like booting an OS and launching applications)

Now that being said, I don't stress about fragmentation once the
fragments are over 1GB or so per fragment, the law of diminishing
returns kicks in very quickly as fragment sizes go up, but at the same
time I do like to squeeze every last bit of performance from my existing
hardware that I can.

This isn't a new thing for me, I was that guy who would spend a day
prying out that last 3KB of convention memory back in the DOS days. It's
not always practical, but then a hobby doesn't need to be :)
 

My Computer

Top