Once I hit apply, SN asked me if I wanted to use quick format, which is sort of a stupid question to ask for two reasons. The first reason this is a stupid question is who wants to use the slow option?? "When someone asks you if you’re a god, you say YES!" right? Anyway, I said "YES"…
I had forgotten the system disk requirement for quick format on the USP-V, which is exactly the second reason the above dialog box is a stupid question, since the array should know full well the system disk requirements are not met.
Anyway, after saying, "Yes, I want to apply these changes" SN put up a dialog box suggesting the format was proceeding.
This of course was total baloney because not too long after this it says the formats failed:
At this point, I was pining about all my wasted time I spent defining the new LDEVs. I thought to myself, "I should’ve been honest and said I wasn’t a god." But as it turns out, SN did actually define my LDEVs, but they were blockaded.
During the process of defining the new LDEVs I realized I was going to have to volume-to-space (V2S) one more LDEV in order to assign it a lower CU:LDEV number so it could be used as the head volume of a LUSE (LUSE requires all sub-volumes to be added in numerical order). I figured since my formats failed, I would V2S the LDEV, redefine it, and then format everything all at once.
So I hit Apply on the V2S operation, locked my computer screen and stepped away momentarily, expecting the operation to be completed by the time I got back. Only, when I got back I saw Storage Navigator reporting that the sky was falling:
Had I been more prescient in the moment, I would’ve considered the blocked LDEVs as the most likely culprit. But I had actually just told my wife, "I’ve got one more thing I want to do so I don’t have to do it Monday… shouldn’t take long at all." Haha. Thank you Mr. Murphy.
Turns out my failed formats prevented the V2S operation because the LDEVs were blockaded. Completing the formats first allowed me to proceed with the V2S operation.
