Accurate size of a disk

I'm currently working on vbscript to report disk, partition, and logical drive usage and size data, in an exact way, in bytes. I use several WMI queries of Win32_DiskDrive, Win32_DiskPartition, Win32_LogicalDisk with associations. In some certain circumstances I've got interesting results, where the size of the disk is less then the size of the partitions on it.

In my experiences I've got these results from disks provided by the virtualisation layer, or by SAN connections.

For example:

Win32_LogicalDiskToPartition shows:

Antecedent       : \\xxxxx\root\cimv2:Win32_DiskPartition.DeviceID="Disk #2, Partition #0"
Dependent        : \\xxxxx\root\cimv2:Win32_LogicalDisk.DeviceID="T:"
EndingAddress    : 1099510579199
StartingAddress  : 1048576

from this data, the size should be 1 099 509 530 624 bytes and the EndingAddress: 1 099 510 579 199

the corresponding Win32_DiskPartition shows:

NumberOfBlocks   : 2147479552
BootPartition    : False
Name             : Disk #2, Partition #0
PrimaryPartition : True
Size             : 1099509530624
Index            : 0

which is Ok, but the corresponding Win32_DiskDrive shows:

Partitions : 1
DeviceID   : \\.\PHYSICALDRIVE2
Model      : IBM 2145  Multi-Path Disk Device
Size       : 1099506078720
Caption    : IBM 2145  Multi-Path Disk Device

The size is: 1 099 506 078 720

So the partition is greater then the disk.

From the MSDN library: https://msdn.microsoft.com/en-us/library/aa394132%28v=vs.85%29.aspx

Size
Data type: uint64
Access type: Read-only
Qualifiers: Units (Bytes)

Size of the disk drive. It is calculated by multiplying the total number of cylinders, tracks in each cylinder, sectors in each track, and bytes in each sector.

For more information about using uint64 values in scripts, see Scripting in WMI.

TotalCylinders
Data type: uint64
Access type: Read-only

Total number of cylinders on the physical disk drive. Note: the value for this property is obtained through extended functions of BIOS interrupt 13h. The value may be inaccurate if the drive uses a translation scheme to support high-capacity disk sizes. Consult the manufacturer for accurate drive specifications.

Example: 657

For more information about using uint64 values in scripts, see Scripting in WMI.

By the above property definitions, the disk size can be inaccurate.

Does anybody know a way to get the accurate disk size using wmi, or any script technique?

May 21st, 2015 10:09am

Hi Papp,

Does your SAN setup has any interface, I think it would be more accurately reporting the actual size. Any mechanism to read that info into windows would solve your purpose.

But I havn't seen anyone having issues with these reporting inaccuracies, you seem to be having some special case.

In your case its about 3 MB of inaccuracy for a single disk, for 1000 disks it would be 3GB. This in normal scenarios would be within acceptable tolarance.

Free Windows Admin Tool Kit Click here and download it now
June 10th, 2015 4:27am

Hi Satyajit321,

Sorry if I was not clear enough, my issue does not related to SAN disks only. Maybe the example could cause this mis-understanding. It mostly occures with disks of some kind of virtualization layer, or not real hard-disk-drives, like VMWare virtual machines, or SSDs, or FlashDrives, and so on...

The found inaccuracy would not be so big deal, but when I tried to create a report about used storage capacity, and calculate the "free" or "available" (not partitioned) space on the disk, and get negative numbers, it is rather disturbing. At least for me. :) I think or rather I feel there must be a way to get the exact size, as the Operating system is able to create partitions on that part, which is over the reported size.

June 11th, 2015 11:12am

Hi Papp,

Seems like you have found issues with the Virtual machine disk reported.

This is not much related, but just to highlight. When using Dynamically Expanding Disks the VM disk capacity can be more that the actual physical disk. Having this possibility might be the reason behind of this inaccuracy.

Free Windows Admin Tool Kit Click here and download it now
June 17th, 2015 3:39am

Hi Satyajit321,

SSDs and FlashDrives are not typically "Dynamically Expanding Disks". I think the secret is somewhere else.

June 17th, 2015 3:56am

Hi Papp,

I get that we are going off topic on this.

There are some similar queries existing for long time.

Basically what I can suggest is don't mix the use of "Win32_DiskDrive.Size < Win32_DiskPartition.Size" in a same reporting tool. Use either of it not both.

Similar issues:

Can anyone explain why WMI WIN32_DiskDrive.Size 5MB smaller than Win32DiskPartition.Size on the same disk???

Who can Explain: Win32_Disk.Size < Win32_DiskPartition.Size???

Free Windows Admin Tool Kit Click here and download it now
June 17th, 2015 5:36am

Hi Papp,

Issue here is the block size:

Sum fo NumberOfBlocks_DiskPartition > TotalSectors_DiskDrive

The TotalSectors = #Blocks   - is calculated correctly as per your formula [total number of cylinders* tracks in each cylinder * sectors in each track * bytes in each sector(512).]

Now the question here is how is NumberOfBlocks in Win32_DiskDrive calculated. This is also called "Number Sectors :" for Partition.

To determine the cluster size of a volume, run the following command at a command prompt, and then note the "Bytes Per Cluster" value: fsutil fsinfo ntfsinfo <<var>volume</var>> Note The <<var>volume</var>> placeholder represents the volume letter.

For example, when you run the  fsutil fsinfo ntfsinfo c: command, you may receive results that resemble the following output:
NTFS Volume Serial Number :             0xf4300f6c300f3560 
Version :                               3.1 
Number Sectors :                        0x000000001d17dbee 
Total Clusters :                        0x0000000003a2fb7d 
Free Clusters :                         0x000000000102bfa0 
Total Reserved :                        0x0000000000000800 
Bytes Per Sector :                      512 
Bytes Per Cluster :                     4096 
Bytes Per FileRecord Segment :          1024 
Clusters Per FileRecord Segment :       0 
Mft Valid Data Length :                 0x000000000e630000 
Mft Start Lcn :                         0x00000000000c0000 
Mft2 Start Lcn :                        0x0000000001d17dbe 
Mft Zone Start :                        0x00000000002185a0 
Mft Zone End :                          0x0000000000218740 
RM Identifier :                         1587CC47-A713-11DB-9287-806E6F6E6963
Note In this example, the "Bytes Per Cluster" value is 4096. This value represents a 4-kilobyte (KB) cluster size.

if you convert the HEX values to Decimal+1 it will be equal to NumberOfBlocks for that partition.

What I understood from all these research is that, Win32_DiskDrive is doing guess work (hence the warning by MS) and Win32_DiskPartition is actually reading the disk looking for StartingAddress -EndingAddress on the disk, hence is the true size.

It uses this information to decide upon the actual NumberOfBlocks for the partitions.

Win32_DiskDrive : Faster, quick, approximate info

Win32_DiskPartition: Slower, accurate info

References:

Frequently asked questions about the GUID Partitioning Table disk architecture

https://support.microsoft.com/en-us/kb/302873

This is not limited to Windows, but Linux too real number of sectors on HDD

http://superuser.com/questions/567227/real-number-of-sectors-on-h

June 17th, 2015 6:48am

Hi Papp,

You are right, as you have observed this is not limited to Virtualization only. I was referring to Dynamically Expanding VHDs.

May be you can start a post for the reporting that you are doing, someone might be able to suggest something to avoid your -ve values.

Free Windows Admin Tool Kit Click here and download it now
June 17th, 2015 8:57am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics