Defragmentation a Boon to Healthcare IT Performance? | [node:field-byline] | Healthcare Blogs Skip to content Skip to navigation

Defragmentation a Boon to Healthcare IT Performance?

December 19, 2010
by Joe Marion
| Reprints
In a virtualized world, small efficiency gains may be important

A decade and a half ago in the early days of speech recognition applications, I became aware of the impact of hard disk fragmentation. Because speech recognition applications tend to generate excessive amounts of image writes, there tends to be a lot of resulting hard disk fragmentation that can eventually impact the application’s performance. Using the built-in disk defragmentation utility in Microsoft’s Windows NT was a laborious task, and hence many users ignored it.

That is when I struck on a 3rd party application from Diskeeper Corporation that offered a much more efficient application for hard disk defragmentation. I offered this application to all of my speech recognition clients as it was a more efficient means of defragmentation over the standard Microsoft tool. Over the years I have been a loyal Diskeeper user (as I am a heavy speech recognition user!), and have followed the technologies evolution. In recent years, Diskeeper has introduced some nifty new features that further enhance disk defragmentation, most notably, IntelliWrite, which prevents up to 85 percent of all disk fragmentation before it occurs.

My experience has been with single PC applications, but Diskeeper also offers enterprise-scale applications. In some recent discussions with Diskeeper, it dawned on me that disk fragmentation is also likely a performance issue within PACS and image and document management systems. When PACS tended to be departmental, it is likely that vendors did not worry much about disk fragmentation, or left it to the facility’s IT department. As PACS technology has expanded to an enterprise perspective, there is likely more IT involvement in the decision making and operation of PACS technology. Consequently, there should be greater emphasis on performance improvement.

With departmental solutions, there very likely was less emphasis on system tools such as defragmentation applications. Now that PACS technology is becoming more intertwined with the rest of IT, there should be greater emphasis on inclusion of these tools. In addition, server virtualization can mean that previously independent applications are now part of a virtual server farm. Tools such as Diskeeper’s V-locity application can bring the same benefits of preventative defragmentation to the world of virtualization. (

In a virtualized world, small efficiency gains may be important. The addition of disk-intensive applications such as speech recognition and imaging could potentially impact the overall performance of these applications. As data storage requirements within healthcare grow, the problem will potentially get worse. Think of the consequence of managing multiple 3000-slice CT studies and performing multiple 3D analyses. As more advanced visualization applications go the client-server route, the performance of a central server doing the 3D processing could be significantly impacted.

I wonder how many healthcare IT organizations are sensitive to this issue. Do they routinely perform disk defragmentation? Do they have an enterprise strategy for handling defragmentation? An what about solution providers? Have they examined the performance consequences of a fragmented disk, and do their system administration/preventative maintenance services address disk fragmentation?




Quote that Einstein could have said:
If a train station is where a train stops, then a computer work station? Is that where work stops?


Great topic!

I learned or at least got caught up on the evolution of computer science around fragmentation (disk storate, namespace, etc) in 2006 though a Google TechTalks presented by Han Reiser.

"Hans Reiser was concerned that hierarchical and relational naming systems add structure not inherent in the information, ..."  ( one hour video available here)

Dedicating disk space to files simply shouldn't follow the shoebox metaphor common to early systems particularly prone to fragmentation. If four thousand small text files each contain, on average 10 characters, should each one tie up a 1k or 4k block of disk space? With the computer and memory speeds of a decade ago, the answer was no.

Of course, Reiser was behind the development of the file system of the same name often found in Linux systems. I'll spare readers the drama of his last few years; interested readers can find that here:

What I learned though from his TechTalk was the increased computer speed and decreased computer memory costs have improved by orders of magnitude, while disk speeds have comparatively not changed nearly as much. As a result, the way Microsoft handed fragmentation in designing FAT several decades ago, for example, or even its basic fixed sector size structuring is antiquated.

More modern operating systems (e.g. Mac OS Extended and Journaled) use techniques like "adaptive hot file clustering" which defragments frequently used files, essentially on the fly. We also have the luxury of spacious hard drives, requiring less gymnastics.  Nice resources here: and on fragmentation and related issues.

The issue of HCIT vendors is complicated or simplified because there needs to be an indexed, relational or hierarchical database construct between the applications and the physical storage. And, other functionality, like rolling-back transactions or embedded DR need to be supported. Lastly, in most cases, once data is written, it's not going be deleted or changed. The metadata will be updated to reflect that it is no longer the current trusted data, but, it must me kept.

A messy new issue are the SSD drives. With the move to persistent data in the clouds and considerably less persistent data on our Droids, iPads, and Netbooks, we may move from response-time performance hits to device lifetime performance issues associated with less reusable disk space.