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.

Guests from Que Publishing and Diskeeper Corporation will appear on Radio Talk Show Let's Talk Computers

by Colleen Toumayan 15. April 2011 04:08

Jeremy Buck, Spokesperson for Diskeeper Corporation, in this series on "How to Speed up your Business Computers," continues his discussion on virtualization, talking about why you need a program like V-locity ®, virtual platform disk optimizer, to keep your virtual computers running at peak performance.

The full release is located here.

Let's Talk Computers ranks as one of the longest-running computer radio talk shows and can be heard weekly in 7 states and 24 hours a day on the website.


virtualization | V-Locity

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 CSV defrag in Hyper-V (Windows Server 2008R2)

by Michael 28. March 2011 04:33

One of the most significant features in Windows 2008R2 (for Hyper-V) is Cluster Shared Volumes (CSV) for virtual disks (vhd). This allows NTFS to behave similar to a clustered file system, addressing many limitations found in Hyper-V storage with the original release (Windows 2008).  

There are three online modes/states for CSV:
  • Direct Access: In this state, the CSV is available to all nodes in the cluster (i.e. all your VMs) for direct high performance storage access. This is the state you want in production.  
  • Redirected Access: In this state, the CSV is still available to all nodes in the cluster, but all I/O is redirected through a single "coordinator" node. Redirected access is used in planned situations where you need to perform certain disk actions that can't have multiple nodes accessing and locking files concurrently, such as a VSS backup or defrag. Channeling all I/O through a coordinator slows I/O and is more likely to cause bottlenecks for production demands.
  • Maintenance mode: enabling this mode is a safe means to get to a state where processes that require exclusive access to a volume can be used, such as a maintenance routine like chkdsk.

Best Practice: 

  • On the Hyper-V system volume,  pass-through volumes and any other non-CSV volumes, leave Automatic Defragmentation on at all times.
  • Given the performance benefits of Direct Access for cluster shared volumes, leave IntelliWrite on and run an occasional scheduled defrag. This is because of the requirement to use the coordinator node and place the volume into a Redirect Access state. Automatically changing from direct to redirect and back is all part of the file system control (kernel code we co-wrote with MS in the mid 90’s – as a Windows source code licensee), and the mechanism all defragmenters use today - you do not need to do anything special.
  • Correction (June 30, 2011): In the process of testing for the V-locity 3.0 release, we discovered that defagmentation does NOT cause a state change to Redirected Access. This is true for any defragmenter. So, defragment CSVs as you would any other volume. [Apologies on making this statement without validation - we should know better :-)] 

Diskeeper and V-locity are fully compatible with CSVs as confirmed by Windows IT Pro here. The file system control built into Windows is used to defrag, but not used for prevention in the design of IntelliWrite, which is a CSV-compatible file system filter driver (it's very important for drivers to be CSV-compatible) residing at a low altitude, expect on XP (where its altitude is much higher). You can view all file system minifilters and their allocated altitudes here.

IntelliWrite is “DKRtWrt” (its code names in development stages was WriteRight and then later RightWrite -hence "RtWrt"). To see or load/unload filter drivers, use the Filter Manager Control Program (fltmc):

Tags: , , , ,

Defrag | Hyper-V | IntelliWrite | V-Locity

Faster Backups/Archiving/Dedupe/DR success with Diskeeper and V-locity

by Colleen Toumayan 27. January 2011 03:29

"Spokane Regional Health District uses CommVault Simpana backup/archiving/disaster recovery software installed on a dedicated server with 37TB of SAS attached storage.


We perform daily full and incremental backups of all our servers. The data backup is disk-to-disk-to-tape and is deduplicated as it is saved on the SAS storage. The deduplication process can create a very large number of file fragments, sometimes over 1,540,000 fragments on a 2TB disk array. With Diskeeper EnterpriseServer automatic defrag running the response time of the arrays is approaching 0.02 second delay due to fragmentation. This has reduced our backup time by approximately 25 percent for any D2D2T job. 

SRHD also uses Microsoft Hyper-V and currently has 31 virtualized servers running on an Intel Modular Server. There are 72TB of storage available to the Modular Server via SAS connections featuring dual path IO. All of the data on the SAS arrays is maintained in RAID 60 logical disk drives. Since setting up V-locity, which has built-in support for VHD (virtual hard disks), with automatic defragmentation, our VHDs very seldom show any fragmentation. 


The solutions also have the intelligence to monitor disk IO and the defragmentation will pause to prevent IO latency affecting performance. They are set and forget applications which perform a very well without impact on our server response times."

-Larry Smith, Spokane Regional Health District


Defrag | Diskeeper | SAN | V-Locity

Defragmenting IT Healthcare

by Michael 20. December 2010 05:18

Joe Marion is founder and Principal of Healthcare Integration Strategies, specializing in the integration of imaging technologies with the overall healthcare IT landscape. His blog (at Healthcare Informatics) covers challenges and opportunities specifically relevant to optimizing Healthcare IT initiatives.

Medical images are a significant percentage of the the world's storage requirements, and have been predicted to encompass an even greater percentage of future storage demand. In Joe's recent blog post he posed the question "Is Defragmentation a Boon to Healthcare IT Performance?"

In his post he includes personal observations and insight into performance implications fragmentation can incur on IT as healthcare departments themselves consolidate and standardize application use:

"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."

He also makes the astute observation that centralizing computing and storage magnifies bottlenecks, making a solution such as defragmentation increasingly more vital:

"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."

You can read Joe's blog here.


Tags: , , ,

Defrag | Diskeeper | IntelliWrite | V-Locity

Month List


<<  September 2017  >>

View posts in large calendar