Condusiv Technologies Blog

Condusiv Technologies Blog

Blogging @Condusiv

The Condusiv blog shares insight into the issues surrounding system and application performance—and how I/O optimization software is breaking new ground in solving those issues.

Nice article on CTOEdge for Diskeeper 2011

by Colleen Toumayan 18. April 2011 15:39

Michael Vizard, Industry leader and IT Editor wrote an article on Diskeeper 2011 and stated,

"But as more applications begin to share the same IT infrastructure thanks to the advent of virtualization and cloud computing, the more fragmentation becomes an I/O performance optimization issue."

 The full article is located here:


Defrag | Diskeeper | Diskeeper TV

Diskeeper Extremely Shortened and Kept Backup Times Minimized

by Colleen Toumayan 5. April 2011 05:22

Daiwa Odakyu Construction Co., Ltd.  


Daiwa Odakyu Construction Co., Ltd did back up of 15 Servers every day using Symantec Backup Exec. But the problem of latency of backup appeared. Initially the system was designed to finish backup within 3 hours at most. But the time grew to 8 hours. They thought additional hardware was needed but had no additional budget. At that time they discovered the cause of latency was fragmentation. First they tried to solve fragments with the built-in defrag. But it solved only 20%. Next a free defrag software was tried. It proceeded to 35% and shortened backup time by more than 1 hour. But 2 days after, the backup time got back to 8 hours. 


Mr. Kawata, manager of the Information System Group of Daiwa Odakyu, found Diskeeper® via the internet and downloaded trialware from SOHEI. Diskeeper solved all fragmentation and shortened the backup times down to 1.3 hours. What’s more, IntelliWrite® prevented fragmentation up to 99%! In accordance with their trial, the system without Diskeeper added 1 hour a day to their backup times. 


Back up Time(hour) Number of Fragments Number of fragments prevented
Initial design 3.0 - -
Fragmented 8.5 10,000,000以上 -
After defrag by Diskeeper 1.3 250 3,000,0007,200,000
Improvement 85% 99.9975% (断片化防止率99%)

 “I couldn’t estimate such a big influence of fragmentation in the 50% used volume.  The incredible power of Diskeeper is surprising me. The massive fragmentation I gave up trying to solve is now easily defragmented and prevented by Diskeeper, and then this leads to prevent latency of back up completely.  

“The trial without Diskeeper, which resulted in adding 1 hour a day to backup time, scared me so much. With increasing numbers of files, the backup caused massive fragmentation and gets into a dangerous situation. Less than $1,000 investment in Diskeeper is equal to more than $10,000 worth of Servers. I think Diskeeper is vital for file servers and backup servers."  

“I’m thankful to the developers of this surprising software.” 


