Thougths on Disk Optimizers

[H]unter

Weaksauce
Joined
Dec 13, 2007
Messages
121
Hi,

Was looking into DiskTrix Ultimate Defrag.
Like they market the product as more then just a defragger, but also a file placement optimizer.

Anyone have experience with this product? Are the any alternatives.

Thanks
 
I use Ultimate Defrag and I like it better than other products ive used because it allows me to put my data on the inner tracks and i can have my freespace on the outer tracks where its faster and I can get faster writes out of my NAS.

Ive looked at others but they just cost too much, and UDefrag has a free version that does everything that i would want it to. UDefrag is a little slow in my opinion. Hope this helps.
 
thanks for the update nitro, would you recommend a setup of the pagefile on the furthest tracks followed by free space then the data on the inner tracks?

this is on a system drive.
 
On my system drive I just use the Auto mode, and check the box to place directories close to MFT. This mode will put the pagefile.sys on the outermost tracks along with some boot files. And it will auto Organize most used data and place it towards the outer tracks. The first time you do this it will take a LONG time. Its definately an Overnight job
 
I haven´t tried the other apps mentioned here, but I am extremely happy with PerfectDisk 8.0 (there might be a never version out). The performance improvements are easily noticable. In my current setup I´ve set it to auto defrag system files at bootup. This works great and has improved responsiveness and smoothness of operation a fair bit. Comparing it to winXPs own defragger, I´d say it about 800 times better in every respect (thats a lose number and should not be taken too seriously..might actually be 754).
 
For a commercial product, the "best" would probably be Perfect Disk 2008, arguably. It's faster than most of the rest that are available, can actually defrag a drive in one pass unlike most of the competition that claim to do but can't, and generally has many favorable reviews.

For a totally free product, the "best" would probably be JkDefrag. It gets many high marks and excellent reviews from users, albeit it can be a bit slower than some others.
 
For a commercial product, the "best" would probably be Perfect Disk 2008, arguably
What? What do you even mean? It's arguably the best? It's probably the best, arguably? It's the "best" arguably, probably? It's probably arguably the "best"? Why is best in quotes? Why is your post so full of weasel words?
 
I meant I would argue that it's the best, most definitely. :D

Figured you'd be able to understand such a simple thing, guess not...
 
I meant I would argue that it's the best, most definitely. :D
Problem is, that's not what "arguably" means.

Others have pointed out O&O disk defrag, which I use; and PerfectDisk, which some insist is arguably perhaps almost definitely the best, or better.

A friend of mine is using JkDefrag, which ships with source. It has a few interesting features, like this counter-intuitive idea where it fragments files on purpose but claims that they're "aligned" and therefore don't pose a performance issue.

mst software is about to release a new version of their tool. Diskeeper is a wildly popular tool, too.

Have you noticed any performance improvement from this "file placement optimizer" feature, Hunter? I've not found a scientific (or even sensible) review of disk defragmentation tools, and as a result there's lots of unquestioned claims and zealotry in the market.
 
mikeblas ---

Perhaps you should use a dictionary. Joe Average used the word in a correct manner.
 
mikeblas ---

Perhaps you should use a dictionary. Joe Average used the word in a correct manner.

Then why hedge his bets so much? He had two words that soften the certainty of his statement. That's probably what mikeblas meant.

Arguably.
 
The ONLY defragger worth buying is Raxco Perfectdisk. Not O&O, not Ultimate, not anything BUT Perfectdisk.

JKDefrag is also great and is free. GPL, even.
 
Thanks for all the replies guys.
I have not found disk optimizers/defragmenter reviews or comparisons. There are reviews for each product, and some have compared to std. built in MS defrag.
I will be looking into DiskTrix and the arguably best ;) Raxco product.
 
The June 2008 issue of Maximum PC has a comparison of review of disk optimizers. While the magazine isn't exactly the pinnacle of scientific method, they've at least attempted a sensible test. They took an image of a machine that was fragmented, then restored it to initialize each test. They timed PCMark scores and startup and shutdown time before and after defragmenting with different tools.

After defragging with Windows' built-in defragger, the PCMark score improved slightly and startup time was substantially better--but shutdown time was substantially worse.

When they tested Auslogics Disk Defrag, Diskeeper 2008, and PerfectDisk 2008, they found that performance was better after running Windows' built-in defragger than it was after running the third-party tools! The only exception was better shutdown time after running PerfectDisk--otherwise, Windows' built-in defrag was better. And free.
 
When Windows defrag wants to fully defragment my drive, then I might think of it as anything other than a total POS. I do not believe they did the test right.
 
Do you have specific reasons for that opinion? Will you share them with us?

No evidence, just that the results do not jive with what I've heard.

