none
Space calculation with dual dual parity volume RRS feed

  • Question

  • I have created a storage space pool SP01 with seven 2TB drives.  On this I created a seven column dual parity virtual disk VD01. When I use Get-VirtualDisk VD01 | FC I get the following information:

    class CimInstance#ROOT/Microsoft/Windows/Storage/MSFT_VirtualDisk
    {
      ObjectId = {1}\\KIRKLAND01\root/Microsoft/Windows/Storage/Providers_v2\SPACES_VirtualDisk.ObjectId="{55be8355-481c-11
      e3-80b0-806e6f6e6963}:VD:{302af1cb-5267-11e4-9440-002590930d7b}{302af212-5267-11e4-9440-002590930d7b}"
      PassThroughClass =
      PassThroughIds =
      PassThroughNamespace =
      PassThroughServer =
      UniqueId = 12F22A306752E4119440002590930D7B
      Access = Read/Write
      AllocatedSize = 7992934137856
      DetachedReason = None
      FootprintOnPool = 13987634741248
      FriendlyName = VD01
      HealthStatus = Healthy
      Interleave = 262144
      IsDeduplicationEnabled = False
      IsEnclosureAware = False
      IsManualAttach = False
      IsSnapshot = False
      LogicalSectorSize = 512
      Name =
      NameFormat =
      NumberOfAvailableCopies =
      NumberOfColumns = 7
      NumberOfDataCopies = 1
      OperationalStatus = OK
      OtherOperationalStatusDescription =
      OtherUsageDescription = Virtual diisk VD01 in stgorage pool SP01 on server xxx
      ParityLayout = Rotated Parity
      PhysicalDiskRedundancy = 2
      PhysicalSectorSize = 4096
      ProvisioningType = Fixed
      RequestNoSinglePointOfFailure = False
      ResiliencySettingName = Parity
      Size = 7992934137856
      UniqueIdFormat = Vendor Specific
      UniqueIdFormatDescription =
      Usage = Other
      WriteCacheSize = 33554432
      PSComputerName =
    }

    My question is why is the allocated space 8TB (7992934137856) rather than 10TB?  Since dual parity will use two full disks for parity information, the allocated space seems to be missing one drive.  What am I missing?



    • Edited by Ross Garmoe Tuesday, October 28, 2014 7:28 PM Typo
    Tuesday, October 28, 2014 7:02 PM

Answers

  • Hi,

    I tried to contact related team about this behavior. From the reply it is caused by design. As my previous reply is not accurate please allow me to edit it in-case it will mislead other users.

    Storage spaces uses erasure coding for its dual parity scheme, which optimizes recovery for the common case (single disk failure). This comes at the cost of higher overhead,  which is 3 columns of “parity” information instead of the traditional 2. So for a 7 disk, 7 column dual parity space the amount of usable capacity is (7-3)*disk size, so you get 8TB with 7x2TB disks.

    Here is the breakdown of the different resiliency schemes available, from TechEd NA 2014.

    Maximizing Storage Efficiency with Dell and Microsoft Storage Spaces
    http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B397


    If you have any feedback on our support, please send to tnfsl@microsoft.com.

    • Marked as answer by Ross Garmoe Sunday, November 16, 2014 9:29 PM
    Tuesday, November 11, 2014 1:46 AM
    Moderator

