What would be the small and high LUN size can be created in VNX/Clariion?

Hi Vibin,

Just an add-on to Dynamox post……

In CLARiiON the user capacity of RAID group is calculated by multiplying the number if user drives by the user capacity of the individual drives making up the RAID group, For example, a 400 GB FC drive has a formatted data capacity of about 367 GB.., with RAID 1/0 (3+3) group would have a max user capacity of about 1101 GB (3 * 367) .., the approximate 1100 GB is the maximum capacity of a FLARE LUN bound on the RAID group……Striping two FLARE LUNs using the max user capacity of this RAID group’s provisioning would create a MetaLUN with a max possible user capacity of 2.2 TB.

The following table summarizes maximum pool LUN capacities supported on a VNX Series.

Regards,

Suman Pinnamaneni

it does let me create 1 block LUN, sure eats a lot for metadata

is there a typo in "EMC VNX Virtual Provisioning - Applied Technology" WP, on page 19 it has:

I would have to test it to verify one way or the other. My impression is it was block count, but it’s possible they limited the pool LUN driver to a 1MB minimum. Architecturally I’m not sure why though since pool LUNs allocate 1GB slices (1MB is just a small portion of the minimum allocation size) and Thin LUNs consume space in 8KB chunks.

And the more I think about this, I realize 512KB is wrong too. Block size is 512 bytes, not 512KB, so you should be able to create a LUN that is only 512 bytes (1 block) in size.

This may not hold true for Pool LUNs though, and regardless, a Pool LUN consumes at minimum 3GB of space (of which only 1GB is user capacity) from the Pool, so creating a LUN smaller than 1GB user space saves absolutely no disk space at the array level.)

Richard J Anderson

Sr SE - Western Division, EMC

richardj.anderson@emc.com

206.229.9263

EMCTA, SPEED

This white paper was the only reason I didn't comment as 1 Block and stopped myself from posting it here as I was not 100% sure. Theoratically speaking, answer can be 1 Block but logically 1 MB or more, not just VNX any storage system.

What are your Thoughts, D?

Would love to have a fruitful conversationw with you about this Richard like we had earlier on mLUs!

Further info..

For a Traditional LUN on traditional RAID groups, the maximum LUN size is the total usable capacity of the RAID Group it is bound to. Since the largest single RAID Group you can create is 16 disks and largest drives available today are 3TB, you could theoretically create a 14+2 RG of 3TB SATA disks with a single LUN of about ~39TB.

Using MetaLUNs across multiple traditional RAID Groups, you could create a single MetaLUN that consumes all of the available capacity on the array, there is not actually a technical limit on the size of the LUN presented to the host from the CLARiiON/VNX perspective.

For Pooled LUNs, 16TB is the limit currently regardless of RAID type, drive size, or drive quantity.

In both cases, the smallest user capacity as mentioned below is 1 block (512KB)

Richard J Anderson

Yeah, that’s why I mentioned that, in practice, making a 1 block LUN in a Pool would be useless. The Thin LUN metadata uses a 1GB slice to start and then allocates a 1GB slice for the user data. So a 512-byte user LUN consumes 2GB from the pool right out of the gate. I also read somewhere that the Pool LUN pre-fetches another 1GB slice to be ready for when the first slice is full and it needs to spill into the second. Looking at your output it seems that the small user capacity prevented the 3RD 1GB slice from being allocated. A traditional RAID Group LUN wouldn’t have the metadata so you’d consume less actual disk space.

There is of course a minimum size that a host will actually mount and use which is dependent on the host filesystem type. NTFS can be formatted with 512byte clusters but the MBR is 63KB so you’d probably need something like 1MB at minimum for it to even create a partition that can be mounted. We use 3MB LUNs all the time with Symmetrix systems to be used for inline management of the symm (these LUNs are called Gatekeepers) and I’m told that one of the byproducts of the 3MB size is that OS’s tend to ignore them due to their small size. Microsoft states that 10MB is the minimum recommended size for NTFS but it’s not clear what the technical minimum is.

The other thing I’m not clear on is how a 512-byte user LUN is striped across the disks in the RAID Group. CLARiiON/VNX uses 64KB block sizes on disk so a 4+1 RAID group would have a 256KB stripe size + 64KB of parity. I guess it must put 128 bytes on each disk and calculate about 128 bytes of parity, but I think that means it’s technically consuming 256KB of disk space (not counting parity) even though the actual user capacity is 512-bytes. I’d have to do more research to find out how this works.

Richard J Anderson

We use 3MB LUNs all the time with Symmetrix systems to be used for inline management of the symm (these LUNs are called Gatekeepers) and I’m told that one of the byproducts of the 3MB size is that OS’s tend to ignore them due to their small size.  Microsoft states that 10MB is the minimum recommended size for NTFS but it’s not clear what the technical minimum is.

oh no, it does not ignore them all. My windows/linux boxes can see VCM, ACLX and gatekeepers ..i can actually format that if i wanted to.

Is it still 16TB without virtual pooling?

As mentioned above.. The size of a traditional LUN is limited to the size of the RAID Group it is created in.. So the largest traditional LUN possible on a VNX today would be a single LUN created within a 15+1 RAID5 RG consisting of 3TB drives (approximately 40TB). Using R5 with 3TB disks would not be best practice however, so this is just an example.

Using MetaLUNs, you can create a single large MetaLUN consisting of all the storage available on the array, spanning all disks and RGs, if desired. But this would likely not meet most of the performance requirements of typical applications.

You’d be better off using multiple LUNs, spread across both SPs, and joined via host based LVM of some kind (Veritas, ASM, Linux LVM, etc)

Richard J Anderson