It's suggested for non-trim OSs like XP, that free space on an SSD be "written" as 1's periodically. Otherwise new partial flash block being written cause useless reads to keep data the OS has thrown away.

MyDefrag writes only two files on the disk - log and debug log. All the rest is done by system through MS defragmenting API and there is no way in that API to set how it should treat file slacks or emptied space after moved files. So the whole point about 1s is completely irrelevant for MyDefrag.

Anyone using SSD under Windows XP or even older system deserves to be punished anyway.

I think this whole discussion is pointless, as far I'm understanding SSDs.

You're probably wrong about the level of mapping on SSDs, otherwise there wouldn't be this known issue:

http://en.wikipedia.org/wiki/1_MB_partition_alignment#1_MB_alignment

However the question is what level of mapping SSDs actually use. I believe the mapping is on page level, not on block level - and since cluster size is usually equal to multiple of page size (4 kB), most disks should not have any need for aligning individual files.

Which makes you right.

The only exception would be if somebody decided to format their disk using clusters smaller than the page size. But I don't think such approach deserves to be supported.

Secondly, the alignment would leave lot's of gaps on the disk. Windows will automatically use these gaps, thereby nullifying (perhaps even negating) the benefits.

There's a lot of room to deliver best effort.

First, this alignment is most critical for small files, typically a few clusters long as that determines whether they can be read from one or two blocks. For large files, alignment is mostly unimportant as it won't mean big difference in file access.

Second, the alignment does not mean that the file must start on the grid. It means that the file should span over as few grid boxes as possible but neither end of the file needs to be aligned to the boundary. That's of course assuming the grid size matches the internal SSD page size but even if it doesn't (and is a multiple of it) it would still mean improvement.

Example: alignment grid is eight clusters, you have files 1, 2, 4, and 9 clusters long. Then one possible way how to make them aligned is this:

| 4-4-4-4 9-9-9-9-|-9-9-9-9-9 1 2-2 |

(the 9-cluster file will always span 2 blocks; if it was 10 blocks long you only need to care for it to not span 3 blocks)

Third, it's not needed for SortBy() commands. There's little use for SortBy() commands on SSD in any large scale. And both Defragment() and FastFill() have enough freedom to make 'best effort', either by making choices in selecting which gap to use to defragment a file, or to make an attempt to reorder files selected to fill the gap to match the grid.

The log snippets you posted don't suggest MyDefrag is cycling or doing anything wrong.

The question is, does the message "Starting to fill the gap at LCN=15019818" repeat in the log with the same LCN value, or does the LCN value steadily increase?

My hypothesis is, there are three large zone 3 files stuck at the end of the disk and there are thousands of gaps in between files before them and MyDefrag just spends time checking all these tiny gaps one by one if they cannot be filled by these large files. If that's the case, you can just wait till it finishes.

If MyDefrag returns to the same LCN, then there might be a problem.

The topic title is a rhetorical question; the answer is:

When you are using Defragment() and MoveUpToZone() commands in your zone, use Defragment() first.

Why?

There are two reasons.

First, by using MoveUpToZone second, you are leaving a little bit more space above the zone start for defragment operation because files left below the zone start are not getting in the way.

Second, both Defragment and MoveUpToZone commands try to fill gaps in the zone before placing files behind the zone. But Defragment also makes new gaps in the zone, gaps left after moved file fragments. So by using MoveUpToZone second you have chance to fill gaps within the zone better.


Of course, except for extreme cases the difference between both approaches is very small. You won't break anything by using them in opposite order.

It "works", although I'm not fully certain if it misses something important.

You are missing something. PlaceNtfsSystemFiles places more than just $mft, it actually places three or four files on my computer and the MFT reserved space is left between the MFT and these files.
I don't know the role of these files so I am not sure what effect on the file system will it have if they are placed far from MFT. I also don't know if they're always the same or if they vary over different system versions.

Now regarding the MFT itself, if you place it from the very start of the disk, then the sequence defragment() + fastfill() has worse performance than the sorting action.

If the mft didn't become fragmented and either grew in size to the free space or didn't grow, then neither of the commands will do anything - it will stay put.