The proper way to use Perfectdisk is to do an offline defrag., reboot and let it run, then do a smartplace defrag. Did they do that?
 
No evidence, just that the results do not jive with what I've heard.
And what is it that you've heard?

The proper way to use Perfectdisk is to do an offline defrag., reboot and let it run, then do a smartplace defrag. Did they do that?

They don't say anything about "smartplace", but they do indicate they did a boot-time defrag. I don't think boot-time defragmentation is worth much. The idea is that it will let the defragger make contiguous system files, like the hibernation file and the page file. It's helpful to have a contiguous hibernation file, if you use it. A contiguous page file isn't too helpful.
 
I've been using JkDefrag under Windows Vista Home Premium (32 bit). It seems to be a pretty good software product at least for the money (free). The method "optimize by sorting all files by name (folder + filename)" makes things (boot, Start Menu, launches) happen noticeably faster.

To use the slow but very efficient optimization, the program must be called like this: "jkdefrag -a 7" (for all drives) and preferably in Safe Mode.

If you (the other people out there) choose to use alternative disk defragmenters, you better remove Windows' own defrag utility from the scheduled tasks.
 
Damn that looks sick. I think i'm going to switch to that just for looks. I've used lots of defraggers and never found them to really do that much. I've always used 15k SCSI so it's always faster than ide.
 
yups Perfect Disc is bomb biggity, hands down. so far have been very satisfied with it. It works fast and its simple too. yeah it bee about 755 times better than windows defrag (jk)

a little off topic, but does anyone know if its necessary to even defrag SSD's?

I haven´t tried the other apps mentioned here, but I am extremely happy with PerfectDisk 8.0 (there might be a never version out). The performance improvements are easily noticable. In my current setup I´ve set it to auto defrag system files at bootup. This works great and has improved responsiveness and smoothness of operation a fair bit. Comparing it to winXPs own defragger, I´d say it about 800 times better in every respect (thats a lose number and should not be taken too seriously..might actually be 754).
 
and worse than JKDefrag which is free.

Eh ..., free doesn't mean better, in fact, quite often it's the opposite.
JK has certainly done the Windows world a great service by creating his defrag solution. Having said that, JKDefrag has limitations which may influence those who have no problem with spending a few bucks on a commercial defrag solution to go out and get one.

No boot time defrag with JKD, no shadow copy support. Sure, you can find other free tools to do that, or you can pay a fraction of your disposable income and purchase convenience.

In addition, statements by JK saying that background defragging slows down your machines and shortens the lifespan of your HDD just made him lose some credibility. If you have a good product there's no need to come up with a slogan that says: Defrag less! Or else your HDD will break! BS is all that is.

Still, the easiest way is to decide for oneself, fully functional trial versions of all commercial defraggers are available.
 
a little off topic, but does anyone know if its necessary to even defrag SSD's?

Not necessary. It's a random access medium (well, for purposes of defragging, anyways) so it just takes files that are already accessible at high speed and shuffles them around.
 
Really? Is one two-sector transfer really not at all slower than two one-sector transfers? Or is it that it's only slower by a negligible amount?
 
Really? Is one two-sector transfer really not at all slower than two one-sector transfers? Or is it that it's only slower by a negligible amount?
My initial instinct was that it's a negligible impact, but I did some reading while writing this response, and now I don't know what to expect from performance tests on this issue.

For reading Flash, one reads pages at a time, with typical page sizes 512 to 2048 bytes. But filesystem blocks are often larger than this, so reads will probably not be completely random. For filesystems larger than 2GB (i.e., most of them) XP/NTFS uses 4k clusters, XP/FAT uses 128k (2 to 4GB), Linux/EXT3 uses 4k (depending on various factors, but 4k is what I most commonly see), Linux/Reiser uses 4k, Solaris/UFS uses 8k, and Solaris/ZFS uses 128k. So to read one filesystem block (which will always be sequential, regardless of where the next one is), the OS reads about eight pages.

