Version 4 scripting language

[TAC109]

I have found it very useful at times!

Can you give an example? I have designed the scripting language to be very flexible, and I think it will be able to handle all needs without first having to move something to the end of the disk.

I am referring to the problems I had when I was trying to expand the MFT Reserved Zone (see http://www.kessels.com/forum/viewtopic.php?t=598)

But the MFT reserved area is way to big. Default is 12.5% of the disk. My laptop has a small 28Gb disk, the MFT is 125Mb (110000 files), or 0.44% of the disk. That's 12% of the disk wasted!

In my experience (see the above link) the MFT Reserved Zone will shrink where necessary to accommodate files, and will not grow again without assistance from the user. I have found that the moveup facility is very useful to allow the MFT Reserved Zone to grow again.

Ah well, If you decide not to include this option, I'll just have to keep a copy of version 3 handy to do a moveup when necessary!

[jeroen]

I have found that the moveup facility is very useful to allow the MFT Reserved Zone to grow again.

Ah, I understand. The v4 scripting language will make it possible to put the MFT in a zone all by itself, and to make that zone as big as you want it to be. The other zones will be defragged and optimized normally. So in v4 it will be possible to free the MFT reserved zone, and defrag and optimize your disk, all in a single run and without tricks such as first moving data to the end of the disk. So I think you will not need the "move up" option any more?

[TAC109]

The v4 scripting language will make it possible to put the MFT in a zone all by itself, and to make that zone as big as you want it to be.

Wow! That looks like an amazing facility! How will it handle a fragmented MFT on XP?

[jeroen]

Wow! That looks like an amazing facility! How will it handle a fragmented MFT on XP?

As far as I know the Microsoft defragmentation API on Windows XP (and Windows 2000) cannot move/defragment the MFT. So JkDefrag cannot do anything with it, it is simply unmovable data.

[cquinn]

(Silly question?) Am I to assume the existing command-line options will still be in place, but with the additional option
of pointing the jkdefrag executable to a script as an alternate course?  

-----

In the grammar I notice  'ShutDownWhenFinished', but no option for RestartWhenFinished ?

That might be preferable in some situations than a simple shutdown.

 (For instance, before a specific project, to defrag the system, reboot to start with a "clean slate" and be able to start
into the project with a newly optimized file system).  

-----
 
I know there are some programs that claim to be able to defrag the MFT (at boot-time), and doing a quick search on that topic I was reminded to download the latest version of Pagedefrag (v2.32)  which appears to be targeted at other files that may not be defraggable while the system is running (unfortunately it does not appear to address the MFT).   But that got me thinking that in scripting it might be a nice option to be able to call another program on defrag completion, to either initiate boot-time activities on the next system start, or perhaps invoke some other maintenance programs (anti-virus/spyware, media cataloger, etc).  I'm sure that could also be done from a batch file after running jkdefrag, but it is an option to consider (especially if someone else comes along with a standalone boot-time tool that can safely handle defragging the MFT).
(EDIT: Apparently Pagedefrag has not yet been updated to be compatible with Windows Vista)

According to this article  there is a "Microsoft approved boot-time method", but it doesn't point to much information beyond that.
 
-----

 The subject of "best placement of files" brings to mind a conversation I once had with a rep from one of the commercial defrag companies.  He pointed out that the classical wisdom of placing files at a pre-determined zone of an NTFS partition (front, end, or middle) may no longer be valid as it was in the days of simple partition structures.  That is because the logical volume that is being addressed may no longer be a single partition on a single hard drive, but could represent many different configurations (RAID (spanned or mirrored)(hardware or software), NAS, SAN; or that even some changes in the design of newer drives (and drive firmware) might throw off the obvious "sweet spots" in performance for a volume created on that stucture.  

The commercial apps (at least that one) get around the issue by running a background performance analysis during early defrags, so they can build a storage profile for that system to call upon when determining later optimization processes.  For a scripted defrag program, it might be possible to use the data from other tools (such as plugging in the results of some of the benchmark tools mentioned earlier) to create user defined "speed zones" that in theory would represent the fastest parts of a specific volume.

[jeroen]

Am I to assume the existing command-line options will still be in place, but with the additional option of pointing the jkdefrag executable to a script as an alternate course?

Yes, that is my intention.

In the grammar I notice 'ShutDownWhenFinished', but no option for RestartWhenFinished ?

Well, adding a reboot option is easy enough. I'll add a RebootWhenFinished option.

call another program on defrag completion

Yeah, I've considered that. I don't like it and I think a batch file would be more flexible. But again, it's easy enough to add, so I will.

might throw off the obvious "sweet spots" in performance for a volume created on that stucture.

It's theoretically possible, but I've never encountered a configuration where the virtual volume is not fastest at the beginning of the volume. I think it's extremely rare. Perhaps in the future I'll build some kind of measurement into JkDefrag, but it's low priority.

[TAC109]

Wow! That looks like an amazing facility! How will it handle a fragmented MFT on XP?

As far as I know the Microsoft defragmentation API on Windows XP (and Windows 2000) cannot move/defragment the MFT. So JkDefrag cannot do anything with it, it is simply unmovable data.

Yes, I wasn't expecting that you could defrag the MFT on XP. My question related to "putting the MFT in a zone by itself". If the MFT is fragmented, then this could be a rather large zone. Alternatively this could refer to only the last fragment of the MFT and the Reserved Zone.

I was trying to understand how it would work. Sorry if that wasn't clear.

[jeroen]

My question related to "putting the MFT in a zone by itself". If the MFT is fragmented, then this could be a rather large zone. Alternatively this could refer to only the last fragment of the MFT and the Reserved Zone.

Well, the program does not exist yet, so I don't know exactly what it will do in that case.

[ABasketOfPups]

I don't like it and I think a batch file would be more flexible. But again, it's easy enough to add, so I will.

I'd vote that you go with your gut, and don't add a function to the scripting language that's easily solved with a batch file.

If I got a vote.

[Myriades]

Hi Jeroen
Maybe a new feature for the V4 scripting language
As we had discussed in some post, the MFT reserved zone is one eight (12.5%) of the hard drive (in most case)
With a parameter option, we could specified the amount of the reserved of allocated space that we want. Eg, 12.5%*x%. It might be usefull to limit allocated space, isn't it?

[jeroen]

It might be usefull to limit allocated space, isn't it?

Yes, it would be useful. I think in Vista there might be an undocumented system call to change the size of the reserved space, because I see it changing size. But using undocumented system calls is usually a bad idea. The only other way I can think of is by directly writing to disk. That is even more dangerous. So I don't think I can do this.

[schitzn]

My concern:

Memory usage, speed (due to additional processing overheads) and binary size.

I love JKDefrag because its compact, fast and optimized.

Please don't loose sight of that! 

Just look at uTorrent, what a masterpiece.

[schitzn]

Jeroen,

Just curious to know how version 4 is coming along, are you still generating a plan for the scripting language, or have you actually commenced coding (or both!) or are you focusing on verison 3 implementing additional features/improvements

I find it exciting to read the changelog of each new release of JKDefrag, so hope the above doesn't come across as a 'pull your finger out'!

[jeroen]

Just curious to know how version 4 is coming along

I started coding on v4 months ago, but discovered that I needed a faster scanner, so I did that first. They are now part of v3 and working fine. There is still a lot of work to be done, and as it happens I am busy with other things, so I have little time. I have more or less stopped developing v3 and for the last 2 months have only done bugfixes there. I don't know if v3.34 will be the last version, perhaps there will be more bugfixes, but there will be no new functionality in v3.