Diskeeper’s Controversial SSD Defrager

By David Murphy
published

Diskeeper Corporation has announced a new software optimizer for squeaking the most speeds out of your solid-state device.  The technology’s called HyperFast, and we’ll let Diskeeper speak for itself as to what it actually does: “HyperFast creates and maintains optimized free space, increasing the controller’s ability to write sequentially and thereby enormously increasing the peak speed and life of the SSD.”

What does that mean?  We crawled through Diskeeper’s white papers to find out, but still couldn’t figure out exactly how this new process speeds up a solid-state drive.  The company claims that it’s trying to reduce an SSD’s free space fragmentation levels—but the “benefits” of solid-state defragmentation are nebulous at best.  An SSD’s firmware uses wear-leveling functionality to assign different locations for the data you push to the drive.  Defragmenting the SSD would only jumble the data around more, for a “sequential” file as seen by a software defragmenter doesn’t correspond to a sequential series of pages on an SSD block.

According to Diskeeper, its HyperFast technology makes sure that files are written to solid-state drives in a sequential order.  This reduces the overall number of write/erase routines that need to run and should lead to higher performance metrics and a greater lifespan. The company boasts reads that are 5.9 times faster and writes that are 19.5 times faster on the benchmarks it’s showing off.  We remain skeptical.  Forum members over at OCZ Technology ran benchmarks on HyperFast-enabled drives, and they claimed to see no performance improvement whatsoever.  In fact, their numbers suggest that a HyperFast-enabled SSD will actually perform slower than one without the attached service.

How does HyperFast integrate with an SSD’s built-in wear-leveling?  Does HyperFast defragment the drive by ordering pages and their corresponding files sequentially, or is it just mashing up a giant chunk of “write” data against a giant chunk of “free” space?  Is the program caching write operations until it can process a large number as a sequential batch?  These answers are completely unclear at this point. What is clear, however, is that there’s some Internet-fueled discrepancy over Diskeeper’s new SSD optimizer.  And if the program is truly performing some kind of defragmentation process on the SSD, it’s doubtful that you’ll see any benefit.  Until more information about the technology emerges, you’re better off taking a look at Microsoft’s SteadyState utility or Easy Computing Company’s Managed Flash Technology if you want to squeak the most performance out of your solid-state drives.

