Defragment?

N

neilford

Junior Member
I am using build Parallels 3.0 latest build 4128. My dad, on his pc, was haing an issue regarding dskchk with disckeeper. I decided to fire up Parallels and run the system defragmenter in XP and it told me I needed to defragment my disk. I have just installed Parallels 3.0, upgraded from build 3188, which I did before really doing anything other than installing it, because I had just bought it. I have installed a few apps, but have not run them yet. So, my question is why would I need to run the defragmenter? I have less than an hour of time on this because I have been busy with other stuff. I can run my Windows system for months writing and deleting files without needing to defrag. The second question is, should I run the defrag program now? I have seen at least one thread on corrupted hdd image file. I am a little nervous to run this, if it is going to screw up my hdd file. Thanks.

neilford
 
There have been some good posts on this subject. You can find them by clicking SEARCH in the orange bar above. Defragmentation may have unexpected results on a virtual disk.
 
Do you think this is something that is bound to be rectified? I don't feel a need to defrag, but was curious as to why it would ask when I have done so little work on the volume. Would it be better to run from a boot camp volume than from a .hdd file? I have very little experience with virtual machines. I like the idea of the virtual disk, but I am not married to it.

neilford
 
Defraging is one of those things you have to experience first hand to appreciate. It either makes a big difference or you don't notice anything. Defraging in a virtual world requires a bit more thinking. Your virtual machine running on virtual disks can fragment, but so too can the host OS it is running on. So the right way to ensure you have an unfragmented world is to start at the start:

Before you begin, run some kind of perf measuring tool in OS X and in Windows, one at a time, so you can have a performance baseline to examine later.

1. Defrag OS X's file system. This will collect your VM into a contiguous disk region.
2. Defrag the VM's file system. This will defrag the virtual disk but will not affect the way it is stored in OS X. It will remain contiguous disk space.

You now have a nice, clean disk drive with a nice, clean virtual disk on it.

Run the perf tool again in each OS and compare results against the first run. Then answer this question: Was it worth all that?
 
neilford said:
Do you think this is something that is bound to be rectified? I don't feel a need to defrag, but was curious as to why it would ask when I have done so little work on the volume. Would it be better to run from a boot camp volume than from a .hdd file? I have very little experience with virtual machines. I like the idea of the virtual disk, but I am not married to it.

neilford
Click to expand...

During the installation there are a lot of files that come and go, so it would not surprise me that on day one the disk has a few loose sectors scattered about.
 
dkp said:
Before you begin, run some kind of perf measuring tool in OS X and in Windows, one at a time, so you can have a performance baseline to examine later.

1. Defrag OS X's file system. This will collect your VM into a contiguous disk region.
2. Defrag the VM's file system. This will defrag the virtual disk but will not affect the way it is stored in OS X. It will remain contiguous disk space.

You now have a nice, clean disk drive with a nice, clean virtual disk on it.
Click to expand...

dkp,

I agree mostly with what you say with a minor exception at least in my personal experience.

I've been using IDefrag since the unset of BC. The first time I was told I could not partition the drive and I should reinstall OSX, I knew what was happening. Even though the experts all said OSX does not frag, 15 years with Unix told me otherwise. In IDefrag, frags show up as "red" blocks.

Now my experience shows #1. above to be true. But not only is it contiguous it is also defragged. There is a difference. You can have a contiguous virtual HD or real HD that is completely fragmented yet contiguous.

As you state the next step is #2. However, I have found that after exiting Parallels and checking with IDefrag, the virtual although contiguous is once again fragmented.

Since OSX does not use the virtual HD who cares if it is fragmented! It is as you state still a nice contiguous block and XP still sees a defragmented virtual HD.

So you are correct regarding the final result. But those that go through the procedures, need to realize this or they might be defragging for eternity :)

ajm
 
HFS+ does on-the-fly defragmentation, but only for files with 20MB or less. That's why if you do move big files around a lot, a separate defrag utility like iDefrag may indeed come in handy. And obviously VM HDD files are much larger than 20MB, so... you get the idea.

For dkp's point to stand, by the way, the VM HDD must be a fixed one, not an expanding one. The act of performing defrag on an expanding VM HDD can 'expand' it, leading to fragmented state again. Therefore in this case, the correct procedure is to defrag in VM, compact, then defrag from OS X side.
 
The followups are both accurate. To do this right one has to both collapse white space within the file systems and put the files themselves in proper order. The objective is to minimize the movement of the disk's read/write head so just collapsing whitespace is only part of the job.

And it is also true that after defragging the virtual drive the host drive may again be fragged. In fact in the original write up I'd included a repeat 1 and 2, but decided to keep it simpler to demonstrate the larger point and that is performance gain as actually measured. Repeating 1 and 2 will further defrag the systems but not likely produce much performance gain over the first iteration. The consequence of defragging is declining returns on future defrag operations.

Now a truly important point was made regarding fixed vs self-adjusting virtual disk sizes and this is true even without virtualization. Any time you have both ordered your files and collapsed your white space, the very next time you edit or modify a file that causes it to grow will also cause it to fragment. This is what happens to a dynamically sized virtual disk. Once it's filled its contiguous space it necessarily has to fragment. Log files are notorious for this and are, sadly, some of the most frequently written to files on a system. There have been some schemes over the years where system files were put at one end of the disk and data files placed elsewhere.

It can make you crazy trying to get the most from it. So over time repeat the perf test (and hopefully you've preserved the perf test conditions so that the perf tests can be meaningfully compared), and when you think your performance has degraded sufficiently, defrag things again. Unless things are incredibly wrong on your system the gains will never again approach those following the first defrag operation.
 
I understand this, but there is a " critical mass " before XP starts to tell you that you need to defrag the disk. As I said, I have never seen this occur so quickly. Thus, my concern.

neilford



dkp said:
During the installation there are a lot of files that come and go, so it would not surprise me that on day one the disk has a few loose sectors scattered about.
Click to expand...
 
neilford said:
I understand this, but there is a " critical mass " before XP starts to tell you that you need to defrag the disk. As I said, I have never seen this occur so quickly. Thus, my concern.

neilford
Click to expand...
Having, as you stated just upgraded from Parallels 2 > 3, and since 3 does a rewrite of the Virtual HD, I would not be concerned.

Assuming you are using NTFS, if the situation continues, then it may be something that needs to be looked at. It wouldn't hurt to keep an eye on it, but don't become obsessed :)

ajm
 
You must log in or register to reply here.
Back
Top