Arnaud,

I too am seeing odd percentages where containerpools and dedup is
concerned.  I have a small remote server pair that protects ~23 TB of pre
dedup data, but my containerpools show an occupancy of ~10 TB, which
should be a data reduction of over 50%.  However, a q stg on the
containerpool only shows a data reduction ratio of 21%.  Of note, I use
client-side dedup on all the client nodes at this particular site and I
think that's mucking up the data reduction numbers on the containerpool.
The 21% figure seems to be the reduction AFTER client-side dedup, not the
total data reduction.

It's confusing.

On the plus side, I just put in the new 7.1.5 code at this site and the
compression is working well and does not appear to add a noticeable amount
 CPU cycles during ingest.  Since the install date on the 18th, I've
backed up around 1 TB pre-dedup and the compression savings are rated at
~400 GB, which is pretty impressive.  I'm going to do a test restore today
and see how it performs but so far so good.
__________________________
Matthew McGeary
Technical Specialist - Infrastructure
PotashCorp
T: (306) 933-8921
www.potashcorp.com




From:   PAC Brion Arnaud <arnaud.br...@panalpina.com>
To:     ADSM-L@VM.MARIST.EDU
Date:   03/22/2016 03:52 AM
Subject:        [ADSM-L] Deduplication questions, again
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU>



Hi All,

Another question in regards of TSM container based deduplicated pools ...

Are you experiencing the same behavior than this : using "q stg f=d"
targeting a deduped container based storage pool, I observe following
output :


q stg f=d

                    Storage Pool Name: CONT_STG
                    Storage Pool Type: Primary
                    Device Class Name:
                         Storage Type: DIRECTORY
                           Cloud Type:
                            Cloud URL:
                       Cloud Identity:
                       Cloud Location:
                   Estimated Capacity: 5,087 G
                   Space Trigger Util:
                             Pct Util: 55.8
                             Pct Migr:
                          Pct Logical: 100.0
                         High Mig Pct:

Skipped few lines ...

                           Compressed: No
                Deduplication Savings: 0 (0%)
                  Compression Savings: 0 (0%)
                    Total Space Saved: 0 (0%)
                       Auto-copy Mode:
Contains Data Deduplicated by Client?:
         Maximum Simultaneous Writers: No Limit
              Protection Storage Pool: CONT_STG
              Date of Last Protection: 03/22/16   05:00:27
         Deduplicate Requires Backup?:
                            Encrypted:
                   Space Utilized(MB):

Note the "deduplication savings" output ( 0 %)

However, using "q dedupstats" on the same stgpool, I get following output
: (just a snippet of it)

                Date/Time: 03/17/16   16:31:24
        Storage Pool Name: CONT_STG
                Node Name: CH1RS901
           Filespace Name: /
                     FSID: 3
                     Type: Bkup
  Total Saving Percentage: 78.11
Total Data Protected (MB): 170

                Date/Time: 03/17/16   16:31:24
        Storage Pool Name: CONT_STG
                Node Name: CH1RS901
           Filespace Name: /usr
                     FSID: 4
                     Type: Bkup
  Total Saving Percentage: 62.25
Total Data Protected (MB): 2,260

How does it come that on one side I witness dedup, but not on the other
one ?

Thanks for enlightenments !

Cheers.

Arnaud

Reply via email to