Reallocation questions

[#1]

Hi

I have a FAS3140 with an 8TB aggregate.

In one volume I have to delete a 2TB LUN. In this volume there are three more LUN's with a total size of 500GB.

So my question.
I think it is necessary to reallocate this volume. Is it?

Or it's the better way to reallocate all Vol's and the Aggr?

Can I start a reallocate during the day or are the perfomance issues are too heavy?

What's about the scheduled reallocation, is it recommended to configure it?
How often should the scheduled reallocation run? Once a week?

I'm looking for a documentation about the reallocation but I coundn't find something.

Thank's for your help

[#2 · Accepted solution]

Reallocation should only be used under the following conditions (ALL must be met).

1. Performance is degraded on a Volume, Share (CIFS / NFS), or LUN.
   
2. Deduplication is NOT turned on for the volume.
   
3. Snapshots are NOT configured for the volume.
   

Use the reallocate measure command to determine the fragmentation of the volume or LUN.  If the output shows that optimization level is higher then 5-6 then you can either manually run a reallocate against the volume/LUN or you can schedule a reallocation job outside of business hours.

In your case I would simply run a reallocate measure if you're curious to see what if any impact deleting the LUN will have.  Typically you don't have to reallocate LUNs in a volume simply because you deleted a LUN within a volume.

[#3]

Performance is degraded on a Volume, Share (CIFS / NFS), or LUN.

Define "performance" ...

Snapshots are NOT configured for the volume.

As usual with "universally true" statements, this is not necessarily true. The real answer is - it depends.

The point of reallocation is to increase sequential read efficiency. Sequential read is often (although not always) result of backup activity. Said backups are often (although not always) done by first snapshotting data and then reading snapshots.

If reallocation is planned in advanced and run regularily, impact on snapshot growth can be mitigated. Another consideration is physical reallocation which does not inflate snapshots. Yet another case is transient snapshots (which exist only to make backup).

[#4]

Thanks for your answers.

At the moment the performance isn't degraded. But LUN isn't deleted.
So I heard about reallocate and thought I have to do it.

But I will do first a reallocate measure after.

The deduplication is enabled on this Vol.
Do I get issues when I reallocate a deduplicated volume?

I haven't any snapshots on this volume.

Is there any diffrent between reallocate and physical reallocate?

thanks

[#5]

Hi,

The blanket statements about reallocation here aren't really helpful.

Now, I'm no big fan of having multiple LUN's per volume in the first place, unless they have largely the same content and there is some impending reason to deduplicate heavily.  The make a lot of other potential adjustments and operations a lot more difficult.

If you do have a situation where the remaining 3 LUN's are largely identical and the deduplication rate is quite high (I'd guess over 70%) then you probably could benefit from reallocation (the same is probably basically true with very low deduplication rates) because you are largely just lining up blocks that would normally be allocated closely anyway.

If these are database LUN's then you probably aren't going to see deduplication savings in the first place.... and deduplication might just be reaking havoc on your performance already...  Things like VDi or VMWare luns (system disk, static data) can give you better performance deduplicated with PAM cards...

Anyway, as always, YMMV...

[#6]

Reallocation is very unlikely to be useful if deduplication is enabled.

Standard reallocation moves blocks on flexvol level – old block versions are left in snapshots (if any) which results in snapshot size growth. Physical reallocation moves blocks on aggregate level and adjusts pointers in flexvol to new blocks. So from the flexvol point of view nothing changes and snapshot sizes do not increase. Downside is, your snapshots potentially become more fragmented, so if they are heavily used (trivial example is delayed backup verification in SME) it may cause performance impact as well.

Unfortunately it all is somewhere between art and black magic but nowhere near science ☺

[#7]

Hi,

Again, I don't think that this sort of blanket "dissing" of reallocation is helpful.

With very high or very low deduplication rates (would be nice for NetApp to actually setup some basic thresholds) reallocation will simply be moving contiguous blocks together that belong together.

If I had, for example, 50 VDI images deduplicated with a 90% savings (and I do in places) then reallocation is basically just moving the datablocks together... the pointers wouldn't matter for the most part.

If I have a "CIFS" volume with 10% deduplication and perhaps lots of pretty large files, then reallocation is probably going to help.

There is, admittedly, a large area where reallocation probably won't help a lot, but it would seem very plausible that for the low and high deduplication cases that reallocation should give the same performance increases as for the "un-"deduplicated volumes.

I, like many of us, would really welcome more research from NetApp on the when and where and why's for these two seemingly contradictory file system operations.

[#8]

Does this old post still stand?

Reallocation should not be run on deduped volumes or volumes with snapshots?

(which I would guess rules out 99% of all volumes for everyone?).

[#9]

Here's a link to the documentation covering why running a reallocation scan on a deduped volume is not recomended.

"A file reallocation scan using reallocate start or reallocate start -p does not rearrange blocks that are shared between files by deduplication on deduplicated volumes. Because a file reallocation scan does not predictably improve read performance when used on deduplicated volumes, it is best not to perform file reallocation on deduplicated volumes. If you want your files to benefit from a reallocation scan, store them on volumes that are not enabled for deduplication."

http://now.netapp.com/NOW/knowledge/docs/ontap/rel80/html/ontap/sysadmin/GUID-9447DB40-4537-4C4F-8C14-45BF8B0F40EF.html

The list that I put together is the ideal case but not the rule.

[#10]

Yeah, I've read that in the admin guide too.

So basically running it on a deduped vol is not recommended.

Running it on a vol with snapshots is OK if you are experiencing performance issues  - but you should try and limit the number of snapshots first.

So based on this theory, high sequential read access vols with a lot of data change (like that which occurs when Exchange runs a storage group defrag, or when we run an Exchange backup verify, or SQL backup verify) - these volumes should use reallocate with the -p switch?

(or would benefit from running a regular reallocate).

This whole investigation into reallocate all started with a question regarding Exchange online defrags & verifies, and the impact on the filer. Then someone pointed me in the direction of reallocate, and now it seems I've been missing an important maintenance procedure on my Exchange/SQL LUNs for many years! :-/ Oh dear.

So would I be correct in saying that for NetApp admins, running reallocate on LUNs should be part of the routine maintenance to ensure performance?

Thanks for the help!

Marc