Data corruption while performing subdisk Move operation.

Data corruption while performing subdisk Move operation.

Article: 100004982
Last Published: 2011-03-18
Ratings: 0 0
Product(s): InfoScale & Storage Foundation


When performing a subdisk move or mirror volume in Storage Foundation for Windows (SFW) on a volume that spans multiple subdisks, there is potential for data corruption when moving a subdisk other than the first subdisk to another disk.


When performing a subdisk move or mirror volume, SFW will perform a calculation to determine used file system clusters. Using the results of this calculation SFW can then determine the starting offset for the clusters and form a list of used clusters.

In certain circumstances, a rounding down of the calculation can cause an error in the starting offset and used file system cluster list and lead to data corruption as some used file system clusters are not included in the list of file system clusters to be moved.


The subdisk move and mirror volume operations have been modified to correctly calclate the starting Logical Cluster Numbers (LCNs) used while syncing used file system clusters so that no block is left out of the sync process.

Veritas has identified the issue and is addressing the issue with patches specific to installed product listed below. Please subscribe to this technical article and/or via the Veritas Operations Readiness Tools site (SORT) for updates regarding the issue and additional fixes for additional versions.

Please contact Veritas Technical Support for additional questions or concerns regarding this update.

Patches are available for affected versions at:


Applies To

  • This issue may be manifest by a file system corruption message in the system event log, or an application logging corruption such as a database corruption or data file read error in the application event log.
  • Permforming subdisk move or mirror volume with the SFW/SFW-HA 5.1 (all AP and SP versions) SmartMove feature enabled.
  • Subdisks that make up the original volume are not aligned to a multiple of 8 times the file system cluster allocation unit size.

To determine if a volume is subject to the corruption issue described in this article, perform the following:

  1. Determine the number of blocks for 8 times the file system cluster unit size.
    1. Find the file system cluster unit size by executing fsutil fsinfo ntfsinfo <driver letter> and getting the “Bytes Per Cluster :” in the output. 
    2. Divide the “Bytes Per Cluster” by 512 and then multiple that by 8

For example, a file system with a Bytes Per Cluster size of 4096 would need an alignment (4096/512) * 8 = 64 blocks.

  1. Determining if a given subdisk is at risk.
    1. Find the plex offset from VEA (Figure 1).
      Figure 1
    2. Divide the plex offset by the alignment value calculated above.
    3. If the plex offset is evenly divisible then the subdisk is not at risk of this issue.
    4. If the plex offset is not evenly divisible then the subdisk is at risk of this issue and the patch should be installed prior to the subdisk move operation being performed.

For our example, with a plex offset of 2097168 divided by 64 for a value of 32768.25.  In this case the plex offset is not evenly divisible by 64 so the patch is needed.


Etrack : 2244087 Etrack : 2244091 JIRA : 2225878 and 2244093

Was this content helpful?