August 2006 | Main | October 2006
September 27, 2006
Inside I-FAAST (file sequencing)
There's been a great deal of interest and attention from the media, customers, and performance enthusiasts on I-FAAST since its release last December in Diskeeper 10. I regularly read tech forums and blogs looking for feedback and new ideas for our products. I've noticed a lot of discussions on "how" this technology works, so to hopefully help clear things up, I'll describe a few of the parts that make it tick.
The first part of I-FAAST is accurately benchmarking the performance of your file system. That is more complicated than it may sound as issues such as caching will quickly invalidate results if not properly handled. While I may gloss over this, it is quite complicated.
The next hurdle is determining the frequency of file usage. The word frequency is vital here because rote application of file attributes (date and time for file creation, last modification, and last access) can only tell you what happened in the past. That offers little to no prediction for future usage of that data. In other words, it only improves slightly upon a wild guess for data sequencing.
To determine frequency, I-FAAST silently monitors file usage. You may have noticed parts of this design as two hidden files at the root of each of your system's volumes. If you watch closely, you'll note they change on a regular basis as I-FAAST continues to learn. This is another key component of the adaptive and intelligent behavior of I-FAAST.
Monitoring frequency is vital as it is very common for data to go through hot and cold phases and eventually reach a point where it is unused and is essentially archival. It may then, of course, return to a state of frequent usage at some time down the road.
While I-FAAST has advanced designs to determine frequency of use, it can use Last Access Time until actual usage characteristics have been identified. Ideally, we suggest giving I-FAAST a week to learn about usage patterns before sequencing files. However, for those who want to have it crank out right away, I-FAAST will rely on that data until it has collected proper usage data. Again, "Last Access" is only relevant if you set an I-FAAST schedule to occur right after install.
Because we need to learn about usage characteristics (as it is part of the performance gain), you'll note that I-FAAST presents both estimates and actual figures for performance benefits. These benefits change over time as your usage of the file system changes and then rely on what sequencing strategies best fit that systems needs at a given time. As a general rule they won't fluctuate much. If it tells you 20% actual performance today, you'll likely stay in that range give or take a percentage or two. Again, that oscillation is all part of its adaptive nature.
As an example, the propensity to create new files as compared to the use of pre-existing data will cause I-FAAST to adjust sequencing strategies. On a system where most activity involves the reading of existing data, less priority will be given to speeding up new file writes, as I-FAAST concentrates on optimizing the speed of existing data. And, of course, it will adjust rapidly to behavioral changes should new file writes become, comparatively, more common. You can observe this behavior by noting tactically ordered and interwoven groupings of files and large free space segments on an I-FAAST enabled volume change over time.
I-FAAST jobs execute proprietary algorithms which are, as described, reliant on the data usage patterns that it has been monitoring. How often you schedule I-FAAST in Diskeeper 10 should be determined by how dynamic your system is. Once a week is the recommended approach in most all cases, however systems where the popularity of files can change dramatically within the week may want to consider running it daily.
Also key to note is that regular defragmentation with Diskeeper is vital. Defragmented non-sequenced files outperform fragmented sequenced ones essentially every time. I say "essentially" only because we could make theoretical arguments to fragment a file across one cylinder rather than consolidate it across two thereby digressing into really long discussions on drive physics (latency, cylinder and head skew, interleaves, etc) - which is not my purpose here.
Anyway... the point is to defrag regularly. Diskeeper's defragmentation engines are aware of the I-FAAST application and will ensure file sequencing is maintained as it defragments files, including specially sequenced files.
I'm often asked what I-FAAST is like; what it can be compared too. Quite frankly there is nothing like it. The closest equivalent I could possibly suggest is the boot optimization/sequencing technology in Window XP; which Diskeeper Corporation assisted Microsoft in developing. While a good start, its purpose and scope is far, far narrower that that of I-FAAST, meaning the benefit recieved is also far less than what I-FAAST offers. In fact, you can get a good idea of what boot optimization is doing by viewing the layout.ini file on a Windows XP client.
As I always like to mention, I-FAAST is the real deal; it speeds up file reads and new file writes - nothing else out there does that (at least not that I'm aware of). Its purported benefits are provable and noticeable. It isn't theory and conjecture; I-FAAST is based on science of the file system. And unlike what Stanley Tucci's character in The Core said, this science is NOT best guess. I just don't think it's a good idea to move important data around for fun or experimental purposes. Maybe that's just me? ;-)
Lastly, as I alluded in an earlier blog, I-FAAST 2.0 will offer expanded I-FAAST functionality, making implementation easier for the corporate System Administrator, and allowing System Administrators or Gamers/PC Experts new ability to customize or "tweak" it. There will also be an I-FAAST 3.0 as the technology expands, and likely even more versions beyond that.
Posted by Michael at 05:16 AM | Comments (1)
September 26, 2006
Diskeeper 10 beta for Vista RC1 (build 5600) is available
The Diskeeper 10 Professional Edition beta for Vista has now been updated to support Vista Release Candidate 1 build 5600.
We've already begun testing on Vista build 5728 and hope to have a Diskeeper 10 beta next week for that update.
Download it here
Posted by Michael at 01:37 AM | Comments (12)
September 14, 2006
Marketing Slogans That Never Made It
With respect to David Letterman, The Top Ten Diskeeper slogans that never made it:
10. The only software to get a speeding ticket
9. Fragmentation is as fragmentation does
8. th3 NUm83R 0N3 4Ut0m4T1C d3FR49M3Nt3r
7. Death, Taxes, Fragmentation.
6. Fragmentation Happens :-)
5. "Every PC dies, not every PC really lives!"
4. "Set It 'n' Faahgeddabooouud-It"
3. Automizzle fo' shizzle
2. Diskeeper "does it" in the background!
1. Pimp My Drive
Thanks to Paul and Derek for their contributions. Got any more? Let us know.
Posted by Michael at 07:57 PM | Comments (3)
September 11, 2006
Industry Experts on Diskeeper
Paul Thurrott has been covering Vista builds for some time in his reviews and articles, often testing Diskeeper 10 as part of the review.
As he noted in his latest review (http://www.winsupersite.com/reviews/winvista_rc1_03.asp) there are ways to get Diskeeper installed on Vista RC1.
I completely agree with his comment that it's not a good idea to run Diskeeper on RC1; that is, until we officially offer a product.
Those who have tested the current Diskeeper betas for Vista have noted that some features are disabled or reduced in functionality. That is because we haven't fully tested them. I don't anticipate anything breaking, but some of our advanced features (e.g. FragShield) do some relatively fancy things (on Win2k and XP) that may not carry over well to Vista without proper adjustment on our part. For the patient enthusiast, we'll have a new RC1-compatible beta soon, and a "full" product when Vista is officially released.
----
Having written a paper on the subject earlier this year, I was interviewed by Processor magazine on server virtualization a couple of months ago. While a few points I discussed were slightly muddied in translation (e.g. "CPU searching for files" is technically incorrect wording - but at least conveys the message) the interview covered some points system administrators/computer power users need to look out for when building these systems.
Virtualization is a popular buzz word these days, but it is important to use this technology in the right places and under the right circumstances. That concept, everyone interviewed for the article agreed upon. There was, however, some debate on the importance of defragmentation.
Alessandro Perilli, well-known virtualization expert and host of virtualization.info (the leading independent site for everything you ever wanted to know about virtualization) added his comments on the subject as well. http://www.virtualization.info/2006/08/is-defragmentation-real-benefit-for.html
You can also check out Michael Otey's (Windows IT Pro) earlier "top 10" in February 2006, which counted defragmentation among the key priorities for VM performance. http://www.windowsitpro.com/Article/ArticleID/48726/48726.html?Ad=1
The simple fact behind these expert's viewpoint is that the disk is the weak link in a modern, general purpose, computer, slowing everything else down (where disk access is required). Alleviate the bottleneck and the whole system works faster.
Posted by Michael at 09:31 PM | Comments (0)
September 06, 2006
Defrag Tech Spotlight - What is Defrag?
What is defrag? Why should I defrag daily? Find out the answers to these questions and more at the new Defrag Tech Spotlight - What is Defrag area.
Posted by alex at 09:30 AM | Comments (0)