Problem Adding Volume to Replication Group: Zero_detect Disabled?

[L1nklight]

I am trying to add a volume to a remote copy group. This is an activity I've done quite often in the last few weeks successfully. In order to add the volume, I must create the target volume on the destination 3PAR. When I go to do this, I am getting an error message that states "Error: Conflict between policies zero_detect and no_zero_detect." To me this seems to indicate that some how, zero_detect got turned off on one of my 3PARs cpgs during the upgrade to 3.2.1 MU2 as I was able to add volumes to remote copy groups and create their destination volumes.

A couple questions:

1. How do I view the status of zero_detect on the cpgs/volumes? I can see how I can create a cpg/volume with zero detect however I don't see a way to view the status of zero_detect per cpg/volume. Also, I am not even sure this is a legit error as turning off zero_detect seems like a pretty big deal for a cpg/volume.
2. If I can figure out which cpg/volume (default SSD_r5 cpg) has zero_detect disabled, whether it's the local or remote 3PAR system, how would I go about re-enabling it?
3. What are the ramifications of re-enabling zero_detect after it has been disabled?

I have opened a ticket with 3PAR support on this, but I was looking for a bit more of an immediate response or maybe someway I can help myself.

[Sheldon Smith]

Remember that everything can be done from the CLI. When in doubt, the command line is your friend.

Zero_detect is a characteristic of a virtual volume, not a CPG. As zero_detect is one of the policies, try

showvv -pol [<VV_name|pattern|VV_set> ...]

There is no problem turning zero_detect on for a volume:

setvv -pol zero_detect <VV_name|pattern>...

Note: While I work for HP, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! "White Star" !

[Sheldon Smith]

Granted, there's a learning curve with the command line. However, the 3PAR commands are quite consistent and you will quickly see the patterns to how the commands are organized.
In addition, as you perform functions with the GUI, you can look in the recent Events to see the corresponding commands executed by the GUI. (Do something in the GUI, look at the events of the last few minutes.)

Personally, I have PuTTY installed on my desktop and in my path so that I can easily connect to an array from the Run dialog box. Something like "putty 3paradm@10.11.12.13".

[L1nklight]

I actually just found those commands as well (I am not unfamiliar with the CLI). As I am looking through my volumes and there are a lot of them, some of them have zero_detect enabled but most of them have no_zero_detect enabled. In my mind, I think I'd want zero_detect enabled globally but as I am reading through the 3.1.2 CLI document I have (which I am not sure if it's relevant for 3.2.1 MU2) I have found this piece of information:

"Thin Persistence can have some performance implications during extremely busy system conditions. HP recommends the zero_detect policy only be enabled during Thin Persistence and Thin Conversion operations. The zero_detect policy should be disabled during normal operation. "

For the record, I am running 7450s in both locations. What should I be running them as (zero_detect or no_zero_detect)?

[Sheldon Smith]

DEFINITELY zero_detect!

While older arrays sometimes had "performance implications", I have not heard of any with either the 7xxx or 10xxx. Zero detect is handled by the ASIC. I am not aware of any customers that are toggling zero_detect.

I think you can do a blanket enable:

setvv -pol zero_detect <vvname|pattern>...

[L1nklight]

What about if the volumes are in a remote copy group? I imagine you'd have to do something like the following:

1. Stop All Remote Copy Activities
2. Enable zero_detect on source
3. Enable zero_detect on destination
4. Start All Remote Copy Activities

Will there be any sort of huge replication deluge to worry about?

[Sheldon Smith]

As far as I know, there is no need to stop Remote Copy. Zero_detect can be enabled on a volume at any time. And you would need to enable zero detect on both the primary and the secondary volumes.

And as far as Remote Copy, anytime you need to stop a group, wait until the volumes are "sync"ed. When stopped, snapshots will be automatically created on each primary volume, then when the group is restarted, the volumes will use the snapshots to get caught up.

[L1nklight]

Hey sorry for the late reply. After I was looking through the configuration guide I found this line:

NOTE: Thin persistence can have some performance implications during extremely busy system

conditions. HP recommends the zero_detect policy only be enabled during Thin Persistence

and Thin Conversion operations. The zero_detect policy should be disabled during normal

operation.

