2 TB Share Limit - AiO 1200

[CurtH]

We have an AiO 1200 server with 12 x 750 GB SATA. We wanted a big place (speed is not a concern) to dump a lot of data from a lot of users. Using the AiO Storage Manager, Shared Folders are limited to 2TB. This will not work for us. So I created a 2.5 TB logical disk on the array using the Array Configuration Utility and shared out the folder with the usual Windows way. Now, the AiO Storage Manager does not see that share. Should it? If we can't manage this share with the AiO Storage Manager, what's the point having it running? We are inclined to just turn all the HP software and just setting up shares the usual Windows way. It seems odd that setting up a share somehow involves expanding the array. Expanding a RAID and creating a share are two completely different things, in my mind.

[Joshua Small_2]

I'm not familiar specifically with this model, but many iSCSI implementations have a 2TB limit on their LUNs.

The AiO storage manager isn't interested in Windows shares, it's interested in iSCSI LUNs, so that's possibly your reason.

[Patrick Terlisten]

Hello,

the Microsoft iSCSI target is limited to 2 TB. So please don't create LUNs bigger then 2 TB.

Best regards,
Patrick

[roberttco]

Hi Curt,

I am sorry that you are having this issue with your AiO. Using the latest iSCSI target included with the AiO 1.4 update, you can create >2TB luns and then create >2TB file systems in them using GPT the GPS disk format. The All-in-One Stoprage manager is still limited to 2TB. Several factors forced this decision including the "newness" of GPT support in the iSCSI target and performance degredation and resource requirments when using >2TB volumnes in Windows. Resource requirements go up dramatically and performance for file system operations goes down. Finally, ASM only creates basic disks (dynamic disks are expressly not supported) and basic disks are limited to volumes of 2TB. GPT disk can be created using disk manager but if they are >2TB, they can not be managed in ASM.

Regarding the array expansion, it depends on how you created the share. The first share you create will provision storage (e.g. create an array and logical drive) using the requirements you specified. The second share createed will grow the storage to accomodate the new requirments unless you specify that you want to use exclusive storage. Another way to look at this is to considder what happens when you pre-allocate the array. If you use the Array Configuration Utility and create an array and logical drive of, say 100GB and then create a share in ASM of 50MB, no grow operation will take place. If you then create another share in ASM of 100MB, it will see that there is sufficieint storage available and again no grow operation will ocurr. Finally if you add a 200GB share, the array will be grown to accomodate the additional 200GB of space needed.

I suggest considering creating multiple shares on different volumes. Allow ASM to manage the storage for you so that you can get the benefit of the other features (e.g. backups snapshots, etc.) I would, however, begin by creating one share that is 2TB to provision the storage all at once so you do not have to wait on the array rebuild. LAter you can change the share space (which just changes the share quota).

If this is still not accdeptable to you, then using the method you described will work fine (e.g. set up storage and shares manually) keeping in mind that if you want to create volumes >2TB in size, the resource requirments are quite large - typically 2GB of RAM for every 1TB and disk operation times grow at an exponential rate (not geometrically).

[CurtH]

I am not doing iSCSI, I am doing plain-old Windows file sharing. So I should be safe without AiO 1.4 update. (I thought I had the latest, but the ReadMe file says "HP StorageWorks All-in-One Storage System Service Release Version 1.3.0." I just downloaded it last week!)

roberttco's response "when using >2TB volumes in Windows. Resource requirements go up dramatically and performance for file system operations goes down." scares me. But when I Google, I see no warning like this. (roberttco, could you possibly point me to some info on that?) However, I've notice pretty poor performance when I transferred 675 GB to this weekend, a rate of approximately 20 GB/hr, but there are a lot of factors involved. On the AiO itself, the CPU or memory was never pegged during the file transfer. I am hoping to do more controlled performance evaluation, but there is pressure to get this deployed.

I really do not want to split up my shares into 2 TB chunks.

[roberttco · Accepted solution]

The guidance we give to customers is based on internal information so it is unlikely that you will find something on Google specifically. In general the greater resource requirments are a side effect of having to keep more information in memory for GPT disks - particularly for snapshots/volume shadow copies.

Regarding your observed performance, what level of firmware are you using on your controller ? There was a release some time back that afforded native command queieing for SATA disks and it greatly improved write performance (about 6X in my crude tests). Version 4.12 is the latest version that you would want to use - verison 5.20 has a known issue with AiO boxes. Also what raid level are you using and what are the cache settings for the controller ? It is also difficult if not impossible to acheive maximum performance using a single "client" system (e.g. the source for your copy operation).

Finally, since you are not using iSCSI, you can be more confident about using a GPT disk that is larger than 2TB. The GPT support was just recently added to the iSCSI target but it has been around a while for direct attached disks.

[CurtH]

Our controller firmware is 4.12, so things look good there. I am using RAID6 for the 2.5 TB partition and the cache ratio is 50/50.

One thing of possible note: The system ships with the OS and "Do Not Delete" array as a RAID 1+0 on the first two disks. I made the decision to add the other 10 disks into that raid then add the RAID 6, 2.5 TB array. So, I have mixed the RAID levels across the 12 disks. Is this cause for concern? Aside from using the system restore disk, I think I'm stuck with that decision.

I plan to do some quick speed tests ASAP.

[CurtH]

After running a few speed tests, our AiO server is performing just fine. Transfer speeds are averaging 90 Gigabyte/hr. Seems right to me.