placement optimization etc.

[edo]

I'm coming up to speed with ASC & SD in vista x64 and have a few questions.

 

The SD window carries the line "Defragments only...without file placement optimization." Does this mean that neither ASC or SD can put the most-used files together at the outer part of the HD, or an I missing some configuration item? (I'm just curious; I hardly think that all of the defragmented files could all go at the top of the chart with such large cluster sized and large skipped file fragments. I've got e.g. a 60G virtual machine on a 500G HD, and unmovable files (what I'm guessing are system & media files) are all over the place. I realize that the idea is that it's easier on the HD to search for >1G fragments than to attempt to keep these in one place. As an experiment I defragged with the 1G limit, which left something like 50 fragmented files and a few percent unfragmentation; then I did it again after setting the limit to the 10Gmaximum. The program then reported 0% fragmentation, which I take with a grain of salt. The chart showed very little difference from that at 1G. And my machine is fast enough anyway that I didn't expect to see a performance difference.)

 

I was surprised, though to see that the MFT was defragmented over a few clusters. I'm coming to vista x64 from W2k, where everything looked a bit tidier. But am I correct in assuming that a fragmented MFT is no problem?

 

One other question: What's the relationship of Disk Doctor & the Care! scanner in ASC to SD?

 

Sorry for these vague questions. I've had poor luck with other registry cleaners & disk utilities, and I want to have a good knowledge of what the IO products are showing me & what reports I have to save in the event that problems show up. So far I'm very pleased with ASC/SD.

[solbjerg]

Hi edo

First I will recommend that you read Usage of IObit Products and Thinking about defragmentation - links in my signature.

Then some of your questions:

Of course not all files can be placed at the outer rim - they are sorted by how much they are used and by date and placed in that order IF you choose Fast Optimize or Deep Optimize as the method of defragging if you use the Just Defrag option they will just be defragged - this option is prudent to use if your disc is very fragmented for the first defragmentation.

I use SD without ticking the size limit, but that is because I don't have enormous files placed on my C:\ drive those I have moved to another drive or to my external harddisks - in other words dependent on the configuration (file -wise) you have chosen for your disk.

It would have been good with some information about how filled up your harddisk is.

I recommend to never fill it to more than 75% of it's capacity.

Most defragmenters -also Windows own cannot defragment if the disk has less than 15% free space - and if they can the process will be rather slow.

One of the possibilities you have in ASC with the extras is to run a defrag of your registry - this may take care of some of the MFT "problems".

Disk Doctor does some of the same things as ASC but you are able to better see what it does and choose directly what to take care of.

As I said - please read Usage of IObit Products - I am sure you will benefit from that :-)

Cheers

solbjerg

 

 

 

I'm coming up to speed with ASC & SD in vista x64 and have a few questions.

 

The SD window carries the line "Defragments only...without file placement optimization." Does this mean that neither ASC or SD can put the most-used files together at the outer part of the HD, or an I missing some configuration item? (I'm just curious; I hardly think that all of the defragmented files could all go at the top of the chart with such large cluster sized and large skipped file fragments. I've got e.g. a 60G virtual machine on a 500G HD, and unmovable files (what I'm guessing are system & media files) are all over the place. I realize that the idea is that it's easier on the HD to search for >1G fragments than to attempt to keep these in one place. As an experiment I defragged with the 1G limit, which left something like 50 fragmented files and a few percent unfragmentation; then I did it again after setting the limit to the 10Gmaximum. The program then reported 0% fragmentation, which I take with a grain of salt. The chart showed very little difference from that at 1G. And my machine is fast enough anyway that I didn't expect to see a performance difference.)

 

I was surprised, though to see that the MFT was defragmented over a few clusters. I'm coming to vista x64 from W2k, where everything looked a bit tidier. But am I correct in assuming that a fragmented MFT is no problem?

 

One other question: What's the relationship of Disk Doctor & the Care! scanner in ASC to SD?

 

Sorry for these vague questions. I've had poor luck with other registry cleaners & disk utilities, and I want to have a good knowledge of what the IO products are showing me & what reports I have to save in the event that problems show up. So far I'm very pleased with ASC/SD.

[Toppack]

The SD window carries the line "Defragments only...without file placement optimization." Does this mean that neither ASC or SD can put the most-used files together at the outer part of the HD

 

No, There's no placement options in SD 1.5 :sad: (no - not manually - but automatic)

 

Where Oh Where is Version-2!:lol:

[enoskype]

Well, no manual placement option, but SD 1.5 has the automatic fast and deep placement optimization though.:grin:

 

Where is the version-2?

 

Soon!!! :lol:

 

Cheers.

[Toppack]

I was surprised, though to see that the MFT was defragmented over a few clusters. I'm coming to vista x64 from W2k, where everything looked a bit tidier. But am I correct in assuming that a fragmented MFT is no problem?

 

Now that you mention it, I've always wondered about that also :!:

Even back in the Win-98 version of defrag, the drive seemed to be more organized, with everything moved to first part of graph (with No free-space holes).

'Tidier' is a good word. ;-)

Even Deep-optimize does Not do that.

I don't know if everything being moved to first part of graph means that they were moved to more efficient outer-edge or not, but it did make a Prettier graph. :lol:

[solbjerg]

Hi Toppack

Seemed is a good word! :-)

As far as I remember the win98 defrag it showed 3 colors, one for the defragged space another for blocks from the middle of the disc and a third for blocks from the end of the disc. When it finished it showed all blocks as blue if I remember correctly.

That certainly looked tidier, but there wasn't much information in it :-)

By the way I recommend that one should run a chkdsk at least once a month!

Cheers

solbjerg

 

Now that you mention it, I've always wondered about that also :!:

Even back in the Win-98 version of defrag, the drive seemed to be more organized, with everything moved to first part of graph (with No free-space holes).

'Tidier' is a good word. ;-)

