THE SQL Server Blog Spot on the Web

Welcome to - The SQL Server blog spot on the web Sign in | |
in Search

Joe Chang

What breaks with GPT disk partitions greater than 2TB?

In one of the recent Windows OS versions, GUID Partition Table (GPT) became an option in addition to Master Boot Record (MBR) for creating disk partitions, with GPT supporting volumes larger than 2TB. In MBR, a 32-bit unsigned integer addresses 512-byte sectors (yeah, there is a push to adapt 4K sectors), so the disk partition limit was 2TB (2.19x1012).

OK, then fine. The Windows Server OS supports GPT and SQL Server has been tested to support >2TB partitions. But to what extent has this been tested? I am sure Microsoft has many SANs with 10-100TB storage capacity, and someone tested 2TB plus. But anyone that works with big complex systems and storage systems has probably got tired of clicking the GUI repeatedly (no joke: one colleague had to go on 6-week disability after doing too many PowerPoint slides), so we do everything from SQL scripts and probably forgot how to use SSMS. (Me, I really liked Query Analyzer, especially how quickly it launches.)

I am sure Microsoft has QA people who must test every single feature of each GUI tool, SSMS, CVT etc., but how many tests are on 2TB plus disks? and then 2TB+ files? So what can break? Even though the core OS and the SQL Server engine core works, there are many utility tools out there that makes file IO API calls. How many work with >2TB partitions or files, and how many still use a 32-bit unsigned integer to represent the sector offset? Or otherwise thinks a partition/file must be less than 2 billion KB?

Now I am sure most people out listen to every word I say as the word of @#$. In which case your storage system is comprised of a great very many 15K 146GB disks distributed over many IO channels, which further implies that each RAID group is probably comprised of 4-8 disks (Fast Track originally recommended 2 disk RAID groups, which results in too many LUNs).

In which case, 8 disks at 146GB (decimal 146x1012 = binary 136x230) in RAID 10 makes for a 543GB LUN. Even if it was 8 disks 300GB in RAID 5, the 1955GB LUN is still under 2TB. So you would have never encountered any >2TB issues. But there are a few who do not seem to follow my advice, and instead choose to trust the technical expertise of your SAN vendor.

Published Friday, December 09, 2011 10:06 PM by jchang

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS



Harry said:

What seems to be the issue with >2TB? We have several Dell R910's in our shop with multiple 2-4 TB LUN's attached. Personally, I have not seen any problems.

December 9, 2011 9:45 PM

Randall said:

I have a 15TB MDF file on a 15TB Equalogic SAN volume. No problems.

December 13, 2011 6:48 AM

yup said:

@Randall, mind if you can answer a few questions on that 15 TB vol of yours

July 10, 2012 10:56 PM

jchang said:

another point is that even with multi-path IO, the IO traffic to any single LUN must go over 1 path only, ie, 95MB/s for 1GbE and 700-900MB/s for 10GbE. So at best 15,000 sec to backup 15TB on one iSCSI LUN, and probably much longer

July 11, 2012 1:21 AM

Leave a Comment


About jchang

Reverse engineering the SQL Server Cost Based Optimizer (Query Optimizer), NUMA System Architecture, performance tools developer - SQL ExecStats, mucking with the data distribution statistics histogram - decoding STATS_STREAM, Parallel Execution plans, microprocessors, SSD, HDD, SAN, storage performance, performance modeling and prediction, database architecture, SQL Server engine

This Blog


Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement