Also, Windows 7 no longer offers the "Tun" option on the "Start" button.  It's in there somewhere, but i haven't found it yet.

Isn't WIN+R working anymore in 7? If I have time on weekend, I'll try the beta myself.

WIN+R works and the Run command is set up just like under Vista.   

http://www.edbott.com/weblog/?p=1360
"1. Right-click the Start button and choose Properties.
 2. On the Start Menu tab, click the Customize button to the right of the Start Menu option.
 3. In the Customize Start Menu dialog box, scroll down and place a check mark next to the Run option"

You are probably seeing the MTF Reserved Zone as part of what Jkdefrag shows.

That is a section of space that is not really being used, but Windows has allocated it to allow expansion of the MFT if needed.   

As other files are stored on the drive, that extra section may disappear as the OS gives it back for usage by general programs,  or it might try to store smaller files in that space.

Diskeeper is probably telling you that the part of the MFT that is actually being used is now laid out in contiguous space, and is ignoring the allocated section that does not have any real data in it.

Please note that only the "-a 7" ... "-a 11" optimizations will create fragments. "-a 3" optimization does not create fragments.

Thank you, I must have confused your usual suggestion of combining the running of "-a7" and "-a3" defrags on a regular basis.

My apologies for tackling this one sentence at a time (and slightly out of order):

He claims that daily defragmention does more wear and tear on a hard drive than say doing it on a monthly basis.

 Lets say you have a drive that has 1000 fragments of files on it at the 1st of the Month, and normal file operations are likely to create approx 33 new fragments each day, ending up with another 1000 fragments by the end of the month.   

If you defrag on the 1st day, then wait to defrag again on the 30rd day you will end up with a total of about 2100 fragments that will have to be dealt with overall.  Where did the extra 100 fragments come from?  They were already there, because there are always some files that cannot be fully defragmented and the count of those fragments are left over to add to the daily count of new fragments from file operations.

If you defrag on the 1st day, and each day thereafter thru the month, you will end up with a total of about 1700 fragments that will have to be dealt with overall.  How is that possible?  Because over the course of the month as you reduce the amount of fragments that build up each day, you also reduce the rate of fragmentation because there are more contiguous spaces available for the OS to create new files or updates to existing files within.   More contiguous files also means less activity is needed to read the file table looking for fragmented files, and to calculate the amount of fragmentation and where to move fragmented files to.   This can even serve to counter the extra build up caused by files that cannot be completely defragged.

(The figures above are made up, but the reasoning is sound imho). 

I tell him I set jkdefrag -a3 to run automatically daily on all the computers I work on. 

 This means you are combining defragmentation with file optimization tasks.  The file optimization pass can create extra fragmentation, but it also tries to place files in better positions for frequent use, which is hoped to reduce wear and tear by
making file operations more efficient overall.

Do you agree that defragmentation/optimization over the lifetime of the HDD causes less head movement than if the HDD was either neither defragmented or only on a monthly basis compared to a daily basis.

Assuming that the usage pattern is the same in both cases, and usage is heavy enough to need regular defragmentation

...either never defragmented:  Definately will result in less head movement on defragmented drive.

...or only on a monthly basis compared to a daily basis:  I would say a Daily defrag will be more efficient that an monthly defrag,  the question that was not asked would be if a weekly defrag could suffice in the place of a daily defrag for most file operations.

Also if you have multiple drives/partitions you may find some drives (system and regularly changing data) require daily defragmentation, while others (storage and archive data) may not require much defragmentation for months at a time.

I hope this helps.

I just tried that in an experiment.  I took a freshly formatted partition, and took analysis snapshots at:

Just after format to get the starting size of the MFT ... 
After filling the drive to over 80% capacity with random files  ...
And after deleting those files and taking another view of just the MFT area.

This was on Windows XP SP2.  And the MFT reserved area did shrink noticably during the process.
I will try to post the before and after snapshots.

run an analysis with option 1  ( jkdefrag -a1 d:\ ) and check the jkdefrag.log file to get an idea of the fragmentation levels of files on that drive.

If you have never defragged it, running a simple defrag with option 2 might be a good idea, just to clean up the file arrangement to make it easier to store other files there.   Files that are frequently accessed could benefit from further optimization.

I'm pretty sure I caused Windows to shrink the MFT area once when moving files back over to a drive I had freshly formatted.   

I do recall it only happened when the amount of space taken up by other files went over a certain threshold.  It may not have been Windows adjusting the MFT more than just flagging the space used in the MFT reserved area as no longer reserved.

I don't remember if that was on XP or Vista, but I have one of each I can test on to see if I can recreate the event. 
 

It sounds like you still have the Windows defrag service running in the background. 

There are two places to check for this. 

The first is a set of instructions I am borrowing (and modifying) from:
http://www.tech-recipes.com/rx/1598/automatic_defrag_disable_and_enable_vista

Vista Automatic Defrag:

