Optimization script for Windows system drive (opinions?)

[MiguelMS]

Hello everyone

I "discovered" MyDefrag just two weeks ago, and I'm really really happy with it, because I started looking for a defragger that would allow the user to choose defrag method, place files on specified positions... a few years ago, but didn't find one... until now! Thanks a lot, Jeroen All other defraggers may be considered "brain-less" when compared to MyDefrag with a good defrag script.

With MyDefrag installed and working on my computer, now I'm trying to write a "perfect" (at least, perfect for me ) optimization script for a drive (partition) with a Windows installation on it. I've got Windows XP, but I would like to write it for 2000, XP and Vista.

I would like to give the script to anyone who may want to use it, but before this, I would like to ask everyone for suggestions, corrections, improvements... or whatever changes you consider my script may need.

On this script, I assume that every file can be moved, although some of them can't be moved in an active Windows installation.

First run of the "Slow optimization" script may be considered slow by some users (not by me, as I know it may be moving and sorting every file on the drive... it's as fast as it can be), but my idea is that next runs of "Fast optimization" script would be faster, as they would only be moving updated Windows files, or updated Program files. These files don't usually change, only when updating, or installing or uninstalling programs, and because there are gaps placed on some positions, these gaps allow for changes without having to move files placed after.

I have included a "Reserve MFT Zone" script too, that should be run once, before "Slow optimization", to allow Windows moving the MFT reserved zone near the MFT that is placed on the beginning of the drive. It first moves the MFT to the beginning of the drive, then adds a gap of 256 MB (Windows won't move the reseved zone there if the gap is smaller than 200 MB and there are bigger free space gaps), then reboot Windows so the MFT reserved zone is moved (I've seen this is the same idea as presented on MyDefrag forum some days ago... I would have saved myself a few hours working on this, but didn't see that message before...).

I have attached the scripts I have written so far, for anyone to comment.
Thank you everyone


P.S. I think this is the appropiate forum for asking this. If it isn't... sorry, where should I post this?

P.S. English is not my home language, so there may be mistakes in my post. Sorry, and feel free to tell me about them.


Attached scripts are final versions and are updated for MyDefrag 4.2.6

[Darlis]

Hi MiguelMS

• Take a look at the DismountVolume description. It should be used when MyDefrag is finished, to reallocate the NTFS reserved area. (Does not work on the system partition)
• ReclaimNtfsReservedAreas() should be placed before you move any files. Maybe the MFT, which is placed in the reserved area before, is moved out again.
• pagefile.sys and hiberfil.sys can not be moved while Windows is running.
• Keep in mind, that if you run from a boot CD to move the files above, ImportListFromBootOptimize() will not work -> lots of unnecessary file movement. Maybe you can make another script for this special case?
• Like the original Slow- and FastOptimization scripts, your are incompatible with each other too, because SlowOptimize uses Sort, which is likely to create fragments, and FastOptimize used Defragment.
• The last AddGap statements does nothing, because all files have already been processed until then.

I hope you found my comments useful. 

[jeroen]

• ReclaimNtfsReservedAreas() should be placed before you move any files. Maybe the MFT, which is placed in the reserved area before, is moved out again.

I see it's not mentioned in the manual, but ReclaimNtfsReservedAreas() will skip the NTFS system files, such as the $MFT.

• Like the original Slow- and FastOptimization scripts, your are incompatible with each other too, because SlowOptimize uses Sort, which is likely to create fragments, and FastOptimize used Defragment.

Version v4.1.2 no longer has this problem. FastOptimize now recognizes the wrap-around fragments created by SlowOptimize. The next MyDefrag version will no longer have a separate FastUpdate script.

[Darlis]

• Like the original Slow- and FastOptimization scripts, your are incompatible with each other too, because SlowOptimize uses Sort, which is likely to create fragments, and FastOptimize used Defragment.

Version v4.1.2 no longer has this problem. FastOptimize now recognizes the wrap-around fragments created by SlowOptimize. The next MyDefrag version will no longer have a separate FastUpdate script.

Ah, sorry. I forgot about this feature. 

[peters40]

Just to clarify, its ok to Slow Optimize monthly / Fast Optimze daily ?

peter

[jeroen]

Just to clarify, its ok to Slow Optimize monthly / Fast Optimze daily ?

Yes.

[Jerom]

I too shall ask:
its ok to "Slow Optimize" + "Fast update" -  monthly,
"Fast Optimze" (WITHOUT "Fast update") - daily.
"Fast update" - how the separate script - to carry out, it is not necessary ??

Best regards..

 

[peters40]

jeroen

I think the FAQ and Using MyDefrag sections needs updating on this issue

peter

PS awesome programe

[Darlis]

its ok to "Slow Optimize" + "Fast update" -  monthly,

It is OK, but it is not necessary that you run FastOptimize/Update directly after SlowOptimize. Both scripts will do minimal change to the disk.

"Fast Optimze" (WITHOUT "Fast update") - daily.
"Fast update" - how the separate script - to carry out, it is not necessary ??

Since Jeroen added the IgnoreWrapAroundFragmentation setting, FastUpdate/Optimize are almost equal. One of them will vanish with the next version.

[MiguelMS]

Take a look at the DismountVolume description. It should be used when MyDefrag is finished, to reallocate the NTFS reserved area. (Does not work on the system partition)

I see... I though that trying to dismount the volume at the beginning would make some unmovable files (NTFS metadata files) movable. But that will only happend if the volume remains unmounted, and if Windows automatically remounts it on next access (because of the script defragging the NTFS System files... or even any other program), then it won't do any good.

I'll remove that DismountVolume() line at the beginning of the script.

ReclaimNtfsReservedAreas() should be placed before you move any files. Maybe the MFT, which is placed in the reserved area before, is moved out again.

I see it's not mentioned in the manual, but ReclaimNtfsReservedAreas() will skip the NTFS system files, such as the $MFT.

Then it should be placed before moving any files other than the NTFS System files. So I had it right just because I was lucky I'll place that sentence before moving any files anyway to be sure

pagefile.sys and hiberfil.sys can not be moved while Windows is running.

I know, but I'm trying to write a script that may be used for both active and inactive Windows installations. So it's like, "if you can move them, then go ahead and place them here; if not, continue anyway".

Keep in mind, that if you run from a boot CD to move the files above, ImportListFromBootOptimize() will not work -> lots of unnecessary file movement. Maybe you can make another script for this special case?

Jeroen said on my other post at the "New features" forum that the function ImportListFromFile() can be used to read a LAYOUT.INI file, so I was thinking about using that function with the !MountPoint! macro:

ImportListFromFile("!MountPoint!\WINDOWS\PREFETCH\LAYOUT.INI")

It'll fail (-> lots of unnecessary file movement) if the current mount point (drive letter) is different than the one on the files of the LAYOUT.INI file, won't it?
Otherwise (drive letter is the same than the one on LAYOUT.INI file), will that work?

Like the original Slow- and FastOptimization scripts, your are incompatible with each other too, because SlowOptimize uses Sort, which is likely to create fragments, and FastOptimize used Defragment.

Version v4.1.2 no longer has this problem. FastOptimize now recognizes the wrap-around fragments created by SlowOptimize. The next MyDefrag version will no longer have a separate FastUpdate script.

Didn't realize about that when writing the script (and I started before version 4.1.2 was released...). Anyway I'm lucky that this problem is now solved and "SlowOptimize" and "FastOptimize" are now "aware of each other".

I was planning to use the Slow version after major changes (installing/uninstalling programs...) and the Fast version weekly (to move added/updated files to the appropiate blocks using the gaps as spare room for new/grown files, but faster that sorting again all the files on a block by name and folder).

The last AddGap statements does nothing, because all files have already been processed until then.

Which ones? I've checked all of them and only found the AddGap on line 101 to be "defective":

- Line 391 AddGap will do nothing if "hiberfil.sys" is unmovable, that's ok (I'm trying to move the "hiberfil.sys" to the end of the drive). But it will work if it can be moved (inactive Windows drive), won't it?
- Line 374 AddGap will do nothing if there are no more files or folders in the drive except those excluded and those already processed in previous FileSelect blocks, that's ok (no need to create this gap if there are no files). But it will work if there are unprocessed files or folders except the ones excluded, won't it?
- Line 101 AddGap may not work, you're right... If there is only one user account, its Registry files will surely have already been selected as used-during-boot files, so that FileSelect block (line 91) may be empty and the AddGap statement not processed. Can I substitute this AddGap sentence for a MakeGap sentence after this FileSelect block, so the MakeGap will always be processed?

Do I have any other wrong AddGap sentences?

I hope you found my comments useful. 

Of course This kind of comments are what I was looking for.

And if you find that any files/folders referenced in the script (or other files/folders that I may have forgotten) may be placed on other drive positions for better performance, please, tell me too.

Thank you very much Darlis and Jeroen

[jeroen]

It'll fail (-> lots of unnecessary file movement) if the current mount point (drive letter) is different than the one on the files of the LAYOUT.INI file, won't it?
Otherwise (drive letter is the same than the one on LAYOUT.INI file), will that work?

The paths from the imported file are compared with the driveletter of the currently processed volume, and if they do not match then the path is quietly skipped. For example, if the program is processing the "d:" disk, then only the paths from the imported file are used that begin with "d:". So, there is never any unnecessary file movement and you can always import the file.

[Darlis]

ImportListFromFile("!MountPoint!\WINDOWS\PREFETCH\LAYOUT.INI")

It'll fail (-> lots of unnecessary file movement) if the current mount point (drive letter) is different than the one on the files of the LAYOUT.INI file, won't it?
Otherwise (drive letter is the same than the one on LAYOUT.INI file), will that work?

You can also use a fixed position: ImportListFromFile("C:\WINDOWS\PREFETCH\LAYOUT.INI")
Maybe you have to change the drive letter, when boot from a CD.

- Line 391 AddGap will do nothing if "hiberfil.sys" is unmovable, that's ok (I'm trying to move the "hiberfil.sys" to the end of the drive). But it will work if it can be moved (inactive Windows drive), won't it?