HP DL380G4 Xeon E5430 4GB Memory 410GB SAS RAID10(146GB SA*6

HP StorageWorks MSA60 3.41TB SATA RAID10(750GB SATA*10  



Defrag | Diskeeper | Success Stories

Fragmentation and Data Corruption

by Michael 31. March 2011 04:54

Diskeeper (data performance for physical systems) and V-locity (optimization for virtual systems) are designed to deliver performance, reliability, longer life and energy savings. Increased performance and saved energy from our software are relatively easy to empirically test and validate. Longer life is a matter of minimizing wear and tear on hard drives (MTTF) and providing an all around better experience for users so they can continue to be productive with aging equipment (rather than frequent hardware refreshes).

Reliability is far more difficult to pinpoint as the variables involved are difficult, if not impossible, to isolate in test cases. We have overwhelming anecdotal evidence from customers in surveys, studies, and success stories that application hangs, freezes, crashes, and the sort are all remedied or reduced with Diskeeper and/or V-locity.

However, there is a reliability "hard ceiling" in the NTFS file system; a point in which fragmentation/file attributes become so numerous reliability is jeopardized. In NTFS, files that hit the proverbial "fan", and spray out into hundreds of thousands and millions of fragments, result in a mess that is well... stinky.

In short, fragmentation can become so severe that it ultimately ends up in data loss/corruption. A Microsoft Knowledge Base article describes this phenomenon. I've posted it below for reference:

A heavily fragmented file in an NTFS file system volume may not grow beyond a certain size caused by an implementation limit in structures that are used to describe the allocations.

In this scenario, you may experience one of the following issues:

When you try to copy a file to a new location, you receive the following error message:
In Windows Vista or in later versions of Windows
The requested operation could not be completed due to a file system limitation
In versions of Windows that are earlier than Windows Vista
insufficient system resources exist to complete the requested service
When you try to write to a sparse file from the Application log, Microsoft SQL Server may log an event that resembles the following:
In Windows Vista or in later versions of Windows
Event Type: Information

Description: ...
665(The requested operation could not be completed due to a file system limitation.) to SQL Server during write at 0x000024c8190000, in filename...
In versions of Windows that are earlier than Windows Vista
Event Type: Information

Description: ...
1450(Insufficient system resources exist to complete the requested service.) to SQL Server during write at 0x000024c8190000, in file with handle 0000000000000FE8 ...
When a file is very fragmented, NTFS uses more space to save the description of the allocations that is associated with the fragments. The allocation information is stored in one or more file records. When the allocation information is stored in multiple file records, another structure, known as the ATTRIBUTE_LIST, stores information about those file records. The number of ATTRIBUTE_LIST_ENTRY structures that the file can have is limited.

We cannot give an exact file size limit for a compressed or a highly fragmented file. An estimate would depend on using certain average sizes to describe the structures. These, in turn, determine how many structures fit in other structures. If the level of fragmentation is high, the limit is reached earlier. When this limit is reached, you receive the following error message:

Windows Vista or later versions of Windows:
STATUS_FILE_SYSTEM_LIMITATION The requested operation could not be completed due to a file system limitation

Versions of Windows that are earlier than Windows Vista:
STATUS_INSUFFICIENT_RESOURCES insufficient system resources exist to complete the requested service

Compressed files are more likely to reach the limit because of the way the files are stored on disk. Compressed files require more extents to describe their layout. Also, decompressing and compressing a file increases fragmentation significantly. The limit can be reached when write operations occur to an already compressed chunk location. The limit can also be reached by a sparse file. This size limit is usually between 40 gigabytes (GB) and 90 GB for a very fragmented file.  

For files that are not compressed or sparse, the problem can be lessened by running Disk Defragmenter. Running Disk Defragmenter will not resolve this problem for compressed or sparse files.


Defrag | Diskeeper | Success Stories | V-Locity

Best Practices for Storage Area Network (SAN) Defragmentation

by Michael 29. March 2011 02:30


As high performing storage solutions based on block protocols (e.g. iSCSI, FC), SANs excel at optimizing block access. SANs work at a storage layer underneath the operating systems file system; usually NTFS when discussing Microsoft Windows®. That dictates that a SAN is unaware of “file” fragmentation and unable to solve this issue.

Fig 1.0: Diagram of Disk I/O as it travels from Operating System to SAN LUN.

With file fragmentation causing the host operating system to generate additional unnecessary disk I/Os (more overhead on CPU and RAM) performance suffers. In most cases the randomness of I/O requests, due to fragmentation and concurrent data requests, the blocks that make up the file will be physically scattered in uneven stripes across a SAN LUN/aggregate. This causes even greater degradation in performance.

Fig 1.1: Sample Windows Performance Monitor Report from fragmented SAN-attached NTFS volume.

Fortunately there are simple solutions to NTFS file system fragmentation; fragmentation prevention and defragmentation. Both approaches solve file fragmentation at the source, the local disk file system.

IntelliWrite® “The only way to prevent fragmentation before it happens™”

IntelliWrite is an advanced file system driver that leverages and improves upon modern Windows’ file system “Best Fit” file write design in order to write a file in a non-fragmented state on the initial write. Intelligently writing contiguous files to the disk provides four principal benefits above and beyond defragmentation, including:

  • Prevents most fragmentation before it happens
  • Better file write performance
  • An energy friendly approach to improving performance, as defragmentation is not required for files handled by IntelliWrite
  • 100% compatibility with copy-on-write technologies used in advanced storage management solutions (e.g. snapshots)

While eliminating fragmentation improves performance. it is important to properly configure and account for advanced SAN features.

With the increasing popularity of SANs, we've included instructions in the Diskeeper installation to ensure users properly configure Diskeeper:

We suggest reading this full document before executing any of the recommended configurations. These instructions apply to V-locity (used on VMs as well).

Best Practices:


Implementing Diskeeper on a SAN is simple and straightforward. There are two principal concepts to ensuring proper configuration and optimal results:

  • Ensure IntelliWrite is enabled for all volumes.
  • Find a time to schedule Automatic Defragmentation (more details below)

If you are implementing any of the following SAN based technologies such as Thin Provisioning, Replication, Snapshots, Continuous Data Protection (CDP) or Deduplication, it is recommended to follow these guidelines.

Defragmentation can cause unwanted side effects when any of the above referenced technologies are employed. These side effects include:

With SAN replication:
Likelihood of additional data replication traffic.

With Snapshots/CDP:
Likelihood of additional storage requirements for data that defragmented/moved and snapshot-related performance lag.

With Thin Provisioning:
Likelihood of additional storage requirements for data that defragmented/moved.

With Deduplication:
Potential for additional deduplication overhead. Also note that deduplication can be used to remove duplicate blocks incorrectly allocated due to defragmentation. This process can therefore be used to reclaim over-provisioned space.

This is why it is important to enable the fragmentation prevention (IntelliWrite) and change the Automatic Defragmentation to occur during non-production periods to address the pre-existing fragmentation:

During Installation, disable Automatic Defragmentation;

Uncheck the “Enable Automatic Defragmentation” option during installation.

Upon installation ensure IntelliWrite is enabled on all volumes (default). IntelliWrite was specifically designed to be 100% compatible with all advanced SAN features, and should be enabled on all SAN LUNs. IntelliWrite configuration is enabled or disabled per volume, and can be used in conjunction with Automatic Defragmentation, or exclusively.

To ensure IntelliWrite is enabled, right click a volume(s) and select the feature.

Then confirm “Prevent Fragmentation on this volume” is selected, and click “OK” to complete.

Once installed, enable Automatic Defragmentation for any volumes that are not mapped to a SAN LUN. This may include the System Partition (e.g. C:\).

To enable Automatic Defragmentation, right click a volume(s) and select the feature.

Then check “Enable Automatic Defragmentation on the selected volumes” and click “OK” to complete.

If you are not using any advanced SAN features, it is recommended to enable Automatic Defragmentation for all days/times. However, note that pre-existing fragmentation will require significant effort from Diskeeper to clean up. This effort will generate disk I/O activity within the SAN.

Therefore, if existing fragmentation is significant, initially schedule Diskeeper to run during off-peak hours. As Diskeeper has robust scheduling capability, this is easily configured.

To enable Automatic Defragmentation during non-production periods, right click a volume(s) and select the feature.

Then check “Enable Automatic Defragmentation on the selected volumes”. Diskeeper is then scheduled by using your mouse to highlight over the 30 minute blocks in the interactive weekly calendar.

The above example disables defragmentation Monday through Friday. It also disables defragmentation Saturdays and Sundays except between 7pm until 3:30am the following morning. This would afford 17 hours of defragmentation availability per week. Immediately following these scheduled defragmentation periods is when SAN maintenance for advanced features should be addressed (e.g. thin reclamation, deduplication).

Should accommodating SAN maintenance be difficult (e.g. limited maintenance windows)using a weekly optimization process, very granular scheduling is also available with Diskeeper. Note, maintenance windows are not required in order to implement and benefit from IntelliWrite.

To schedule for specific non-reoccurring dates and times in the future, select the “Turn Automatic Defragmentation on or off based on specific dates” option. Click any multitude of dates and times using Shift-Select or Ctrl-Select. Once done, click OK to complete.

If you are implementing the above mentioned advanced technologies and your SAN provides hot block optimization / data tiering, it is also recommended to disable I-FAAST® (Intelligent File Access Acceleration Sequencing technology). I-FAAST sequences hot “files” (not blocks) in a Windows volume, after determining hardware performance characteristics. The sequencing process creates additional movement of data for those advanced SAN features, and is therefore generally recommended to disable when similar SAN solutions are in place.

To disable I-FAAST, right click a volume(s) and select the feature.

Note, I-FAAST requires Automatic Defragmentation be enabled. Also note that I-FAAST is disabled by default in Diskeeper 2011 in certain cases. Also note that I-FAAST generates additional disk I/Os and will therefore cause an increase in the aforementioned Automatic Defragmentation side effects.

Once pre-existing fragmentation has been removed, increase the periods in which Diskeeper actively optimizes the Windows file systems. With real-time defragmentation and InvisiTasking® technology, Diskeeper immediately cleans up fragmentation (that is not prevented by IntelliWrite). This minimal ongoing optimization generates only invisible, negligible I/O activity.

New features in Diskeeper 2011 to improve SAN performance:

Diskeeper 2011 introduces SAN specific solutions. These default solutions automate many of the configurations required for SAN-attached servers.

Diskeeper 2011’s new Instant Defrag™ technology dramatically minimizes I/O activity, and exponentially speeds up defragmentation. The Instant Defrag engine is provided fragmentation information, in real-time, by the IntelliWrite file system filter driver (those fragments that it does not prevent). Without the traditional need to run a time and resource intensive whole-volume fragmentation analysis, Instant Defrag can address the recently fragmented files as they occur. This dynamic approach prevents a buildup of fragmentation, which could incur additional I/O overhead to solve at a later date/time.

Diskeeper 2011’s new Efficiency Mode (default) maximizes performance, while minimizing disk I/O activity. By focusing on efficiency and performance and not on presenting a “pretty disk” visual display, Diskeeper 2011 minimizes negative side effects (e.g. reduce snapshot storage requirements or thin LUN growth, etc..) while maximizing performance benefits. It is a SAN-optimized defrag mode and our recommended solution for SAN-attached Windows volumes.

By default, Efficiency Mode also disables proprietary file placement features such as I-FAAST.

Also, by default, Diskeeper 2010/2011 moves data to lower NTFS clusters, and hence generally “forward” on SAN LUNs.

Best Practices Summary:
  • Ensure IntelliWrite is enabled for all volumes.
  • Automatic Defragmentation should be enabled at all times for all direct attached storage volumes.
  • Use Efficiency Mode of Diskeeper 2011.
  • Schedule Automatic Defragmentation on SAN LUNs, based on use of advanced SAN features.
  • Run SAN processes such as space reclamation and/or deduplication on recently defragmented LUNs using advanced SAN features.

Want this in PDF form. Get it here: Best Practices for using Diskeeper on Storage Area Networks.pdf (3.00 mb)

Tags: , , , , ,

Defrag | Diskeeper | SAN

How NTFS Reads a File

by Michael 17. March 2011 11:38

When Windows NT 4.0 was released, Diskeeper 2.0 hit the market. NT 4.0 had limitations about the type of data that could be safely moved online. So, a market-first innovation that Diskeeper brought to market with Diskeeper 3.0 was what we called Boot Time Defragmentation. Boot Time Defragmentation addressed these special data types during the computer boot process, when it was safe to do so. The files that Diskeeper optimized included metadata (data which "lives above" your data), directories (folders), and the paging file. 

Metadata are special files that the NTFS file system driver uses to manage an NTFS volume. The most famous piece of metadata is the MFT (Master File Table), which is a special file typically consisting of 1024-byte records. Each file or directory on the volume is described by at least one of these MFT records. It may take several MFT records to fully describe a file... especially if it is badly fragmented or compressed; A 271MB compressed file can require over 450 MFT records!

Defragmenting the MFT, data files, and folders are all vital for optimal performance. The example below of what occurs when NTFS goes to read in the 1-cluster file \Flintstone\Barney.txt, makes that case.
1. The volume's boot record is read to get the cluster address of the first cluster of the MFT.
2. The first cluster of the MFT is read, which is used to locate all of the pieces of the MFT.
3. MFT record 5 is read as it is predefined to be the MFT record of the root directory.
4. Data cluster 0 of the root directory is read in and searched for "Flintstone".
5. If "Flintstone" is not found, then at least one other data cluster of the root directory needs to be
read to find it.
6. The MFT record for the "Flintstone" directory is read in.
7. Data cluster 0 of the "Flintstone" directory is read in and searched for "Barney.txt".
8. If "barney.txt" is not found, then at least one other data cluster of the "Flintstone" directory needs.
to be read to find it.
9. The MFT record for the "Barney.txt" file is read in
10. Data cluster 0 of the "Barney.txt" file is read in.
This is a worst-case scenario. It presumes the volume is not yet mounted, so the NTFS cache is empty at step 1, and the MFT itself needs to be located.  But it shows how many I/Os are required to get at a file that is only one level removed from the root directory: 10. Each one of those 10 I/Os requires a head movement. Any fragmentation along that path only increases the amount of disk I/Os required to access the data - slowing the whole process down.

And, if you follow the step-by-step I/O sequence outlined above, you'll see that every time a new directory is encountered in the path is an additional two or three I/Os. For obvious performance reasons it is beneficial to keep the depth of your directory structure at a minimum.  It also makes the importance of defragmenting these special file types quite obvious. 

As Windows progressed with newer iterations, many of the files that required offline defragmentation, were supported in online defragmentation (including the MFT and directories), so while Boot Time defrag still exists today, the need to run it has diminished. As a great deal of metadata is typically cached from boot to shutdown, perhaps the last remaining system file that is vital to defragment "offline" is the paging file. We've heard arguments over the years that due to the random nature of the data in the paging file that defrag was not valuable, but anyone who has cleaned up a badly shredded paging file will tell you otherwise.


Defrag | Diskeeper

Month List


<<  September 2017  >>

View posts in large calendar