David Murphy
18 Comments Comment from the forums
  • thartist
    Rocket them alla GTA.
    Reply
  • Diskeeper is like a manufacturer of sleeves for floppy drives: Obsolete. Meanwhile on Denial Street, Seagate is still claiming that SSDs will probably never catch on.
    Reply
  • Actually, the link to the OCZ forum shows that Hyperfast did result in some performance improvements but not even nearly as much as Diskeeper is claiming.
    Reply
  • cjl
    Actually, Seagate plans to release their own line of SSDs. Hardly denial street.
    Reply
  • pbrigido
    Whoever would buy into the idea of a SSD needing to be defragged, needs to study the technology a bit more. But in the computer industry, if there is a buck to be made, someone will try.
    Reply
  • sidewinderdt
    To add fuel to the fire, straight from an Intel SSD engineer:
    "Q. Do SSDs need to be defragmented?
    A. Unfortunately this answer isn't exactly straightforward. Solid state drives generally do not organize data the way that HDDs do, or the way the operating system is expecting them to. This is done to overcome the limitations of flash memory (eg. wear leveling). For that reason, standard defrag tools will not make correct decisions about how to optimize the file system layout on an SSD. I would cautiously suggest that anyone using any SSD should disable automatic defrag on that drive and don't bother running it manually. SSDs are exceedingly fast at seeking, so fetching a seemingly scattered file is going to be nearly as fast as fetching a file that is written sequentially. A traditional HDD will fetch that same scattered file drastically slower, which was the original motivation for defragmentation.


    That said, there certainly are best and worst case layouts for data organization on SSD media. Currently the firmware is responsible for keeping everything as organized as possible. There might be a new opportunity for tools to be developed that will "defragment" an SSD, but they may need inside knowledge of how each SSD works. The magnitude of the fragmentation problem is reduced though, because the performance difference between an optimal layout and worst case isn't nearly as crippling as with a HDD."    http://enthusiast.hardocp.com/article.html?art=MTYxMSwyLCxoZW50aHVzaWFzdA==

    And BTW, defrag is totally different from wear leveling. It has nothing to do with each other since wear leveling is the reorganization of data at the physical block level (cell) of the MLC SSD and defrag is the organization of the data at the logical (NTFS) level of the operating system.
    Check out the comments section here:
    http://www.diskeeperblog.com/archives/2008/12/hyperfast_is_al.html
    Reply
  • rodney_ws
    Hey! Scientology folks have to make money somehow! Praising celebrities only pays the bills for so long.
    Reply
  • SparkyTheWonderDog
    My thesis is on the optimization of wear leveling algorithms on operating system file system usage. I directly monitor the embedded NAND flash component connected to the embedded controller (lazer shaved the NAND device, bond wires, connected to a dedicated fpga based tester), recording every NAND block erasure count directly on various controller commands, extending the test to the life of the product (some up to 100's of TB's of data). In addition, I also have custom hardware to drive the SSD/SD/MMC device directly (emulating the hardware interface), in complete control of all parameters; static and dynamic areas, data pattern, sector size, transfer length and so many others. I have data to show that there are significant advantages to large transfer sizes of data relative to the amount of dynamic area available. In fact, totally random write access with small transfer sizes is extremely slow (worst case) to wear leveling affects such as write amplification and block erasures, life of product, etc.

    I may be able to understand their research, but it will require that the operating systems API will need to be optimized to take real advantage of the controllers wear leveling algorithm, and these algorithm vary by controller and product family. There are no 'standards' yet, as this is an emerging technology used in many different applications.

    My research is to link the operating system file management to the controller and better the access and wear performance. New technologies in NAND are emerging as well (cache, stripping, multiple die and channel, etc). I read an article that Windows 7 has worked on this.

    Defragmenting a SSD, SD, MMC device so larger transfers of data can be written without causing the wear leveling algorithms to internally move data sectors around (and erase blocks) requires insight into the controller's algorithm, which directly would affect write performance. A 'generic' method may be difficult to show any performance between various devices, which is probably why no significant performance was observed using a traditional file system approach with this product.

    Anyway, I believe that will happen is that the controllers and NAND technology coupled with the new embedded commands to link the file system API to the hardware will leap frog the performance in the very near future. This is only my opinion; hopefully, my Thesis results will show this promise.
    Reply
  • pbrigido
    Looks like Ctrl-C still works.
    Reply
  • shqtth
    Flash uses Pages.

    So if data of a file was sequential in that page then fetching data would require less pages, and would provide faster access.

    Also for writing data, writing a full page would be faster then reading a page, inserting data into a section then writing the page back to flash.

    Memory devices allow access to a specific address, but flash/eeprom etc uses pages. And when writing data a whole specific page has to be written. When fetching data depending on the device may allow fetching of a specific piece of data within a page (offset), or may require the whole page being fetched. In the case where a full page has to be fetched to just to gain a peace of data is when the efficiency is lost.

    It is up to the controller to hide this. A controller will use RAM to shadow/cash pages, and will write the page when it is best. In the case of writing some data to a page the controller will fetch the page, insert data then write the page. If the page is accessed a lot (reading and writing) its best to cache the page to reduce time needed to write and/or reduce time needed to close a page if data is already in cache. All in all the ram will help reduce wear and tear, increase throughput, sand ultimately save energy, as constant write uses more power then reads.

    So it’s not that different from hard drivers in the way flash is accessed, but what is different in flash is opening a new page is just a quick and no seek time.


    So imagine this, you have a file that would use 5 pages if it was sequential, but since it is fragmented it uses 8 pages.

    Well, data that is now fetched would be: 8 pages * page size, and the efficiency would be 5/8. So the bandwidth is cut almost in half.

    One reason why flash is so cheap, is that it uses pages/rows to access flash for reading/writing etc. Other types of flash that use single addresses for reading/writing is more expensive as it use more complex circuitry.
    Reply