[Script] Robust System Disk script (good access performance with less shuffling)

[Bill]

The script tries to reduce overall AverageBeginEndDistance of files in order to minimize disk-head thrashing when seeking for related files. If most related files are contiguous on disk then overall access is faster.

[poutnik]

Unfortunately, AverageBeginEndDistance parameter has no relation to optimization of related files, it gives to all file to file moves equal probability and weight.
Its correlation to disk optimization is weak. But, reserving area for very small files improves it anyway.

Also, contiguous area of related files to speed up access sounds good and works for boot and app launch, but it requires that
- We know the access order ( layout.ini and pf files cover just part of file accesses, file order in layout.ini often varies )
- It is not interrupted by access to metafile data
- Only one process is accessing the disk

[Bill]

The idea is to keep related files close together so the disk-head does not have to travel a long back-and-forth distance when accessing a group of related files at a given time.

If the begin-end distance between small files is small (i.e. no big files in-between) then the disk-head can remain localized (over a small area of the disk) when accessing most of the related files at a given time, thereby resulting in less total disk-head travel distance when accessing related files (due to small back-and-forth distance between each small file).

The script is not intended to perfect the placement of every single file, but it does try to place related files close together to reduce overall disk-head seek time when accessing a group of related files.

[poutnik]

The idea is obvious.

It is what I have said by other words. Note that Begin End distance parameter is rather a measure
of occupied space compactness and filesize space distribution than of optimized placement.

Such script is not even possible, your one does its work well, especially not sorting spacehog variant.
I just wanted to point out the gain of sequencing is not always as big as supposed, especially for occacional boot scenarios,
and we do not always know proper sequencing.

[braiam]

Hi,
are MyD files removed from the post?

Copy the code in the first post into a text editor such as Notepad, then save the file as SystemDiskRobust.MyD

Can you post the scripts that comes in the bundle? Particularly the first run, as somebody doesn't know how to change the variables, included me.

[Bill]

I have attached two scripts to this post, "SystemDiskRobust - 1st run.MyD" and "SystemDiskRobust.MyD".

Run "SystemDiskRobust - 1st run.MyD" the first time you defragment your system volume, then run "SystemDiskRobust.MyD" on subsequent defragmentation runs (weekly or monthly).
There is no need to change variables in these two scripts.

"SystemDiskRobust - 1st run.MyD" should be run occasionally (every 3 months) to fully compact all files belonging to each zone..

[htb2050]

hey man nice script! gives better performance then all of other defragmenter programs out there. Most are very complex such as ultimate defrag new bies like us don't know the optimal settings. but what you have provided here is awesome. no need to do settings ourselves just run it and forget it. very good work indeed. Thanks  man!

[Bill]

I have added another system disk script to the first post of this thread, called System Disk Robust Simplified.
It is a simplified version of the System Disk Robust script. It simply partitions the data by file size and sorts the files by newest date.
It should give similar performance to the System Disk Robust script, with less file shuffling during defragmentation.


I have attached two scripts to this post, SystemDiskRobustSimplifiedMonthly.MyD and SystemDiskRobustSimplifiedWeekly.MyD.

Run SystemDiskRobustSimplifiedMonthly.MyD the first time you defragment your system volume, then run SystemDiskRobustSimplifiedWeekly.MyD on subsequent defragmentation runs (weekly).
There is no need to change variables in these two scripts.

SystemDiskRobustSimplifiedMonthly.MyD should be run occasionally (every month) to fully compact all files belonging to each zone.


UPDATE:
Get updated scripts in first post: http://www.mydefrag.com/forum/index.php?topic=4054.msg24638#msg24638

[Esteban4u]

The idea is to keep related files close together so the disk-head does not have to travel a long back-and-forth distance when accessing a group of related files at a given time.

If the begin-end distance between small files is small (i.e. no big files in-between) then the disk-head can remain localized (over a small area of the disk) when accessing most of the related files at a given time, thereby resulting in less total disk-head travel distance when accessing related files (due to small back-and-forth distance between each small file).

The script is not intended to perfect the placement of every single file, but it does try to place related files close together to reduce overall disk-head seek time when accessing a group of related files.

