"smart" philosophy on big files.

[davexnet]

If you have a data partition (non-system) made up of mostly small

files (< 30MB) and about 10 files of 500MB - 1GB on size,

what is the philosophy for a "smart" defrag.

 

I'm asking this because I don't see any of the current defraggers

doing a good and efficient job.

 

I'd like to see the defragger make a "best effort" pass on the big files.

For example, if it takes 5 minutes to reduce them to 5 extents, but half an hour to reduce them to one extent, leave it at 5. That's fine for a

big media file.

 

You see my point? A more intelligent way of handling the big files.

 

The present method of just disregarding big files over a certain size

is lazy programming - there should be a middle ground, as mentioned above.

[Toppack]

There are actually 8 different file-size options.

1 with No files skipped (with check removed) and 7 size options, with the selectable slider (with box checked).

(The slider control is in Settings / general-settings page)

 

I understand that an 'extent' is a contiguous area of storage in a computer file system,

but I thought a file is not truly Defragmented until all parts of that file are made contiguous?

So, only doing a portion of the process is Not truly Defragmentation, correct?

[davexnet]

There are actually 8 different file-size options.

1 with No files skipped (with check removed) and 7 size options, with the selectable slider (with box checked).

(The slider control is in Settings / general-settings page)

 

I understand that an 'extent' is a contiguous area of storage in a computer file system,

but I thought a file is not truly Defragmented until all parts of that file are made contiguous?

So, only doing a portion of the process is Not truly Defragmentation, correct?

 

Yes, but as far as the performance of the data disk, it gives me no benefit

if the big file is in one extent, Vs. 5 or 10 or 15. If the file is in 1000

extents, that's another matter.

 

If I can defragment that 1000-extent big file to 5 or 10 extents in

5 - 10 minutes, that's good enough.

 

No need to thrash the HDD running the defragmenter for hours to try

and get the big file into one piece. Why incur all the wear and tear on

the drive and all that extra time?

 

There used to be a version of Diskeeper that had a mode that

could make these "Smart" decisions about big file handling.

It was the only defragger where I've seen such an algorithm.

NO need to specify a "size" of file.

 

It looked at the file mix, amount of free space, did the best it could in a

quick defrag.

 

In my mind that is the best way to defrag a HDD when you have a mix of

small and large files on a non-system disk.

 

Defrag considerations for system disks, with the boot files,

program files, etc,etc is completely different to a non-system data disk.

Containing, a mix of big media files, folders of photo's, folders

of mp3's, AVI & MPG files, etc,etc.

[Toppack]

Okay, now I understand what you are asking about.

I can certainly see how that option could save time, the first time a well used drive is defragged, but after that the next defrags take very little time.

So, after getting past that very time consuming First defrag that option would not be needed as much.

 

I'm wondering if the advantages of such a complicated programming addition would really be appreciated or needed by the average user?

At least it sounds like it would be Very Complicated to do? (but I'm not really a programmer) :wink:

[davexnet]

Okay, now I understand what you are asking about.

I can certainly see how that option could save time, the first time a well used drive is defragged, but after that the next defrags take very little time.

So, after getting past that very time consuming First defrag that option would not be needed as much.

 

I'm wondering if the advantages of such a complicated programming addition would really be appreciated or needed by the average user?

At least it sounds like it would be Very Complicated to do? (but I'm not really a programmer) :wink:

 

I'm not sure what it would take programming-wise. The first thing you

would need to work out would be the criteria

for making decisions on the individual files.

 

As I mentioned, Diskeeper used to be able to do it (I haven't seen any recent

release so I don't know if it's still there. It was called "file performance"

mode). It was perfect with the kind of disk I'm talking about.

No attempt to optimize based on date - it's not necessary with this kind of

data - just a very quick, best effort defrag that worked great for

a big/small file mix.

 

It's a useful defragment option. In this kind of data disk,

the partition tends to be volatile.

It's content potentially changes often. For those

that do a lot of video and audio capture/encoding,

those big files will come and go.

 

I don't know if IObit would find my suggestion useful or not.

Does Smart Defrag make any distinction between

system and non-system data disks? The way files are accessed on

each type is completely different. A good defragger should have a

way to differentiate because the defrag considerations are

not the same.

[Toppack]

Does Smart Defrag make any distinction between

system and non-system data disks? The way files are accessed on

each type is completely different. A good defragger should have a

way to differentiate because the defrag considerations are

not the same.

 

I doubt they would look different to SD.

I don't understand why they would be accessed differently?

To me, a System drive is one with a bootable Operating-system on it

and a Non-system drive is one that does Not?

So, why wouldn't both's files look the same to SD, except for the OS portion which I think would be Non-movable data?

(And SD just skips over all that Non-movable data)

[Toppack]

I forgot to mention that in Vista and Windows-7 the System drive partition is Hidden. So, with those OSs SD would Only ever see Non-system drives, unless another OS has been installed Also. (which can be done by adding virtual-XP)

[davexnet]

I doubt they would look different to SD.

I don't understand why they would be accessed differently?

To me, a System drive is one with a bootable Operating-system on it

and a Non-system drive is one that does Not?

So, why wouldn't both's files look the same to SD, except for the OS portion which I think would be Non-movable data?

(And SD just skips over all that Non-movable data)

 

Good morning -

conceptually, they seem different to me. The system drive is defragged to optimize

the boot files so that the PC boots faster, and application files so that programs start

quicker.

 

When a program is started, it accesses anything from a few to hundreds of files.

BY having these files defragged and placed well, HDD head movement is reduced,

file access is faster and more efficient, giving the perception of faster

load times.

 

On the otherhand, the files on the data drive are not accessed when programs

are started. They are likely to be accessed, one or two at a time when the

program is running. Therefore the placement of such files is not really critical,

and possibly their level of fragmentation has less of an impact. However,

when the mix is small and large files as I mentioned before it can get out of hand.

 

That's why I mentioned the type of defragment for this data drive. It's quick

and it's good enough. All the file placement stuff is not needed, just defrag

the files and it's done. It's quick and it doesn't thrash the drive - and it doesn't matter

that they may not be completely defragged.

[davexnet]

I forgot to mention that in Vista and Windows-7 the System drive partition is Hidden. So, with those OSs SD would Only ever see Non-system drives, unless another OS has been installed Also. (which can be done by adding virtual-XP)

 

Not sure what you mean - are you saying SD cannot defrag the system

drive in Vista and WIn 7? Many third-party defraggers wotk just fine in Vista

(all though there is the issue of the shadow copy and deleted restore points).

[Toppack]

are you saying SD cannot defrag the system drive in Vista and WIn 7?

 

Correct, Other programs do Not have access to the Hidden System partition, in those OSs.

It is Completely Hidden, which is Great for Many reasons.

(There is never any fragmentation of that partition anyway, since data on that partition is not normally changed by user)

(The Registry, MFT and any other User-config files are still stored on c: drive, which is a Non-system drive)