Thanks Blume for the link, this is interesting to know.
Yesterday a friend of mine showed me his PC. It was nearly 3 years old, running Windows XP SP2 on a disk of 40 GB , only one partition. He was complaining that the PC was slower than 2 years ago. As I had my USB key with CCleaner (portable vesion) and JKDefrag 3.34 on it I proposed to have a look. I found at the first Jkdefrag analysis that his disk may be a perfect example for another experience to prove how windows xp continues writing at the end of the disk even after a good JKDefrag defragmentation. Even worse the Windows Boot File Optimisation process moved back all the "optimised" files at the end of the disk!
I took notes and screenshots of all the steps in order to share them with you. Here they are...
1st analysis
-> CCleaner to clean the disk + deletion of all files in C:\windows\temp\
2nd Analysis: this is not obvious to see but there were few hundred files deleted.
-> JkDefrag.exe -a 3 -l "JkDefrag_a3.log" C:\*
-> Leave the PC up and running for the next 7 hours .. without doing anything
3rd Analysis: note the yellow stars in the dark part ! HDview shows they are all newly small files created in C:\Windows\Temp\, MSIxxxxxx.LOG from 16KB to few hundred KB size.
-> Create a flat file of 500 MB : fsutil file createnew c:\windows\temp\tempMB500.txt 524288000
4th Analysis: we can obviously see where the 500MB file has been created
-> Create a flat file of 100 MB : fsutil file createnew c:\windows\temp\tempMB100.txt 104857600
5th Analysis: we can obviously see where the 100MB file has been created
-> Create a flat file of 30 MB : fsutil file createnew c:\windows\temp\tempMB30.txt 31457280
6th Analysis: we can obviously see where the 30MB file has been created
-> Create a flat file of 10 MB : fsutil file createnew c:\windows\temp\tempMB10.txt 10485760
7th Analysis: we can obviously see where the 10MB file has been created
Though it is obvious the location of the newly created files is confirmed with HDview.
-> Run : Rundll32.exe advapi32.dll,ProcessIdleTasks
-> This has the effect to force the Windows Boot files optimisation (assuming the correct parameters are set in the registry for it and that the right services have been started, the C:\windows\prefetch\layout.ini was also updated during that process)
7th Analysis: we can obviously see where Windows moved the optimisation files !
did I say “optimisation” ? …
Conclusion:
On this PC, which was heavely fragmented and which had not been cleaned up for a long time, a JKdefrag –a3 occurred and that moved all the files down properly. Classic case for many PCs which had never been cleaned up and defragmented.
Then it appeared that the newly created files, which were small log files or specific bigger files, were created anywhere on the disk but only in the previous area that older files previously occupied, never above it. And for sure they were not created in the fastest available location on the disk as we saw.
The Boot File Optimization moved the files at the top of the old area… probably at their same old location prior to the Jkdefrag –a3 , obviously not at the fastest location again (as it is near the end of the disk!
)
The $MFT was still one fragment on this disk.
19:46:22 Fragments Bytes Clusters Name
19:46:22 1 94306304 184192 C:\$MFT
I note that after a brand new installation of Windows XP, following a reformat of the hard drive, this behaviour never happens , at least not immediately …
In such case the $MFT was not fragmented so there was no reason to defragment it I have to say… but surely that MFT needs to be cleaned up … Is that what one calls defragmenting the free space?...I don’t know but the cleanest behaviour would be to see the new files created at the first fastest available area on the disk.
To prevent at least the good files to be moved away at the end of the disk again , after re-running JKDefrag -a3 again I disabled the BootOptimisation in the registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Dfrg\BootOptimizeFunction
-> Enable = N
