Further my contribution on another thread (hereunder for convenience), I continued... It's been a week and I'm down to 169 fragmented files and 547 fragments, and the program has begun horading CPU resources (50% avg) and reducing disk activity to one file per second... and the counter still shows 38% ... and as the program works it seems to be actually FRAGMENTING files based on the what I can see on the disk map with a first line solid blue defrag activity (in which most of the read/write activity is taking place) and now 4 lines of intermitent red and light blue, plus red blocks being written at the end of the map space...
Something is very wrong here. I have the feeling that taken separately, RAID 5, Vista 32-bit or WOW on Vista 64-bit, are not sources to any particular inconvenience. Put together, however, it's like watching your disk structure slowly and inexorable crumble to shreds... I now revert to MS stuff, and hope you will be able to make this work under the above settings sometime soon.
I'm a 50 year-old researcher in management that has used just about all programmable calculating devices available to consumers since the TI-57 calculator 35 years ago. This is the first time I've encountered such an experience with so little feedback from the developpers.
I trust you will come up with a new algorythm soon.
- - - - - - -
Last Post: http://forum.piriform.com/index.php?showto...;hl=Douweiqiang
I'm running a fairly fast machine for calculus and stats -not gaming- (Quad 3Mhz + 8 Gb RAM at 1033Khz on an ROG motherboard) under vista 64 and RAID 5 with 1.5 Tb total space of which 25% are used for the moment.
I began running defraggler on wednesday Feb 4th evening and... still running it 4 days later... I stopped yesterday morning for half an hour, updated and got back on letting the machine complete the task. I stopped the task once more for work purpposes yesterday afternoon, and got it back to defrag once more. It's defragging as I write on "normal" setting.
What I've noticed:
1. Defraggler works rather rapidly during the first 20 minutes or so. Then drops to very slow (what appears to be 20 files per second using average 25% cpu on all 4 cores with 35% peaks).
2. Total file size has increased, according to already documented vista restore files issue, but not that much. Anyhow, MS suggests one should keep 1/5th of total drive space free for "headroom" especially with smaller HDDs.
3. For the first defrag, I had about 850 defragged files and about 2000 fragments. I updated at 39% of the task. After update and hardware restart, I had around 500 files and 1600 fragments to start with. I had to run some calculus simulations, so I stopped defraggler at 29%. When I was through, I did a hardware restart, and put defraggler back on the job. The app came up with 240 fragged files (155.5 Gb) and about 1400 fragments. It's been running for 15 hours this time. It's at 36%defrag and has 174 files, 589 fragments, and 155.1 Gb left!!
4. Files were originally situated in the middle of the "map" and are in the process of being moved to the beggining. I now have a nice solid blue line at the top, and a very appealing bright red middle. Which would tend to explain the slow defrag speed, since defraggler is having to cope with RAID-5 redundancy when moving all of the data contained in the files from one place to another on the disks.
5. Moving the files around this way, naturally increases fragments during the defrag process and makes rebooting a bit longer than usual, yet remains within the "bearable" limits of less than 3 minutes (for a machine such as this one). I'm happy with 5 minutes for my laptop.
6. Other than the issue of increased boot time, nothing to say on the RAID-5 side of things, for the moment.
7. I checked the defrag with Tune-Up and found that the mapped "red" files were all blocked and only the "blue" files were available for defrag. The MS Vista onboard defrag tool does not provide a visual, so canot tell. This would tend to say that while Defraggler has not finished, the files defragged by defraggler are blocked, which is OK if you are going to continue defragging with Defraggler, but could cause an issue if you run into heavy waters, and should Vista need to move these files around (if they are also blocked for Vista). We'll see what happens once the job has been completed.
(Yes, I'm a backup maniac)
I do hope that as the process goes over the critical defrag/rewrite point, things will speed up. I would expect this point to be located somewhere around the 65% to 70% defrag mark... and in about 3 more days...
IF Defraggler moves files around only once, then subsequent defragging experiences should be noticeable shorter in time.
Perhaps an option, and otherwise a warning, should be posted about the data re-arrangement time consequences (and the need to run a full backup before defragging). I did not see anything on this issue in pirifom.doc, nor any of the Piriform forums I consulted. I may have missread. Please correct me if I have.
Hoping these lines help.