DMX Virtual Provisioning, like everything else has good + bad parts
I really like DMX VP (aka thin provisioning), it’s great in the automatic wide striping, overcommit, etc but at the same time there are a number of things you need to be aware of that will annoy you. VP is great in that I don’t really need to think (care) as much anymore, those iops are wonderfully spread across the backend… until I do and then ouch.
On the DMX you lose a resonable chunk of things you might be used to, optimizer is surely one of my old friends. I’ve been strugglilng a bit with performance, not because VP is slow but tracking things back to a source is such a massive pain in the ass. WLA don’t seem to know much about VP, so you now have an added layer of abstraction you have to find. SO if I’m beating a 48x of my SATA drives in a pool into submission at 100 wonderfully even spread iops per spindle… finding the guy who is doing it becomes a click nightmare. I’ve got close to 1500 tdevs attatched to that pool and I’ve got to go look at every single one of them (or at least select all of them) and they don’t all have to be nice contiguous numbers, some tdevs might belong to another pool so you’ve got to exclude them. Additionally there is no way to tell which one is nicely spread across all the drives in pool and which one has started doing random iops across concentrated to a subset of the pool… because someone had written out data when the pool was at 48 spindles rather than the 100+ it is now. So you see a subset of disks get hot in a pool, so who’s doing it? You have to map the 1500 tdev’s to the physicals and try to look for a peak/valley at the same time. I’m pretty sure I’ve got a “fix” for the unbalance in the new microcode (unfortunately not the who part)… Read more