Data ONTAP 8.x 16TB LUN Size Limitation

[#1]

I just ran into the Datat ONTAP 8.x 16TB LUN limit within my own environment and thought I'd start a thread to discuss how customers are handling requirements for LUNs greater then 16TB in size?  As NetApp has indicated that LUNs greater then 16TB will not be supported in the near future I ask what are my alternatives. I am limited to using Windows has my host OS and am also limited due to snapdrive not supporting backups of dynamic disks.  I'm guessing I'll end up having to write a script to snapshot a consistency group.

In my mind it makes no sense that I can do all of the following but create a 16TB+ LUN

Aggregate 100TB Size Limit (6280)

Volume     100TB Size Limit

[#2]

are volume mount points an option for you?

eg have a 16TB disk E:

Then add several more 16TB LUNs as

E:\files1

E:\files2

E:\files3

so the directorys can store additional 16TB each?

[#3]

I discussed this option with the customer and they explained that this won't work due to an application constraint.  For now it's back to the drawing board.  I'm looking at their performance and I/O requirements now to see if CIFs is a viable option.  Although based on the partition size requirement and their data change rate I'm guessing CIFs will fall short on the performance side.

[#4]

Is there any chance you could give us a few more clues about what the customer is trying to accomplish with these immensely huge filesystems?  Just if you are open to a little more of a "brainstorming" solution.  Sometimes one is too close to the trees to see the forest...

For my part, I'm still trying to get my head around situations where such huge filesystems would be necessary.  The application is either hugely specific or terribly designed... at least from my initial gut feeling...

:-)

[#5]

The application is the root cause of the problem and is poorly designed.  

[#6]

Not that this is much help, but as a SANscreen guy I don't see metas that large - I happen to be looking at a environment with 1.5 PB raw DMX, and across the 15k or so luns carved, only one is > 1024GB usable. There are around 5k metas in this environment

[#7]

Use stripping from OS level (e.g. for Windows it looks like it is defined here http://www.techimo.com/articles/index.pl?photo=149), this will theoritcally build you something like software RAID0 (or stripped LVM) - so you'll have one single disk with single filesystem on it.. but it opens a can of worms when it comes to scalability and performance.

The LVM is typical solution used in the UNIX world.

-J.