Why you should use GPT rather than MBR on SANs/Storage Servers

We have a lot of infrastructure that we’re rather proud of here in our server room at Neotechnology Business Systems. We have our own ‘mini’ SAN in the form of a HP DL380G5 Storage server complete with a P800 controller, an MSA60, Several NC373i NICs and to top it off the Microsoft HP iSCSI Target Software. We also have three virtual hosts, currently two of which are running Hyper-V and the third is running VMWare ESXi, all of which run their virtual machines on iSCSI LUNs hosted on the storage server. Most of the disks in our storage server are SAS disks for speed and reliability however for space considerations we have a few large SATA disks which offer much cheaper $/GB ratios.

We use all this infrastructure to host literally dozens of Virtual Machines which we use for testing our Point of Sale (POS) product, Amicus. We need lots of VMs to cover all the different scenarios that we deploy our product for such as Hospitality, Fuel, Retail, Supermarkets, Multi-Site Businesses and so forth. But because most of these VMs aren’t utilised all the time and none of them need to be very efficient we host the VHDs (the LUNs) on the SATA Volumes along with all our other space eating files (database backups, ISO files, archives and so forth).

Our problem came about when we expanded our existing 4*1TB RAID1+0 SATA disk set (2TB capacity) to 6*1TB RAID1+0 SATA disk set (3TB capacity). We had previously expanded this same array from 2->4 disks so we were familiar with the process which is basically just plug them in, use the HP Array Configuration Utility to expand the array and the logical drive then jump into Disk Management (in Windows Computer Management MMC) and expand the volume. We followed that procedure and aside from the hiccup of a drive failing (which now seems to be alright strangely enough), we got to the part where we wanted to expand the volume in Disk Management without any issues. However, when we looked at the disk we found that there wasn’t any more space to absorb.

This baffled us for a while, firstly we looked at the array config and verified that it had finished, it had. Then we tried rescanning disks and refreshing and every other trick we could think of but nothing would seem to make the space appear. After a while of Googling around we realised that we had previously, quite inadvertently, hit the 2TB limit imposed by MBR. FAIL! So our 3TB disk set wasn’t ever going to be able to utilise the other 1TB we’d just added.

Much cursing later we found that if we had simply right clicked the volume before we created any partitions on it in the first place (i.e. Over a year ago now...) we would have seen an option to convert the disk to GPT (GUID Partition Table) which is a new(ish) type of partition table that allows for NTFS partitions up to 256TB in size. If only that were the default!

There of course is absolutely no non-destructive way to convert an MBR disk to a GPT disk – not that we would have trusted it in any case. Fortunately, Harvey Norman (Australian Retailer) had Seagate 1TB USB disks on special for a modest $168AU (~$135US) so I ducked out and bought a couple of them. We’ll use Robocopy to copy everything off (duplicating the important stuff) then schedule a complete system outage for 24 hours to give us time to copy the VHDs for iSCSI off and back on again with the iSCSI target turned off so that we don’t have a jumble up of the iSCSI LUNs which would happen if we turned half of them off which would cause all the virtual machines to get the wrong disk which would be a nightmare.

So, lesson in this is, use GPT with large sized disk sets! Hopefully there won’t be any issues hosting VHD iSCSI LUNs on a GPT partition.