All replies

  • edit: incorrect reply. 


    Thursday, October 30, 2014 6:28 AM
    Moderator
  • If I mount a WD 2TB drive in Windows and check the properties, the capacity is listed as 2,000,396,742656 or 1.82TB.  These two numbers are equivalent.  The first is the manufacturer's listed capacity in decimal.  The second number is what Windows quotes after dividing the binary capacity by 2^40 and converting to decimal. 

    In my case, the decimal capacity of the 7 column dual parity array is listed as 7,992,934,137,856 decimal or 7.44TB after dividing by 2^40.  Actually, the properties display show the capacity as 7.26TB which is equivalent to 7,795,365,642,240.  I assume the difference is some magic in how Windows calculates the capacity. 

    Also, 7.26TB/1.82TB (both Windows capacity figures) is 3.989 drives.  The difference may be due to the fact that the drives actually in the array are not WD 2GB drives but Seagate 2TB drives with slightly different capacities.

    By the way I figure it, I am still missing one drive.  Are there any ways I can figure out how Windows actually laid out the storage spaces?

    Friday, October 31, 2014 7:59 AM
  • Or to put it another way 7,992,934,137,856 bytes of capacity divided by 5 drives is 1,598,586,827,571.2 bytes used per drive.  This is 400GB per drive unused or unexplained space.
    Friday, October 31, 2014 5:07 PM
  • Note: all of the following information is for a 7 column virtual disk.

    I deleted the dual parity disk and created a maximum size single parity disk.  The capacity is 11,989GB  I then deleted this disk and created a maximum size dual parity disk.  The capacity for this one is 7,992GB.

    The question that I would like you to ask the Storage Spaces people is why a dual parity disk takes 3 drives for parity.

    Thanks

    Ross

    Friday, October 31, 2014 7:16 PM
  • Hi,

    I tried to contact related team about this behavior. From the reply it is caused by design. As my previous reply is not accurate please allow me to edit it in-case it will mislead other users.

    Storage spaces uses erasure coding for its dual parity scheme, which optimizes recovery for the common case (single disk failure). This comes at the cost of higher overhead,  which is 3 columns of “parity” information instead of the traditional 2. So for a 7 disk, 7 column dual parity space the amount of usable capacity is (7-3)*disk size, so you get 8TB with 7x2TB disks.

    Here is the breakdown of the different resiliency schemes available, from TechEd NA 2014.

    Maximizing Storage Efficiency with Dell and Microsoft Storage Spaces
    http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B397


    If you have any feedback on our support, please send to tnfsl@microsoft.com.

    • Marked as answer by Ross Garmoe Sunday, November 16, 2014 9:29 PM
    Tuesday, November 11, 2014 1:46 AM
    Moderator
  • That is what I needed to know.  It is not at all obvious what the available space for dual parity will be.
    Sunday, November 16, 2014 9:28 PM
  • Ross, hi.

    (This is off topic.) You might know that the vintage Purdue CDC 6500 is now up and running at Paul Allen's Living Computer Museum (LCM) in Seattle. I think you are the same Ross Garmoe who worked with Gordon Letwin and I at the Purdue University Computer Center in the mid 1970's.

    Tom Hunter is working with LCM to reconstruct a working Purdue MACE / MESA operating system from sources. Tom is the author of the DtCyber emulator.

    Can you send an email to my address croft@lightfield.com ? Tom has some questions regarding the data flow between MESA, 1IM, and the Modcomps. I know you wrote most of that code. LCM already has KRONOS running. And Tom runs NOS with TCP interface on his DtCyber. A goal is to TCP interface the LCM Purdue machine running MACE.

    Best regards,

    Bill Croft [Purdue Modcomp guy]

    Sunday, February 7, 2016 9:09 PM
  • For anyone else that comes across this, the answer is essentially accurate, but misleading.  Storage Spaces Dual Parity uses Reed-Solomon encoding to create two parity chunks for 4+ equally sized data chunks.  This should produce a 4+2 scheme for storage (or 5+2 for the 7 disk setup required by Storage Spaces Dual Parity).  The issue is that Storage Spaces ALSO stores a "Global Parity" data chunk, for use when spanning data over multiple servers.  The problem is that this is obviously a waste of space in a single server scenario.  So, for a single server 7 drive setup, you end up with 4 data disks, 2 parity disks, and 1 disk holding useless information.

    In a multi-server setup, there should only be one copy of the global parity across the servers, which would improve efficiency.  You can see some additional information about LRC here:

    https://www.microsoft.com/en-us/research/wp-content/uploads/2016/11/LRC-Erasure-Coding-in-Windows-Storage-Spaces.pdf

    Edit:  I just tested this in Server 2016, and it looks like the behavior has been changed.  The New-VirtualDisk cmdlet no longer creates the global parity by default, possibly by the new switch -NumberOfGroups being 1.  However, on a 7 disk array, it will set the number of columns to 6 by default instead of 7.  For reference, this is what pool capacity usage looks like in a 7 disk pool for 100GB virtual disks using dual parity on Windows Server 2016 1607:

    150GB - Default settings, using 6 columns

    140GB - Using 7 columns

    175GB - Using NumberOfGroups = 2

    • Edited by Atamidos Wednesday, November 1, 2017 5:17 AM Additional information
    Wednesday, November 1, 2017 4:52 AM