HPE Storage Users Group

A Storage Administrator Community




Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: showvvmap etc with dedup/compressed volumes
PostPosted: Wed Sep 20, 2017 6:59 am 

Joined: Thu Jul 10, 2014 10:42 am
Posts: 5
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 


Who is online

Users browsing this forum: Google [Bot] and 47 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group | DVGFX2 by: Matt