Dinky are you talking about "symconfigure reserve" ??

i believe he is.

yes Stefano I am asking about "symconfigure reserve"

I would even like to know how help ful is it in an environment of 2 PB.

symmask commands should work, but symconfigure changes will fail (since you put the reserve on the volumes)


AFAIK the reserve prevents devices/luns from being mapped/unmapped. No impact on the content of the lun .. I think you are still able to use TF.


No IO impact is expected, AFAIK ...

Unfortunatly I can't play with that feature but think about it like a POST-IT that you can attach to your devices (or to lun addresses on the frontend) just like a reminder that the specific device/lun is still free but that you are simply waiting to change its configuration ASAP since you already decided how to use it ..

documentation says that you can manipulate devices (including symconfigure) that have been reserved as long as you specify device reservation id. Take a look at "Symmetrix Array Controls CLI" document

That's what reservation is used for ..

If you put the reserve (something like a lock) you have the key to open the lock ..

If you didn't put the lock, you can't mess up someone else's work

Kigare do you have an open SR with this issue ?? I feel it's pretty strange if you have to wait minutes instead of seconds...

Yes. It is closed now, and we were told that SE 6.5 was the answer.....

emc159215 <- this also mentions symcfg list -v, but the real problem was the masking.

The symcfg list -v was a completely separate issue, and came about because the developers changed the functionality of that command in SE 6.4
symcfg list -v was running extremely slow due to a change in SE 6.4 that now performs a sync every time on every frame. Run symcfg list -v -offline to get prior SE 6.4 results.

The crux of the problem had to do with the fact that we have multiple SE servers registered with the array. So it was having to check any reservations in SFS for each registered SE client. At least that is what I was told.

They are supposed to be working on the problem. With that being said, if you only have one SE server, you may not see a performance hit (on not much of one).

Yes, once it gets set, the problem exists.

There was an "undocumented" option, that we had to set to have it ignore anything to do with reservations.

6.5 will fix a lot of bad things .. Do you trust the output of "symmir" or "symrdf query -i interval" commands ?? Do you think that the measured speed and the ETA that both commands show in the output have some vague meaning ?? Let's wait 'till 6.5 is out.

As far as I can see even removing the reservation will not remove the problem.

There is also an OPT .. I'll try to have a look at the OPT .. however I think it's safe to say that RIGHT NOW (with S.E. 6.4) reservation is a little bit premature

ThX for your contri !!