If the mft became fragmented, then both actions will do the same, i.e. defragment mft to a free and probably distant spot, then move it in one piece back down. But FastFill cannot wrap it around eventual small unmovable files in its place while sorting can do that and therefore place it safely exactly where you want it to be.
Note that wrap-around fragmentation is totally harmless for mft as it is basically a database file and is accessed using random reads rather than sequentially.

Default scripts contain some usage-related logic - if a file is long unused, it goes to spacehogs zone. It also follows windows prefetch recommendations. All in all, if you have a program which you use only rarely, it will move towards the end of the disk after about a month, then it will jump back to the beginning after as little as single use.

See this post for a rough estimation.

As far as I understand that "rough estimate", there's no need for more releases.

Such a feature has been proposed several times before. The problem is that the Windows Defragmentation API, on which MyDefrag is based on, is not available during boot time.

The API is available at that time, otherwise every other defragmenter wouldn't offer boot-time defragmentation. I believe only Jeroen knows the true reason why it's not available with MyDefrag but my guess is it would be a lot of work and it would not make much difference. If you desperately need boot-time defragmentation, you can use other defragmenters which offer it. But my experience is that it's not really a big problem to leave a few unmovable files where they are.

Do you mean the Data Disk Weekly script?

No, I meant monthly script with its sorting.

I guess the best approach would be if you try both and decide yourself what you consider better. My view on the matter is:

Monthly script moves each file on the disk 1.5 times on average (half of the files are moved straight to their destination position, half of files get moved somewhere aside first to make room for other files).

Weekly script uses FastFill(WithShuffling) which is extremely ineffective on zones consisting of large files unless they're all the same size. Chance for it to find exact fit for a gap are close to zero so it will likely first stuff all the files to the end of the disk and then it will start dropping them back down in some random order. It may end up moving each file on the disk twice or even more.

Monthly script can wrap files around unmovable files on your disk, while FastFill will never do that and may leave some small gaps on the disk. They're not critical but sorting can simply stuff files better together.

In any case you should not need to perform such operation often - it's a question if you'll need to ever use it unless your disk becomes very full - and in that case yet again sorting (monthly script) is better than filling (weekly script).

My recommended strategy for disks with DVD and blu-ray images:

- regularly use defragment only, don't care about leaving gaps
- if there are fragmented files left after defragmenting, use monthly script once to consolidate files and free space

reasoning:
- disk images don't really need to be lightning fast, so they don't need to be stuffed to the beginning of the disk
- there will be gaps between files, but they will be usually rather large so if any new file gets stuffed into them it will still be reasonably unfragmented and usable

Until there is a new release it might help if there was a separate download or forums section with latest translations and guidelines how to install them into the current version.

On Windows 7 machines it is possible to start MyDefrag using a scheduler task with administrator privileges. MyDefrag's self-installed tasks do not have that privilege but it is possible to edit the record and check the privileges box. You can also give users an icon which will start that task if you wish to give them the ability to start it manually rather than at predefined times.

Or add more RAM and switch to 64 bit Windows.

Or buy more RAM, buy 64-bit Windows, and watch it run out of memory in a few times longer time. Of course, never underestimate an expert.

My wild guess on source of the problem (without knowing or having confirmed any details, so likely wrong or at least oversimplified):

Step 1: MyDefrag sends the MS API command to move a file fragment.

Step 2: MS API fails to move the fragment because it did not succeed updating directory record due to its too long pathname.

Step 3: MyDefrag detects it as if the destination clusters are occupied by previously unknown file so it finds next suitable spot and tries again from Step 1 - ad infinitum. Probably some memory structures are created along with it, permanent or temporary, which gradually fill up the memory.

If it's the reason then of course it may depend on what file system and OS is used, MS defragmentation API is known to have different properties on different systems. Or the reason may be completely different, we would never know without investigating it properly and the only person who can do it is Jeroen who stated his position clearly:

The problem is caused by not enough memory in your computer, not by a bug in MyDefrag. And MyDefrag has no problem with paths longer than MAX_PATH.

I think it's pointless to dispute whether it's a bug or not on a program with last release over two years ago (and known bugs promised to "be fixed in next release" almost all that time). The question is whether Jeroen intends to investigate why is MyDefrag so memory-inefficient in such situation or if all you can do about it is to find a workaround (such as exclude the folder or remove it from the disk) or change defragger to some which does not have such problem.