Even Deep-optimize does Not do that.

I don't know if everything being moved to first part of graph means that they were moved to more efficient outer-edge or not, but it did make a Prettier graph. :lol:

[Toppack]

Solbjerg, what I and 'edo' were referring to is the way the older degrag programs moved the MFT and All other files Together with no free-space gaps. (compacted so free-space is only at end of drive, which I assume was the inner part of platters)

 

That way there's less chance of encountering a contiguous free-space problem, since all the free space was moved together.

(Which seems to be one of the biggest problems when using SD, when hard-drives start getting Full)

 

Not about the colors or the amount of Info provided by them, since that amount of Good Info has definitely Improved in SD.

[solbjerg]

Hi Toppack

Yes, but here we again run into the problem what the best placement is :-)

Some advocate that some free space around MFT and other unmovable blocks be reserved for new MFT blocks and new unmovable blocks. Some even argue that som free space at the outer rim is good?

And as I said I advocate to never fill the disc to more than 75% of capacity - and to run a chkdsk fairly often.

The speed at the outer rim I have calculated to be about 3 times faster than the speed at the inner edge of usable space on the disc. To that one has to take into account that the reading heads travels from the outside and in, and this has to be calculated to, but I have no data on how fast they move at this point.

Cheers

solbjerg

 

 

 

Solbjerg, what I and 'edo' were referring to is the way the older degrag programs moved the MFT and All other files Together with no free-space gaps. (compacted so free-space is only at end of drive, which I assume was the inner part of platters)

 

That way there's less chance of encountering a contiguous free-space problem, since all the free space was moved together.

(Which seems to be one of the biggest problems when using SD, when hard-drives start getting Full)

 

Not about the colors or the amount of Info provided by them, since that amount of Good Info has definitely Improved in SD.

[Toppack]

Yes, there are many optimum placement questions

but I was mainly focusing on the 'lack of contiguous free-space' problem, that seems to be a Very common problem.

Which would be greatly improved by file & free-space compacting.

[solbjerg]

Hi Toppack

Yes it can be a problem especially for those that fill up their disks close to capacity.

But isn't the best solution then to get a larger harddisk or move some of the accumulated files to another disk, - they would have to eventually -even with free-space compacting, don't you think?

Cheers

solbjerg

 

 

Yes, there are many optimum placement questions

but I was mainly focusing one the 'lack of contiguous free-space' problem, that seems to be a Very common problem.

Which would be greatly improved by file & free-space compacting.

[Toppack]

Hi Toppack

Yes it can be a problem especially for those that fill up their disks close to capacity.

But isn't the best solution then to get a larger harddisk or move some of the accumulated files to another disk, - they would have to eventually -even with free-space compacting, don't you think?

Cheers

solbjerg

 

Yes, but we are seeing reports of users having that problem with about 100.GB of free space still Available, since that 100.GB is Broken up in many Small free spaces all over the drive. If all the free space was moved to one large contiguous space, then that problem would Not be encountered, for a much longer time. (depending on how fast the drive is completely filled of course)

100.GB is a lot of free space for most users.

[solbjerg]

Hi Toppack

It certainly is - but it is still only 10% of a terabyte :-)

Cheers

solbjerg

 

Yes, but we are seeing reports of users having that problem with about 100.GB of free space still Available, since that 100.GB is Broken up in many Small free spaces all over the drive. If all the free space was moved to one large contiguous space, then that problem would Not be encountered, for a much longer time. (depending on how fast the drive is completely filled of course)

100.GB is a lot of free space for most users.

[Toppack]

Since I can't Wish for new Terabyte drives for all SD users, I can only Hope and Wish that 'contiguous-compacting of file and free-space' will be added to Version-2, to help with the 'contiguous free-space' problem. ;-)