JKDefrag/MyDefrag...

[Thor_Odinson]

Since I plan to get a new HDD soon, I'll be starting out fresh. Is JK Defrag/Mydefrag still the top option for Win XP/7 these days or am I better off just sticking with the built-in tool?

 

[Soundmanred]

Defragging is wholly unnecessary and a waste of time.

 

[Nothinman]

Does the JK stand fore Just Kidding?

 

[Fardringle]

Defragging is wholly unnecessary and a waste of time.

Not entirely true, unless Thor's new hard drive is an SSD. I have seen situations where a hard drive is so badly fragmented that it very noticeably affected system performance. Defragging on a daily, weekly, or even monthly basis is almost never needed, but it can be a useful tool when appropriate. That said, I use Auslogics when I need to defragment a drive. It works quickly, has all of the options that I want, and it's free.

 

[Nothinman]

Not entirely true, unless Thor's new hard drive is an SSD. I have seen situations where a hard drive is so badly fragmented that it very noticeably affected system performance. Defragging on a daily, weekly, or even monthly basis is almost never needed, but it can be a useful tool when appropriate. That said, I use Auslogics when I need to defragment a drive. It works quickly, has all of the options that I want, and it's free.

The affects of defragging are largely dependent on workload and even debatable in those circumstances. However, even if one concedes that the affects are not zero, why would you waste your time with a 3rd party tool when Windows will do good enough on it's own?

 

[imagoon]

The affects of defragging are largely dependent on workload and even debatable in those circumstances. However, even if one concedes that the affects are not zero, why would you waste your time with a 3rd party tool when Windows will do good enough on it's own?

Third party tools (they use the MS defrag API actually) just add more features like the ability to defragment free space or free up the MFT if you let the drive hit 99% etc.

mydefrag I found does a better job "fixing" databases that get horked up. I had a misconfigured domino server that I didn't manage but seemed to be responsible for the performance for (yeah i don't get it either.) Reducing the fragmentation count on the mail databases from some where in the 60k fragments area in to the few hundred made a huge difference even on a SAN attached server. I personally found that somewhere around file size /32MB or /64MB = (# of fragments) equals no noticeable performance issues. IE a 128MB file in 2-4 fragments is irrelevant. Several hundred and you start seeing API lag and arm swinging etc (not SSD.)

 

[billyb0b]

i use jkdefrag on my mechanical 1tb samsung drive. never use it on the main boot/os ssd

 

[Nothinman]

Third party tools (they use the MS defrag API actually) just add more features like the ability to defragment free space or free up the MFT if you let the drive hit 99% etc.

I understand that, but those "features" are less useful than the defragging itself.

mydefrag I found does a better job "fixing" databases that get horked up. I had a misconfigured domino server that I didn't manage but seemed to be responsible for the performance for (yeah i don't get it either.) Reducing the fragmentation count on the mail databases from some where in the 60k fragments area in to the few hundred made a huge difference even on a SAN attached server. I personally found that somewhere around file size /32MB or /64MB = (# of fragments) equals no noticeable performance issues. IE a 128MB file in 2-4 fragments is irrelevant. Several hundred and you start seeing API lag and arm swinging etc (not SSD.)

I'd say that's an extreme corner case, mostly because no one really uses Domino. =) But on the other side, if that's an issue then the database was really misconfigured and using a defrag tool to duct tape over that problem isn't a good thing.

 

[Bill Brasky]

I just use the defragmenter built into Windows.

 

[imagoon]

I understand that, but those "features" are less useful than the defragging itself.



I'd say that's an extreme corner case, mostly because no one really uses Domino. =) But on the other side, if that's an issue then the database was really misconfigured and using a defrag tool to duct tape over that problem isn't a good thing.

You're missing the point. The third party tools do a few things the built in MS one doesn't do. Defrag.exe just calls the built in NTFS defragment APIs. Mydefrag etc call the same APIs but can do more to clean up. Defrag.exe makes one pass, doesn't consolidate free space at all, and basically does nothing when the disk is less that 15% free. We assign disk out to the servers based on need so 10% disk looks like efficiency to us and we would not bother handing out more space until the disk is in the 5% range. At that point the windows defrag.exe barfs and won't do anything yet tools like my defrag can clean up the disk clean, up the MFT area and reextends it (defrag.exe never does this), it can also zone data but this feature is useless on SAN based storage.

It is important to consolidate free space on filled drives reduce the fragment count of other files. Defrag.exe won't even bother to process a file that it can't find a contiguous block of free space for.

MFT extending is also important. It is like running out of inodes. Do you like getting "out of disk space" when your storage is reporting 50% physical space free? NTFS will shrink the MFT if the disk is really full to allow for more storage. Once it does this it doesn't auto extend back with you freeing up the MFT area.

Those features seem to make if far better than the built in one in my opinion.

 

[Nothinman]

You're missing the point. The third party tools do a few things the built in MS one doesn't do. Defrag.exe just calls the built in NTFS defragment APIs. Mydefrag etc call the same APIs but can do more to clean up. Defrag.exe makes one pass, doesn't consolidate free space at all, and basically does nothing when the disk is less that 15% free. We assign disk out to the servers based on need so 10% disk looks like efficiency to us and we would not bother handing out more space until the disk is in the 5% range. At that point the windows defrag.exe barfs and won't do anything yet tools like my defrag can clean up the disk clean, up the MFT area and reextends it (defrag.exe never does this), it can also zone data but this feature is useless on SAN based storage.