Seems to suggest that the zero_detect option should be turned off by default. Is this correct?

[Sheldon Smith]

No. Go back and read Message 5 of 8.

And what document are you reading?

[L1nklight]

Re-read 5 of 8. Here's the output:

3PAR7450 cli% showvv -pol Volume_Name
  Id Name               ---------------------Policies----------------------
1781 Volume_Name stale_ss,no_system,no_one_host,cache,no_zero_detect
---------------------------------------------------------------------------
   1 total
3PAR7450 cli% setvv -pol zero_detect Volume_Name
Error: VV Volume_Name is a TDVV and thus cannot have zero_detect policy enabled
3PAR7450 cli%

Document is titled: HP 3PAR Command Line Interface Administrator's Manual HP 3PAR OS 3.1.2. Page 86 about midway down.

Also found on document titled: HP 3PAR Command Line Interface Reference HP 3PAR OS 3.2.1. Page 336 a little more than midway down under the setvv command flags.

[Sheldon Smith]

<grumble grumble mutter mutter>

This is an old recommendation from back in the T and F days.

It is not a problem with any of the StoreServ generation.

I have been applying boots to the head to start getting documentation updated.

Turn zero_detect on.

[L1nklight]

Any input on that error message I recieved when trying to enable zero_detect on the tdvv?

3PAR7450 cli% setvv -pol zero_detect Volume_Name
Error: VV Volume_Name is a TDVV and thus cannot have zero_detect policy enabled
3PAR7450 cli%

[Sheldon Smith]

TDVVs do zero detect in a different way. All zero pages will dedup to a single page so there’s no need to have the extra zero detection of TPVVs.

If you try to set zero_detect on a TDVV you will get an error.

So:

TPVV, policy zero_detect yes

TDVV, policy zero_detect no

Note: While I work for HP, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! "White Star" !

[L1nklight]

That makes sense! Thanks so much. It very strange though. I've tested it and if you create a TDVV volume through the GUI it will be set to zero_detect. The volumes in question that have no_zero_detect I created via a script without the zero_detect argument. I have all TDVV volumes so essentially what you see when you look at the volumes is a mix of tdvv volumes with zero_detect and no_zero_detect.

Thanks for your answer. I appreciate your help!

[Dennis Handly]

> if you create a TDVV volume through the GUI it will be set to zero_detect.

It might be due to the difference in checking between createvv and setvv.

[Sheldon Smith]

Suggest you download the latest Management Console (MC 4.6.2) as well as the new StoreServ Management Console (SSMC 2.0).

Both are available today at the HP Software Depot:

https://h20392.www2.hp.com/portal/swdepot/displayProductsList.do?category=3PAR

[L1nklight]

Already done! I was on the closed release for the GA. The create volume operation went perfectly and there were no issues. So far I really like the SSMC and it seems to bring HP more in line with its competitors as far as look and feel (Pure and Xtreme I/O).

The volume has been created and no_zero_detect was the default on the tdvv volume. It must be something with the way the volume is created in the GUI or in the GUI for 3.2.1 MU1 vs. changing an attribute on the policy after creation.

All of the tdvv volumes I created using the java based GUI on version 3.2.1 MU1 seemed to have been created with zero_detect enabled. All the volumes I created using the CLI for version 3.2.1 MU1 seemed to have been created wtih no_zero_detect enabled which appears to be a CLI default setting. Under version 3.2.1 MU2 the volume I created using the SSMC v2.0 was created with no_zero_detect.

As a test I went ahead and ran setvv to change the policy on one of my tdvvs from zero_detect to no_zero_detect and then tried to move it back to zero_detect. As expected, the system wouldn't let me change it back to zero_detect. This was as discussed on this thread.

Thanks for your help.

[NicholasSullo]

I'm a little confused.  All my TDVVs are no_zero_detect and this is normal right?  If so, why did it sometimes put yours as zero_detect with a different client if it's something that's not needed?  Is this something I should be worried about because I'm doing some VMWARE vMotions of some of my disks and they seem to be taking quite long as if they aren't detecting zeros?

[Dennis Handly]

>if it's something that's not needed?

I wouldn't worry.  Both the zero-detect and de-dup code use the ASIC hardware, so de-dup is a superset of zero-detect.