The best data I can find (if you've got better or more modern spec sheets, please let me know!) says that reading a single page at random from a particular flash chip takes about 10 microseconds, while reading the next page takes about 50 nanoseconds. That means, to read the eight pages for a filesystem block takes about 10.35 microseconds, so if one's filesystem were completely fragmented (no reads are sequential) one would expect to see 790 MB/s or so from this chip. This obviously not being the case, I think the numbers are incorrect (or I'm interpreting them wrong). Maybe I'll see if I can write and run some performance tests on my CF cards tomorrow.

Oh, and another point; even if one makes the file contiguous from the filesystem's perspective, it may not be contiguous on chip. Modern flash controllers (everything from SD to Compact Flash to SSD and up) remap sectors that are frequently used so that they don't wear out particular parts of the disk faster than others. So trying to optimize the order in which the device is accessed could actually make things worse.
 
Funny that defragmenting SSDs was just brought up as I was thinking about making a post (writing an article, actually) about why defragmenting SSDs would probably be a bad idea. The wear-leveling technology that each has nowadays is meant to ensure a long life or as long as possible given the limited writes that each storage cell (or whatever they call 'em in Flash-media terminology) are capable of.

Reads don't matter and can be nearly infinite, but the limitation on the write cycles would obviate the need to not move data around as much as magnetic hard drive storage does or is capable of. Besides, with the extremely fast random access times, even a horribly fragmented SSD would still be far faster than even the fastest physical hard drive will ever be in it's most optimized state.
 
The best data I can find (if you've got better or more modern spec sheets, please let me know!) says that reading a single page at random from a particular flash chip takes about 10 microseconds, while reading the next page takes about 50 nanoseconds. That means, to read the eight pages for a filesystem block takes about 10.35 microseconds, so if one's filesystem were completely fragmented (no reads are sequential) one would expect to see 790 MB/s or so from this chip.
What is it that you're measuring? The time for the CF card to respond to the request at its electrical interface, or the time for the application to see the response through the drivers to the CF card?

Thing is, at the application level, I'd assume that I'd want one transfer of two clusters, even in solid-state media, rather than two transfers of one cluster each. The context switch, ring transition, and so on, all add up. Sure, if you're just reading two sectors, it hardly matters; but if you're reading a bunch of data, the overhead will add up quickly.

For a physical device, the problem is batching. If you read two consecutive sectors, you read them at once. You pay the latency time and head movement time just once, and that's that. If you issue two different read requests, maybe the OS coalesces them. Or, maybe it doesn't; if it doesn't, and there's an interleaved request by someone else to the same device, you pay latency and head movement again for both requests. You block while that's happening, and next thing you know, your application sucks.

I think the same thing can happen, with less cost, for a solid state device. Setting up, issuing, and executing a DMA request to have the device dump data back to memory has a cost, though it's probably a thousandth of the latency charge for a physical drive. It's still there, though.

So trying to optimize the order in which the device is accessed could actually make things worse.
Make things worse for longeivty? Sure, I guess; if that's a real cost in the long run. But even if the data is stored on non-consecutive pages in the device, I'm thinking more about the logical ordering. That's what defragmenting is meant to fix, and spinning hard drives can remap, too.

If the file is fragmented, and you want to read the first three clusters, maybe you read Cluster #1, and Cluster #3, and Cluster #5. They're certainly separate operations, since they're not in order. OTOH, if the file is contiguous, you just read Cluster #9, Cluster #10, and Cluster #11 in order.

If the device has, under the covers, re-mapped the clusters to different physical locations (for wear leveling, for example), then that's fine. You're still doing one single request for three clusters in a row, and letting the implementation of the medium sort it out. There's probably some overhead in that, but it seems you're paying the overhead anyway because all requests, even continuous ones, are going to have to go through that same mapping layer.

Meanwhile, the fundamental problem with defragmenters exists, anyway. They make files continuous based on the presumed access pattern, which is always sequential and continuous. In real life, most files are read in small blocks, inconsistently. It turns out that fragmented and interleaved file storage might be faster because of that.
 
What is it that you're measuring? The time for the CF card to respond to the request at its electrical interface, or the time for the application to see the response through the drivers to the CF card?
That spec sheet is for a single flash chip; its specs are for the electrical level only.
Make things worse for longeivty?
No, I was thinking of latency. If the blocks are non-sequential on the actual media behind the mapping layer, it will hurt performance just as much as if they were non-sequential from the OS perspective---but there's less you can do to correct that.
But even if the data is stored on non-consecutive pages in the device, I'm thinking more about the logical ordering. That's what defragmenting is meant to fix, and spinning hard drives can remap, too.
That's true, but they do it less often, and there remapped sectors are an indicator of a failing disk rather than an everyday happening.
If the device has, under the covers, re-mapped the clusters to different physical locations (for wear leveling, for example), then that's fine. You're still doing one single request for three clusters in a row, and letting the implementation of the medium sort it out. There's probably some overhead in that, but it seems you're paying the overhead anyway because all requests, even continuous ones, are going to have to go through that same mapping layer.
Agreed. Any measurements I make would be affected by that translation layer, but the devices I have are new enough that they probably still have large contiguous blocks. That would allow for reasonable intra- and inter-block measurements. I'd do read-only tests to try to prevent the sectors from being remapped as I tested.
Meanwhile, the fundamental problem with defragmenters exists, anyway. They make files continuous based on the presumed access pattern, which is always sequential and continuous. In real life, most files are read in small blocks, inconsistently. It turns out that fragmented and interleaved file storage might be faster because of that.
True enough.
 
Back
Top