It is important to consolidate free space on filled drives reduce the fragment count of other files. Defrag.exe won't even bother to process a file that it can't find a contiguous block of free space for.

MFT extending is also important. It is like running out of inodes. Do you like getting "out of disk space" when your storage is reporting 50% physical space free? NTFS will shrink the MFT if the disk is really full to allow for more storage. Once it does this it doesn't auto extend back with you freeing up the MFT area.

Those features seem to make if far better than the built in one in my opinion.

I'm not missing the point at all, my point is that those few things are virtually worthless. Consolidating free space isn't even a great idea because it makes expanding files cause more fragmentation since there's no free space near the existing file's end. I'm not even sure what "can clean up the disk clean, up the MFT area" means because the MFT doesn't need cleaning and it'll be extended by the NTFS driver whenever necessary. And I can't say that I've ever heard of someone running out of MFT space, although I'm sure it's technically possible.

And if you're talking about SAN LUNs, defragging is even more worthless because the logical blocks presented to the OS aren't necessarily contiguous on the physical disks in the SAN so defragging them logically does nothing but cause I/O to happen.

 

[imagoon]

I'm not missing the point at all, my point is that those few things are virtually worthless. Consolidating free space isn't even a great idea because it makes expanding files cause more fragmentation since there's no free space near the existing file's end. I'm not even sure what "can clean up the disk clean, up the MFT area" means because the MFT doesn't need cleaning and it'll be extended by the NTFS driver whenever necessary. And I can't say that I've ever heard of someone running out of MFT space, although I'm sure it's technically possible.

And if you're talking about SAN LUNs, defragging is even more worthless because the logical blocks presented to the OS aren't necessarily contiguous on the physical disks in the SAN so defragging them logically does nothing but cause I/O to happen.

Once the disk hits a certain % of disk space the MFT (area) is shrunk to clear space for files. It can't extend again if their is files in the way because it must be contiguous. Clearing the files out of the way (something mydefrag and jk defrag do) allows Windows to resume extending the MFT.

 

[Nothinman]

Once the disk hits a certain % of disk space the MFT (area) is shrunk to clear space for files. It can't extend again if their is files in the way because it must be contiguous. Clearing the files out of the way (something mydefrag and jk defrag do) allows Windows to resume extending the MFT.

It's not that I don't believe that's technically true, but I have never, ever seen a Windows machine run out of MFT space and I see a lot of poorly designed and maintained Windows servers every day. I couldn't imagine spending any amount of time to try and avoid a failure case with such a low probability of occurring, hell you probably have a greater chance of winning the lottery than seeing this happen to one of your servers.

 

[imagoon]

It's not that I don't believe that's technically true, but I have never, ever seen a Windows machine run out of MFT space and I see a lot of poorly designed and maintained Windows servers every day. I couldn't imagine spending any amount of time to try and avoid a failure case with such a low probability of occurring, hell you probably have a greater chance of winning the lottery than seeing this happen to one of your servers.

The information I dug out indicates that in one of the xp / 2003 service pack levels they updated it so the MFT can be fragmented rather than requiring it to be contiguous. So I am in error to say you will run out on those versions. However you end up with your file table also fragmented across the disk. If you have the defragmentor move the files out of the way, NTFS will defragment the MFT in to a contiguous file. Old NT4 / 2000 stuff sticking in my head when it doesn't apply. Apparently 2008+ / Vista / Win7 defrag added these features also.

Also reading back. Consolidate free space is good if the disk is so bad you can't defragment (and just doing an imagex off and back it isn't practical). In 2003 I used to refer to it as fragmentation lock. IE defrag.exe wouldn't defrag any thing because their wasn't enough contiguous space to hold files that wouldn't end up with more fragmented space. I wouldn't run something like that all the time for the reasons you mentioned. Sometimes you just need to get a spot big enough to hold the files to get it to run. The systems I have seen this issue on have had 200k fragments on the "worst files list" that defrag builds.

 

[Nothinman]

The information I dug out indicates that in one of the xp / 2003 service pack levels they updated it so the MFT can be fragmented rather than requiring it to be contiguous. So I am in error to say you will run out on those versions. However you end up with your file table also fragmented across the disk. If you have the defragmentor move the files out of the way, NTFS will defragment the MFT in to a contiguous file. Old NT4 / 2000 stuff sticking in my head when it doesn't apply. Apparently 2008+ / Vista / Win7 defrag added these features also.

Also reading back. Consolidate free space is good if the disk is so bad you can't defragment (and just doing an imagex off and back it isn't practical). In 2003 I used to refer to it as fragmentation lock. IE defrag.exe wouldn't defrag any thing because their wasn't enough contiguous space to hold files that wouldn't end up with more fragmented space. I wouldn't run something like that all the time for the reasons you mentioned. Sometimes you just need to get a spot big enough to hold the files to get it to run. The systems I have seen this issue on have had 200k fragments on the "worst files list" that defrag builds.

But once again, so what? Saying a file has X number of fragments means nothing without context. For example, if the fragments are all in line but with small spaces between them then the time to read the entire file should be about the same as if they were contiguous because it's not like the drive is stupid enough to do a full seek for every fragment. And in general, once you factor in read-ahead, other I/O going on, disk caching, etc the affects of fragmentation are a lost smaller than someone like Diskeeper Corp wants you to believe because they want to sell you software that you don't need.

My filesystem could be 100% contiguous and I could still have a seek storm if I'm running something that has to read 20,000+ files like a Linux kernel compilation.