Re: Ex storage admin, here
Dear Regadpellagru,
blast from the past, for sure...
However there's far less danger in Symm than you may think.
The latest Symms (5 6 and 7) do offer the same level of control as the earlier Symm (3 and 4). That is not a bad thing, in itself. It allows you to give the best possible performance to the system that requires that level of performance. It also allows you to make sure that systems that do not need that level of performance are not in the way of delivering the performance to systems that need it. But one must understand how the machine works on a mechanical as well as logical level.
The bad thing comes, indeed, when people think they can outsmart a machine they do not fully understand. And that is where the pain comes in. Some Joe Local Admin may think they know what's going on, but the most important rule in storage, as you well know(!), is "It Depends...". Things one learned in one particular application of storage may not apply to some other system... Generalization of knowledge in storage is generally a bad thing, really... Remember the study I did with regards to LUN mapping and characterisation of storage through XP storage for that big DB system? Generalizations did not come into that study... Real understanding of how things were actually done was the only way to find perf issues....
Lastly, you couldn't blast away a LUN if it were mapped / masked or performs any other useful service. Only when a LUN/Device is not visible (mapped / masked) and does not have any relationships (R21, R2, BCV, RBCV, Meta Head or indeed Meta Member) to any other device will the Symmetrix allow you to delete/blast away the device. But there are ways around those problems, however those ways are far more involved than just
# symconfigure -sid <SID> commit -nop -v -cmd "delete dev <DEV>;"
Now, how is that most wonderful part of the world where we were colleagues? :)
Take care,
Guus
Biting the hand that feeds IT