Hey Bill,

Thanks for answering my questions earlier about your script and data-only volumes. I have a few more questions if you don't mind. Do you think that special placement for the Windows swap file (Pagefile.sys) would be beneficial for overall responsiveness of a system? Although SSD's have virtually no access times at any location within the flash memory and a finite number of write cycles, can they benefit from your script? Some people on these threads as well as on others claim that SSD's do benefit from some kind of optimization. With the outstanding job your script has done on traditional spindle-based drives, what are your thoughts on this?

[poutnik]

And there is another factor - wear leveling on SSD firmware level, causing data relocation.
Result is the position where the cluster is has just indirect relation to the position where you think the cluster is.

[Darlis]

Do you think that special placement for the Windows swap file (Pagefile.sys) would be beneficial for overall responsiveness of a system?

Imho close to other frequently used files or a second HDD (if the system disk is not a SSD).

Although SSD's have virtually no access times at any location within the flash memory and a finite number of write cycles, can they benefit from your script? Some people on these threads as well as on others claim that SSD's do benefit from some kind of optimization.

It highly depends on the SSD you're using. Old SSDs can get a performance boost after shuffling files around while modern SSDs with Garbage Collection and Trim do not increase in performance. You could get an increase in performance if you do a file system level defragmetation, but your files have to be heavily fragmented to notice any change.

[Kasuha]

In my opinion:

Putting pagefile on SSD is a very good idea if you actually use it. Sure it wears the SSD out but it works as very efficient expansion of your system memory, several orders of magnitude better than having pagefile on traditional disk. The way Windows use the pagefile suits SSDs very well because writes usually come as a stream of consecutive sectors while reads are completely random - exactly what SSDs excel at.

File fragmentation has two effects:
- file parts being located on distant parts of the disk (which is problem on traditional disks but not on SSDs)
- files having many records in MFT (each file fragment is a separate record)
If a file system is heavily fragmented, the MFT is also very large and a lot of it needs to be read while you are trying to read the file which also reduces performance (although by far not that much as physical distance of file fragments on traditional disk)

Therefore I believe even on SSD it is a good idea to keep the fragmentation reasonable.

Sadly MyDefrag is not quite up to that task, its commands are a bit too thorough for it. I can accept Jeroen's argument about the wear not being as big issue as many people think but the time spent on these unnecessary operations counts too.

[Bill]

Do you think that special placement for the Windows swap file (Pagefile.sys) would be beneficial for overall responsiveness of a system?

I have 4GB of RAM and I had placed Pagefile.sys near the beginning of the disk; but now Pagefile.sys is currently placed two-thirds into the disk and I haven't noticed a change in system responsiveness. Maybe if you have 2GB of RAM or less, or if the swap file is used heavily, then placing Pagefile.sys near the beginning of the disk might benefit overall system responsiveness a bit.

Although SSD's have virtually no access times at any location within the flash memory and a finite number of write cycles, can they benefit from your script? Some people on these threads as well as on others claim that SSD's do benefit from some kind of optimization.

Imho defragmenting fragmented files is enough for SSD's; simply Defragment(Fast). My script shuffles around files, which would give no gain in performance on recent SSD's.

[poutnik]

A fixed size of pagefile.sys will be a good approach.
It will be created continuous and will stay so, at least at file system level.
What wear leveling will do it with it we no influence.

[Esteban4u]

Do you think that special placement for the Windows swap file (Pagefile.sys) would be beneficial for overall responsiveness of a system?

I have 4GB of RAM and I had placed Pagefile.sys near the beginning of the disk; but now Pagefile.sys is currently placed two-thirds into the disk and I haven't noticed a change in system responsiveness. Maybe if you have 2GB of RAM or less, or if the swap file is used heavily, then placing Pagefile.sys near the beginning of the disk might benefit overall system responsiveness a bit.

Thanks for answering my questions Bill and others who also contributed. I have another question and a request if you don't mind of course. Do you think clearning the Windows prefetch folder and recreating the layout.ini file has any benefits to speeding up a system? if so, how often should it be done? Could you include optimal placement of the windows pagefile in your next version of your script?