I'm not sure about this. The manual says that "The gap will not be created if the zone is empty (no files are selected by the FileBoolean)". But the hiberfil.sys is selected, even if it is unmoveable. But you don't have to have a gap after this file anyway, because it does not grow, unless you get more RAM.

Can I substitute this AddGap sentence for a MakeGap sentence after this FileSelect block, so the MakeGap will always be processed?

Yes.

[MiguelMS]

The paths from the imported file are compared with the driveletter of the currently processed volume, and if they do not match then the path is quietly skipped. For example, if the program is processing the "d:" disk, then only the paths from the imported file are used that begin with "d:". So, there is never any unnecessary file movement and you can always import the file

Maybe I'm wrong, but... when my script tries to place the boot files, if the drive mount point has changed, only a few files will match the drive letter in LAYOUT.INI files (or maybe no files will match the drive letter), so only a few files (or no files) will be placed by this FileSelect block of the script. That few files (less files than when LAYOUT.INI drive letter matches) will cause the gap and all next files to move towards the beggining of the drive, causing the script to do "unnecesary file movement", and if later defragged when drive letters match, the script will move again the files towards the end of the drive to make room for all the boot files.

It's a problem in the script, not a MyDefrag problem, as MyDefrag will get from the list the files that apply to the drive letter being defragged, and that's right.

