Hi
Apologies the below is quite geeky
We've recently had our sandpit 8450 upgraded to 3.3.1 and am playing with dedup and compression (aware of the recent advisory, this is sandpit data only).
One thing I've always liked about the 3PAR is that it doesn't hide anything. If you want to see something, there's commands to see exactly how things are laid out (unlike, say, EVA which even hid things like RSS layout!)
Anyway, when we started using AO many years ago, I was able to use a combination of showvvmap and showld to determine, for each VV, where data was located (in terms of tier). From this I could generate PNG's to see where data for a given volume resides, and watch it migrate over time, by knowing where each 128MB region lived. More for interest than useful from sysadmin perspective but you could visualise that data was moving up/down tiers even if the % in FC remained static for example.
What I'm now wanting to try and do is understand at a detailed level (again, more for interest rather than sysadmin usefulness) how a dedup volume is split into the shared area. In our case we have a LOT of copies of the same database (each database ~2TB) and much common data so we get very good dedup, which I'd like to visualise in a similar way to what I previously did with AO volumes.
A sample (truncated) showvv output on 3.3.1 gives: -
Code:
---------Snp---------- -------------Usr------------- --------------Total---------------
--(MiB)-- -(% VSize)-- -----(MiB)----- --(% VSize)-- --------------(MiB)--------------- ---Efficiency---
Id Name Prov Compr Dedup Type Rsvd Used Used Wrn Lim Rsvd Used Used Wrn Lim Rsvd Used HostWr VSize Compact Compress
178 .shared.raid5-3.1-new_0 dds NA No base 0 0 0.0 -- -- 2847744 2846253 4.2 -- -- 2847744 2846253 -- 67108864 -- --
179 xxxxxxxxxxxxxxxx-vgcompdedup1 tdvv Yes Yes base 0 0 0.0 -- -- 201472 170422 8.1 0 0 201472 170422 1843188 2097152 12.31 1.95
180 xxxxxxxxxxxxxxxx-vgcompdedup2 tdvv Yes Yes base 0 0 0.0 -- -- 91136 86500 4.1 0 0 91136 86500 1853617 2097152 24.24 1.66
181 xxxxxxxxxxxxxxxx-vgcompdedup3 tdvv Yes Yes base 0 0 0.0 -- -- 156800 116358 5.5 0 0 156800 116358 1832088 2097152 18.02 1.60
182 xxxxxxxxxxxxxxxx-vgcompdedup4 tdvv Yes Yes base 0 0 0.0 -- -- 94976 76922 3.7 0 0 94976 76922 1855617 2097152 >25 1.56
183 xxxxxxxxxxxxxxxx-vgcompdedup5 tdvv Yes Yes base 0 0 0.0 -- -- 311040 260600 12.4 0 0 311040 260600 1788455 2097152 8.05 2.10
We see the .shared which is the new style shared area (which was .sysvv in 3.2.2 I believe). If we look at HostWr for compdedup1 volume I see 1.8TB, and only 170GB written, so by extension around 1.6TB if this volume is in the shared VV, and represents dedup data. I'd like to delve into this and see how much of the data NEVER changes, versus how much changes depending on use case.
If you do showvvmap on this volume, you only see the mapping of volume-unique regions to LD's. Similarly if you do showvvmap on the .shared volume, you see what would be the shared regions in that volume. There's nothing that tied together in a linear fashion which bit of the volume is unique vs which is in the shared area. It would be good to overlay several DB's, and create a sort of "hotspot" image, which would actually be "coldspot" to show which bits never change.
From the commands I know it would appear that there's a lower-level data structure somewhere - just wondered if anyone knew of any commands to expose this, and had played at this level? Have we reached the limit of what is exposed? I wondered whether showblock might do something useful, but can't really make any sense of the output.