none
Extremely Large Volume - Pro and Cons

    General discussion

  • "Extremely Large" is only meant in the 2013 standard.  I'm sure it will be "not so large" in 5 years and "tiny" in a decade.

    We're a large organization and one of the responsibilities of my group is to manage about half a million user homefolders, which are currently spread across about 100 volumes in 10 file clusters.

    As grand and majestic it may seem, problems arise when those volumes are filled up.

    At one point the situation became so bad that I had to assign one of my staff to move homefolders around FULL TIME, in order to continue some service.  What an expensive and completely meaningless excercise to do!

    We do implement quotas and expand the volumes regularly, however it never catches up with the demand, since we're forced to overprovision due to our size.  Imagine if we provide 1GB of space per user, quite pathetic in today's standard, we need 500TB of space just to fully provision the storage.

    I'm aware of some technology (Storage Pool in 2012, EMC, etc.) for building very large volumes.  This will be ideal for my situation.

    However, I also heard some concerns from different people in regards to extremely large volumes.  Backups, RAIDs and maintenance are some concerns, although I don't quite understand much in those areas yet.

    Now, although technically possible, what will stop me from building a 10PB volume, put everything there and don't worry about it for the next 5 years.......

    Pros and Cons, experts?

    Monday, January 21, 2013 5:47 PM