But it's not a big deal... if drive letters match (as they should), there will be no problem.

You can also use a fixed position: ImportListFromFile("C:\WINDOWS\PREFETCH\LAYOUT.INI")
Maybe you have to change the drive letter, when boot from a CD.

Using a fixed drive letter will cause the script to be fixed for a drive letter, and I'm trying to write it without fixed drive letters (so the same VolumeSelect block can be used for two or more volumes by replacing the Name("C:") statement as the comment in that line says). And if the drive letter has been changed, that will not change the full paths written inside the LAYOUT.INI file that may be pointing to other drive letter.

But it's not a big deal... if drive letters match (as they should), there will be no problem. And someone using a special boot CD or even a special "changing-between-Windows-installations" drive letters scheme, can use the AltLayout utility from Jonib or may still modify the script to meet his/her needs.

I'm not sure about this. The manual says that "The gap will not be created if the zone is empty (no files are selected by the FileBoolean)". But the hiberfil.sys is selected, even if it is unmoveable. But you don't have to have a gap after this file anyway, because it does not grow, unless you get more RAM.

Maybe I'm wrong here too, but... I'm trying to take the "hiberfil.sys" file (if movable) to the very end of the drive, because this file is only used when entering of exiting the hibernation status and no other files are accesed while this file is being written or read (so it may be placed away from other system files without causing any seeks to other disk positions) with only a little time penalty for being at the end of the drive. That time penalty is better than having this file in the middle of anywhere being "a big gap" between other files placed by the script, and even better than having it at the beginning fo the disk (wasting the fastest drive space). Because the file will not grow or shrink, as you say, it'll not move from this place once placed.

