On 04/23/2012 03:15 PM, Richard Rhodes wrote:

Hi Everyone,


Our concern is that the DD is a limited resource - how much
  disk it has.  If some node dumps a bunch of backups that
  don't dedup that could greatly effect the disk available.

Amen, brother.  Preach it!

A couple examples.
1) audio files - we have a node  that records audio which are kept for 2
years.  It currently has a TSM occupancy of 48tb.  we expected it wouldn't
be a good fit for a DD.  Sure enough, when I put some of it's backups onto
the DD I got almost no dedup/compression.
2) Notes mail backups - We use Notes for email.  It's our understanding
that the mail boxes are already compressed somehow by notes.  If you take
one and gz it, it doesn't shrink much.  We figured it was another bad fit
for the DD.  To our surprise, when I put part of the backups on the DD it
deduped at a 5x ratio.  It turns out this is a good fit for DD.

5x is a good deal?

I don't know how good you are at negotiating, but my DD disk is way more
than 5x as expensive as raw.

So.  After reading the replies by everyone, we are going to
collocate our DD file pool and I'm going to try and create a
report that will list our nodes, occupancy, DD disk, and a computed ratio.

Remember, you can do show compression down to the file level..


sysadmin@cns-prod-dd01# filesys show compression
/data/col1/remedy/prod/data/df_REMEDY_P_1002_1_779409006
Assuming default global compression is type 1.
Total files: 1;  bytes/storage_used: 3.9
       Original Bytes:        6,995,806,860
  Globally Compressed:        6,453,299,125
   Locally Compressed:        1,774,055,288
            Meta-data:           19,701,904

so that equates to the volume level if you use a collocated FILE devclass.



- Allen S. Rout