Video Screencast Help

ERROR - to virtual partiton - could not defragment virtual partition

Created: 20 Mar 2013 | 5 comments

Hi,

I am having problems deploying my images from ghost console, and am receiving "ERROR - to virtual partiton - could not defragment virtual partition"

 

clients - chipPC thin client running windows embedded standard SP3 intel atom n270, 1GB ram, 2GB SSD hard disk

Server Windows 2003 R2, program version 11.5.1.2266.

Image is windows embedded standard . NTFS size 1998.3 MB, Data 1559 MB 

 

cd/bootable hard disks work fine - I can boot into WINPE - map a network share and upload the image, then name the machine.

However I dont want to visit the machines individually as I have more than 500 to image at once!

I believe the problem is when it is trying to create the virtual partition - it is trying to find continuous space perhaps....

When I boot into windows embedded, it does not contain the defrag executable in system32. I have tried dragging a copy in from WINXP but it is then missing .dll files.... If I try and load it into MMC it does not allow defrag to be used as a snap in - so I assume Windows embedded has defrag stripped out.

I have used a 3rd party program "JK Defrag Portable", and defragged the drive first and then re-imaged. this does not work. The Console always seems to want to defrag the drive....

the virtpart.dat file that gets created into root C: as part of the task is 207mb. I have deleted this and tried to run the task again. still the same impact.

any help much appreciated!

 

thanks

 

craig

 

 

Operating Systems:

Comments 5 CommentsJump to latest comment

EdT's picture

I do not believe that GSS contains any specific provision for SSD drives, and of course their method of equalising the life span of the flash cells is to move high usage areas (such as swap files) around the SSD, so effectively causing massive fragmentation. This has no consequence on an SSD drive as it takes the same amount of time to access any "sector" as there is no head or rotational positioning delay.

Consequently, unless there happens to be a command line switch that turns off any fragmentation checks, you are stuck with this behaviour, as you cannot really defragment an SSD.

What I am wondering however, is whether the presence of a largish virtpart.dat file on the SSD is leaving insufficient space on your SSD to actually transfer the image. Bear in mind that the formatted capacity of a 2Gb SSD is a lot less than 2Gb - maybe 1.8Gb, so there may be insufficient space available to hold both the virtual boot stuff and your image.

When you deploy from CD or external disk, there is no requirement for the local virtual partition stuff so the full SSD space is available for the image.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

MacBrinky's picture

Are you aware about this article?
TECH106753: Ghost compatibility with Solid State drives
https://www.symantec.com/business/support/index?pa...
This article mentions the limitations you need to deal with if using Ghost Solution Suite.

EdT's picture

@MacBrinky

Does Symantec's testing of SSD's include any long term testing, or just testing for function when the devices are new?  The article referenced makes no allowance for the internal management that SSD drives apply regardless of the controller interface.

How does the user's defrag message originate?  How does Ghost assess the state of fragmentation of any drive, whether rotational or SSD ?

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.

lidster's picture

What I am wondering however, is whether the presence of a largish virtpart.dat file on the SSD is leaving insufficient space on your SSD to actually transfer the image. Bear in mind that the formatted capacity of a 2Gb SSD is a lot less than 2Gb - maybe 1.8Gb, so there may be insufficient space available to hold both the virtual boot stuff and your image.

I think that the above was partly true in this instance but have since tested it with a few different sized images and unfortunately it is just down to dumb luck if the image will clone and rename through the ghost console..... I have had images with 350mb free space - that have been disk defragged before setting off the task that still dont work. I have had better results after compressing all old windows files which gave me 800mb free space on a 2gb drive. - but what happens after 3 months if I need to re-ghost the machine and the files are ineviteably fragmented on the drive?

 

Is there a way to stop it from passing the defragment command to the client?  as already discussed - it doesnt need to check on these drives for fragmentation....

EdT's picture

I have had a look through the Ghost command line switch options and there is nothing I have spotted which would turn off defrag checking.  Have you explored whether deleting the existing partition and creating a clean partition on the SSD makes any difference?

Other than that, unless someone from Symantec can offer any long term experience of SSD management, I suspect the answer is whatever you find that works for you, as there has not been any formal development of Ghost for a number of years.

If your issue has been solved, please use the "Mark as Solution" link on the most relevant thread.