1. Click Start
2. Click Control Panel
3. Selct the Control Panel Home
4. Click System and Maintenance
5. Under the Administrative Tools section at the bottom, click Defragment your hard drive
6. You may need to grant permission to open the disk fragmenter

6a.  You will probably see a check mark next to "Run on a schedule" for the Windows defragger, or you may need to click on the "Select Volumes" button to see the option for item #7. 
7. Click or unclick Run automatically (recommended) depending if you want this feature enabled or disabled.  (You may also be able to select or deselect specific volumes for the Windows defragger to work on).
8. Click OK

The second place is the Task Scheduler utility.   If you uncheck "Run on a schedule" above, it should remove the entry from the task scheduler as well, but it doesn't hurt to doublecheck.

I suspect you still have the defragger set to run automatically, which would explain why it kicks in after the system has been idle for a while.

Depending on what switches you are running jkdefrag with, it is possible that some files are left with fragments still on the system as part of the process of organizing them in the layout you prefer.
The Windows defragger may see these files and think it is doing you a favor by re-organizing them.

I have not noticed a conflict with the Vista defragger, but I usually run the command:
"jkdfrag -a2 -uDisableDefaults"  to correct for loose fragments after moving files or running a system optimization pass; so the Windows defragger probably does not see what it would think are fragmented files afterwards.

It's incredible how a 1-man program is far superior than 1-BIG company program 

Not to detract from my earlier comment, but that 1-man probably has a lot less to deal with in code complexity and working with a stable of other programs than some BIG companies do.
It is impressive what Jeroen has managed to do with this program, also considering the boundaries he has set for his own development (programming to the API, and not trying to create alternate methods or use shortcuts that might enhance the capabilities of jkdefrag, but would also put user data more at risk of not being moved in a fashion compatible with the OS).   

There are a couple of features I would like to see in jkdefrag, or at least find some alternate program that can be used to supplement those features.  But until I find those alternates I will continue to look forward to version 4, and continue to appreciate the releases of version 3 that seem to still trickle out. 

Jeroen already makes the source for each release available for others to review, learn from, and comment on.  And there have been times in the forums where another programmer has made a suggestion that has led to a fix or enhancement of the program, along with the bug reports, test reports and general encouragement provided by the forum community. 

There are also contributions made by other programmers to the finished product of jkdefrag that are listed on the download page, as well as links to other helpful programs that can enhance the usability of the program.   There have also been times that someone has modified the source code in an attempt to resolve a specific issue, and the merits of those changes has been discussed as well. 
Many of the hobbyists who use jkdefrag prefer it because we can pick and choose what other programs and functions we can run with it, without having to fight with those features as if they were built into the program itself.

Some OSS projects benefit from a collaborative effort, but as most are done on a hobbyist basis (when and where the programmers can find the time to work together) it can also become a hindrance if it becomes more of an obligation for the principal programmers than a form of recreation
(where other users can reap the benefits of the programmers creative interest in coding).
Many projects have stagnated or died by placing programmers outside the boundaries of what they feel comfortable doing in their free time. 

As much as I want Jeroen to hurry up and release version 4, I also understand the difference between coding because you want to, and coding because you "have to"; and I would not want to put him in a position of feeling like this is more work for him to do, instead of where he might go to get away from "working" as an Internet Engineer.   I also look forward to version 4 because I hope that the awaited scripting language will lead to just the kind of community contributions that you hope for as we all learn how to make the most of the new release.   

Good advice usually allows for equal discussion from both sides; and you may not be aware that the topic has come up before:

http://www.kessels.com/forum/index.php?topic=1006.0
 On how jkdefrag does not try to defrag flash drives by default

http://www.kessels.com/forum/index.php?topic=1156.0
 On the difference between flash drives and other solid state storage devices

I don't think Jeroen is recommending using JkDefrag on those devices, but the question does come up occasionaly, and it would be dishonest to not admit the capabilities of the program, even if most people would choose not to use it in that manner.

See also http://www.kessels.com/forum/index.php?topic=303.0
 for some other comments on defragging USB and considerations to take there.

AFAIK, your .tc file looks to the OS (and hence to jkdefrag) like a 60GB file that is completely filled with valid data to move (since the OS cannot tell the difference between parts of the file that actually contain your files, and the random background "noise" of the remaining space. 

The defrag may be assuming it has to analyze and move the whole .tc file each time it runs.
Better then to add it to an exclusion list.

What you see is "normal", but it might help to explain further what you are most likely seeing.

Windows allocates a certain percentage of space for the MFT to grow into,  which is what you are seeing on the screen.  As the number of files on the drive increases over a certain threshold, Windows can shrink some of the MFT space to make room for other files. 

The problem with bittorrents can be mitgated somewhat by using a client that can pre-allocate the space needed for the whole file.

How much real memory do you have on that system?  Windows uses less swap if it determines it can safely keep less used system files and applications in memory longer.

I try to configure my disks to have a little space at the front for the pagefile and hibernate file if needed, but I find my systems rarely page out once they are optimized