At the point the "hiberfil.sys" file is moved (if movable), there are no files left unprocessed because previous FileSelect block says "all and not (FileName("hiberfil.sys"))"... so I think that gap doesn't affect any other files, as no files are left unprocessed at this point.

The AddGap sentence is AddGap(UntilPercentageOfVolume(100)) as seen in the example MoveToEnd script. If I understood it, that sentence is expected to (all other files been alredy placed) open a gap (it's alredy open as all other files have been placed, so from that point there is just free space and the hiberfil.sys somewhere in that free space if it is movable) to the end of the drive minus the space needed to place the hiberfil.sys file selected in this FileSelect block...

So... is it wrong? Am I missing something?

Can I substitute this AddGap sentence for a MakeGap sentence after this FileSelect block, so the MakeGap will always be processed?

Yes.

All right, I'll substitute that sentence

Thank you again Darlis and Jeroen

[MiguelMS]

Hello everyone

As there have been no more replies with corrections or improvements for some days, I'm posting the scripts for anyone who may want to use them. All corrections and improvements I was told in the previous posts are already applied.

I have tested these scripts on my computers with really good results. Boot time and applications start time have noticiable improved on my computers with this file placements and optimizations, available thanks to MyDefrag. And I like to have all files ordered as I always wanted


If anyone using these scripts have further suggestions, corrections, improvements... or whatever changes you consider my script may need, I would like to hear from you.


Before using these scripts keep in mind the following:

- You should review and modify these scripts to customize them for your system (and/or the specific use you make of your system and files) before using them (as they may no be appropiate as-is for every system or every user). Comments are placed where a modification may be appropiate/needed.

- On these scripts, I assume that every file can be moved, although some of them can't be moved in an active Windows installation (i.e. pagefile.sys, hiberfil.sys ...). They may be moved by running these script from other Windows installation or from a boot CD (but it is not necessary at all to move them)

- First run of the "Slow optimization" script may be considered slow by some users (not by me, as I know it may be moving and sorting every file on the drive... it's as fast as it can be with these huge scripts), but my idea is that next runs of "Fast optimization" script would be faster, as they would only be moving updated Windows files, updated Program files or new/changed documents or personal files. Windows files and program files don't usually change, only when updating, or installing or uninstalling programs, and because there are gaps placed on some positions, these gaps allow for changes without having to move files placed after. Fast optimizations can be slow too if there have been lots of changes on the drive since the last time the defrag was run (you may want to adjust gaps sizes to solve this, or even further customize the FileSelect blocks of the scripts for your specific system/use). So, NO pointless complaints or rants about speed when using these scripts, please

- I have included a "Reserve MFT Zone" script too, that should be run ONCE (just ONE TIME), before using the other scripts for the first time, to allow Windows moving the MFT reserved zone near the MFT that is placed on the beginning of the drive. It first moves the MFT to the beginning of the drive, then adds a gap of 256 MB (Windows won't move the reseved zone there if the gap is smaller than 200 MB and there are bigger free space gaps), then reboot Windows so the MFT reserved zone is moved (MFT of the system drive can't be moved by just dismount, so a reboot is needed). Using this script two or more times will make the Reserved MFT zone bigger than intended.


Thank you very much to Jeroen, Darlis and Jonib, who helped me with these scripts

[jonib]

If anyone using these scripts have further suggestions, corrections, improvements... or whatever changes you consider my script may need, I would like to hear from you.

In ReserveMFTZone.MyD there is a syntax error on line 58

Code:

    SelectNtfsSystemFiles(yes) and not FileName("$MFT")

Should be

Code:

    SelectNtfsSystemFiles(yes) and not( FileName("$MFT"))

jonib