Clariion thin LUN sizing

we're on 5.6.47-11 not 5.6.7.11

Hi Scott,

the size of the LUNs doesnt matter much, but try to:

- make them all the same size

- have enough LUNs from at least 2 (better 4) different raidgroups

- create a thin pool thats only used for NAS LUNs

With NS Integrated’s we typically:

- create at least two LUNs per RG so that both SP’s can get used

- more than two if the RG was larger than 4TB (but newer NAS codes also support LUNs >2TB)

All the NAS support matrix says about using thin LUNs is:

 One AVM system-defined virtual pool is automatically created for each visible CLARiiON Thin Pool

during regular diskmark process.

 Thin LUNs are managed during regular disk mark and delete operations.

 CLARiiON rules and best practices apply.

 Mixed pools are not supported.

 Celerra does not support mixing thin and thick LUNs in the same file system or Celerra iSCSI LUN.

Make sure you read the Managing Volumes manuals to understand how thin LUNs are used

Regards

Rainer

As I'll be using thin pool i won't be able to control how the RGs are configured; apart from adding the disks in multiples of 8 for R6.

Thanks for the info contianed within the nas support matrix. There's nothing new there, so looks like I'm good to go.

Is there any info on how the celerra handles deleted data within thin luns? I would guess it would depend on the OS using the file system. i.e.windows does not reuse these areas until it has to, and *nix which does. Does that rule apply when writing data to CIFS and NFS on a Celerra? Or as the Celerra is managing the writes to disk the space is reused. There little is to no detailed information out there on this. The VP WP doesn't even mention the Celerra let alone provide any info.

So, more questions ... how does dedupe and compression affects the consumed space? Does the space reclaimed by these processes get reused by the Celerra within the file system or is this handled by the OS using the FS.

With the announcement of FLARE 30 there have been number of VP enhancements. Does anyone know if there are any improvements for the Celerra? Can it used the new space reclaimaton feature?

Maybe we'll have to wait for the new dart code to make use of these, and other undisclosed features.My VC is continuingly pushing VP to us yet there is very little information on how it works with the Celerra. There's plenty, well, enough info on the sym and clar, but very little on how  it works with one of EMC's own products. I know I've gone on a bit of a rant here, but it's very frustrating.

I opened an SR the other asking about what happens when a thin pool fills, and what can be done (bar adding disk) to resolve a full thin pool. Can disks be lun migrated to another? I received a full answer full of shoulds, mights, and maybe's, which is not very reassuring. I'd already started to do my own testing on this, and will publish those results here if I have time ... or idea remember.

Hopefully some of you guys have tested this sort of thing before, and can put me out of my misery.

Regards,

Scott

Hi Scott,

AFAIK the only way to influence which raidgroups are built under the cover is to always add disks in multiples of the preferred VP raidgroup size.

the Celerra uxfs file system handles thin LUNs the same way as thick LUNs.

If a file gets deleted, the blocks are marked free but NOT zero'ed (like with most other file systems for performance reason).

If there is a snapshot for that file system then before a block gets re-used amd its necessary (corresponding file is part of a snapshot) then the "old" data is copied to the savvol bevor being overwritten.

uxfs does re-use of deleted block - but it might not be an immediate reuse.

It also depends on the application - if the app does change the block in the same file (as databases do)  we do an overwrite.

However other apps like to always create a new temp file, delete the old file and rename the temp file

Other apps (Word quick-save I think) just append any changes to the existing file.

see the Symmetrix space reclamation white paper for a discussion of different apps

http://powerlink.emc.com/km/live1/en_US/Offering_Technical/White_Paper/h6730-virtual-provisioning-space-reclamation-wp.pdf

uxfs is a file system with Unix heritage, fixed metadata and cylinder groups.

So even when you create an empty file system there are going to be used area's throughout the LUN.

AFAIK the unused empty data blocks we dont zero when creating a file system.

When creating a new file it depends on the free space in the cylinder groups if blocks are re-used or "new" blocks are used.

I dont think there is a preference there.

So for space reclamation I dont think you will see a benefit for thin LUNs.

The never written data blocks will already be not allocated.

Since space reclamation works by looking for block of zero's it wont reclaim blocks for deleted files (unless your or your app zero them before deleting)

Celerra deduplication works exactly as it would for non thin LUNs and doesnt benefit from space reclamation.

In order to compress a file will have to be written to a new space and the old blocks freed similar to a copy and delete type move.

As far as what happens if a pool runs out of space - you have to add disks before that happens.

There are mechanisms in place to warn you in advance before that happens.

Since LUN migration isnt supported with NAS LUNs (AVM tends to put file systems on multiple LUNs and mixing LUN "types" is not supported for NAS file systems)

If you are concerned about that and dont think you will be able to add disks in a timely fashion I suggest to use Celerra virtual provision with regular LUNs which avoids that scenario.

I wouldnt be astonished if you dont get much feedback on this, considering that Clariion VP is relatively new, used to be an extra cost license and Celerra thin provisioning does a good enough job for most Celerra customers NAS usage.

regards

Rainer