Defrag() Before Sort() ???

[RandomClown]

MyDefrag Version: 4.3.1
OS: Windows 7 64bit Enterprise
RAM: 8GB
HDD: 720GB & 2TB

So everyone has been telling me, when I posted here in the past, that I shouldn't put in the Defrag() lines if I have sort functions.
In all this time playing with it, I call BS on that. [no offense]

It seems MyDefrag will defrag files only when it is the file's trun to be sorted; wont bother defragging files out of turn.

Dont bother defragging files out of turn to save time, right?

For this case following, it doesnt work well at all...

---------

BTW: This is for a horribly slow 20GB HDD a year back.

It doesnt seem to work out well when most files are split into a dozen fragments or more; at least the hours more of me waiting for a defrag implies that...

Step 1: Begin a new zone.
Step 2: If a file is in the way & not next in line to sort, move it past the end of the current zone. If a fragment is met, the same rules apply. Move the fragment, not the file, and do that for every fragment met.
Step 3: Place the correct file to sort.
Step 4: Repeat step 2 & 3 until the end of a zone.
Step 5: In the next zone, start from step 1.

Now for multi zoned scripts, fragments get moved over & over again for every zone it doesnt belong to.
EX: If a file is in 100 non-contiguous fragments near the beginning, each fragment met is moved individually past the zone's end. Repeat that 100 movement until the correct zone & correct position.

I find that highly inefficient. How I made this more bearable was to include Defrag() 1st.
Instead of the HDD moving each fragments for every zone, the HDD only needs to move the whole file.

---------

Other issue is that this "Defrag only when the file is next in line to sort" assumes the file wont be in use by the system or a program later.

I saw many times already that excluding the Defrag() line ended up in chaos & havoc.

Following the above instructions, imagine a large multi GB file is locked for just a moment. [ISOs, VHDDs, unfinished vid segments]
All of the fragments that are scattered everywhere are locked & in the way.
That means when MyD is defragging a file, it will be "fragged by the frags".

From what I have seen, MyD will fragment a file [at least for large files] if an "unmovable" fragment is encountered.
I seen this many times, so I know I'm not crazy.

BTW, the file that got locked was not locked. Maybe the system was poking its nose around while the file was being pushed to the end of the current zone.

Point is, the longer MyD takes to defrag, the more chances there are for a file to be marked unmovable. I defrag 1st to reduce the chances of the chaos from happening.
Of course, it happens a zillion times less while in safe mode, but I want a usable computer as well, so no safe mode. I rather close all my programs except MS Word or whatever I need.

This happened many times, most recently today. To make sure this is absolutely true, I will try my idea in the near future when I have time.

--------

Attachments...
Default Monthly Script: Pic of the results from MyD unchanged monthly script.
HDD Setup: Doubt its necessary, but if you want to know. Partition layout wont change the defrag result.

I understand the unmovable file will be the way it is, unmovable, but the heavy fragmentation from movable files is ridiculous.

One of the fragments is a VM's virtual disk. Virtual box is closed. No trace in Process Explorer / task manager.
In the middle of "pushing" it to the next zone, it locked up. Lock Hunter showed it was not in use.
That file was the major reason for the horrible bitmap.

Strange thing is, the VHDD I mentioned above was forever marked red for all new instances of MyD until I remove the dat file.

=====

Something I picked up from my programming classes:
In theory, theory & practice are the same. In practice, they aren't.

In theory, its better to exclude the Defrag() lines if you already have sorts.
In practice, its not always better.



I really dont have the time [days] to sit in front of a monitor & screw around with different script while DDing to a previous disk image. That takes ages...
So, the reason for this post:

- What is everyone's experience with relying on Sort() to defrag flawlessly? Does it actually work for you?

- Do you think its better to Defrag() before sorting?

- Not in theory, but in practice, does MyD actually go back to defrag a previously unmovable file?

- Do you think I'm a complete noob?

[RandomClown]

For the sake of organization, I will make a 2nd post. That 1st one was a bit...messy.

When I say I defrag before sort, I mean defrag only. Next script sorts.

Also, I wasnt expecting the forums to show an attachment if its a picture. Was hoping to conserve space.

[Kasuha]

I understand your point but what you really need is not defragmenting the drive before sorting it, you just need to put all files above the place where their zone starts to avoid getting these files rolled around the drive. This can be accomplished by running a script that uses the same disk layout (i.e. file-zone assignments) but with just a single MoveUpToZone command for each zone that needs that (for standard layout for all zones above zone 3). This command defragments files too, but only does so for files starting below the zone. Then, during the sorting run, all file fragments lying above their zone boundary have about 50% chance of getting placed in just a single move, the rest in just two moves. Defragmenting these just adds up more unnecessary moves to the file data.

Another point is that sorting up a drive that has never been optimized by MyDefrag before is significantly more tedious task than doing that for a drive that already has majority of files placed correctly according to MyDefrag layout. Especially if the drive is full it may take long and run into various problems. In such a case, defragmenting the drive first may improve things ... or it may not, it really depends on the situation.

Another point is that sorting commands use different strategy than filling commands. Basically when sorting, the wrap-around fragmentation is used (unless you turn it off) and if a file gets wrapped around a small chunk of data unmovable just at the time of the move it may seem like it fragmented the file (because it will color the file right after the move) but in fact it's quite harmless, the file is actually very close to being perfectly optimized. So the thing is to not get nervous about these yellow stripes if you are sorting - they are ok, perfectly usable and will get fixed the very next daily run anyway.

Personally I don't use sorting commands on anything but the MFT and directory zones and I am pretty happy with the result. The performance may be slightly lower than if the important zones are sorted but it comes out much faster and the performance drop is in my opinion negligible, actually smaller than what I'd spend on sorting the drive.

[RandomClown]

Thanks for replying.

Thats interesting. I never would have considered excluding the sort() instead.


I have noticed the files splitting in small amounts like you explained. I guess that makes sense it is near perfect anyways. Although in some of my bad cases, the VHDDs tend to be a few thousand fragments in larger chunks, so it gets a little worse than that. Thats what I get for making dynamic VHDDs on an OS volume.