All replies

  • Well just want to add that 10PB is just an arbitary number I came up with and although it exceeds the 256TB NTFS limitation, it's not actually as crazy as people may think.  Some other file systems like UFS supports volumes as large as 8ZB.

    My point is, we're living in an age when the amount of information explodes exponentially, while storage becomes cheaper and cheaper.  Does it make sense to work towards a one volume architecture in order to eliminate all administrative burden?
    Monday, January 21, 2013 11:16 PM
  • Hi,

    I did not find the 256TB limitation in the article you provided about NTFS.

    It said the Max Volume Size of NTFS is "2^32 clusters minus 1 cluster" and NTFS5 is 2^64 clusters minus 1 cluster.

    Here is another article:

    Maximum Volume Sizes

    http://technet.microsoft.com/en-us/library/cc938432.aspx

    Note:

    2^64 is 18,446,744,073,709,551,616. That's 17,179,869,184 gigabytes.

    1PB=1,125,899,906,842,624=1,048,576 gigabytes.


    TechNet Subscriber Support in forum |If you have any feedback on our support, please contact tnmff@microsoft.com.

    Wednesday, January 23, 2013 8:09 AM
    Moderator
  • Let me discuss few things before answering pro and cons. As you are aware storage pool you do understand QoS (Quality of Service). As Service doesn't come free to you, you need to pay higher price for resilient volumes. Consider three type of data

    1) Critical data like hosting your app. You need it to be up and running 24X7.

    2) Personal data. You do need it to be fault tolerant but in case of corruption you are fine to wait for some time to get it recovered.

    3) Backup data. You will only need it if something drastic happens. So you can keep it on a cheap storage device like tape.

    Now coming to your question the volume you are creating will have same QoS. So if all of them are critical data you know the price you are paying.

    1) You may end up paying for something which you will never need. Like fault tolerant backup data.

    2) If you compromise on QoS in case of corruption you will end up losing huge amount of data.

    From Pro I can think management might look easy but don't get fooled. Taking snapshots/backups  and managing them may turn to be a big headache.

    Let me know if it clarifies your doubt,

    Regards

    Satish

    Wednesday, January 23, 2013 5:02 PM
  • Hi,

    I did not find the 256TB limitation in the article you provided about NTFS.

    It said the Max Volume Size of NTFS is "2^32 clusters minus 1 cluster" and NTFS5 is 2^64 clusters minus 1 cluster.

    Here is another article:

    Maximum Volume Sizes

    http://technet.microsoft.com/en-us/library/cc938432.aspx

    Note:

    2^64 is 18,446,744,073,709,551,616. That's 17,179,869,184 gigabytes.

    1PB=1,125,899,906,842,624=1,048,576 gigabytes.

    Thanks Shaon.

    There is this article that states the 256TB limit.

    I think the calculation is based on 2^32 clusters * 64KB per cluster - 64KB = (256TB - 64KB) maximum volume size. You mixed up the clusters and bytes above.

    I think the 2^64 vs 2^32 difference is based on some system limitation (could be the volume table).
    Friday, January 25, 2013 4:16 AM
  • Hello,

    In 2012, there is UEFI support for up to 9.4 Zettabytes in a single partition! 


    Miguel Fra | Falcon IT Services, Miami, FL
    www.falconitservices.com | www.falconits.com | Blog


    Friday, January 25, 2013 4:45 AM
  • Let me discuss few things before answering pro and cons. As you are aware storage pool you do understand QoS (Quality of Service). As Service doesn't come free to you, you need to pay higher price for resilient volumes. Consider three type of data

    1) Critical data like hosting your app. You need it to be up and running 24X7.

    2) Personal data. You do need it to be fault tolerant but in case of corruption you are fine to wait for some time to get it recovered.

    3) Backup data. You will only need it if something drastic happens. So you can keep it on a cheap storage device like tape.

    Now coming to your question the volume you are creating will have same QoS. So if all of them are critical data you know the price you are paying.

    1) You may end up paying for something which you will never need. Like fault tolerant backup data.

    2) If you compromise on QoS in case of corruption you will end up losing huge amount of data.

    From Pro I can think management might look easy but don't get fooled. Taking snapshots/backups  and managing them may turn to be a big headache.

    Let me know if it clarifies your doubt,

    Regards

    Satish


    Thanks very much Satish for your reply.

    I guess great minds think alike and we actually have a tiered storage structure in different grades.  Just like you said App and DB data are stored in the most expensive high performance disks.   Non-app data such as homefolders and departmental shares are fault tolerant and stored in the lower grade disks.  Backups used to be on tapes but we have transitioned to disk backup since tapes are unacceptably slow given the amount of our data.

    By one volume I mean grouping all data of the same priority/criticality into one logical space/volume instead of spreading out into hundreds of different volumes. Homefolders, for example, is my main target for such consolidation.

    Our backup team is one of the biggest protestors of such idea. Their main argument is backup will be a lot less efficient and more time consuming with one large volume vs many smaller ones.  This is understandable, however, only in the sense that the backup is performed on the same logical layer.  I don't believe backups can only be done in the front end.  The storage, after all, is just the same bunch of disk arrays in the back end.  There must be a way for more efficient backup that operates independently from the logical volume and its limitations.

    I'd also like to comment about the 256TB volume size limit of NTFS.  Will Microsoft eventually do something about it or we'll have to consider other file systems as alternatives?  256TB is still a beast for domestic use, but in Enterprises that is starting to become a normal deal.
    Friday, January 25, 2013 5:14 AM
  • In 2012, there is UEFI support for up to 9.4 Zettabytes in a single partition!

    That's wonderful, but we're still subject to the 256TB limit of NTFS........ unless we abandon Windows altogether lol
    Saturday, January 26, 2013 5:22 AM
  • Hello,

    Server 2012 has UEFI support and ReFS support. ReFS is backwards compatible with NTFS and supports a 262,00 Exabyte single volume.

    http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx


    Miguel Fra | Falcon IT Services, Miami, FL
    www.falconitservices.com | www.falconits.com | Blog


    Saturday, January 26, 2013 5:03 PM
  • Server 2012 has UEFI support and ReFS support. ReFS is backwards compatible with NTFS and supports a 262,00 Exabyte single volume.

    http://blogs.msdn.com/b/b8/archive/2012/01/16/building-the-next-generation-file-system-for-windows-refs.aspx



    Great article, thanks.  Although there are some criticisms of this new file system, it's truly worth consideration.

    Lack of disk quota is a disappointment, but I think FSRM can fill the gap.

    I appreciated all these useful replies.  Now I know which direction we should take.
    Saturday, January 26, 2013 6:07 PM