Agreed. AFAIK, the client-side dedup function is reliant on the dedup information in the storage pool where the data resides on the server. Which has to be a file pool, and deduped.
-----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Wednesday, June 22, 2011 7:01 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Deduplication and Collocation This is my understanding as well. I'm almost certain this is the case, though we have not yet used source dedup. ..Paul On Jun 22, 2011, at 3:34 AM, "Grigori Solonovitch" <grigori.solonovi...@ahliunited.com> wrote: > As far as I know client site de-duplication will not work with primary > storage pool DISK. It must be FILE as well like for server site > de-duplication. > Am I right? > > Grigori G. Solonovitch > > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf > Of Roger Deschner > Sent: Wednesday, June 22, 2011 9:37 AM > To: ADSM-L@VM.MARIST.EDU > Subject: Re: [ADSM-L] Deduplication and Collocation > > Back to client side dedupe, which we're about to deploy for a branch > campus 90 miles away in Rockford IL. > > The data is sent from the clients in Rockford via tin cans and string > to the TSM server in Chicago already dedpued. We're using source > dedupe because the network bandwidth is somewhat limited. So if it is > received into a DEVCLASS DISK stgpool, then I assume it is still > deduped, because that's how it arrived. Then finally when it's > migrated to tape, we've already established that it gets reinflated, > and then you can collocate or not as you wish. > > But the question is, does this imply that deduped data CAN exist in > random access DEVCLASS DISK stgpools if client-side dedupe is being > used? I sure hope so, because that's what we're planning to do. > > Roger Deschner University of Illinois at Chicago rog...@uic.edu > ========== "You will finish your project ahead of schedule." > =========== ================= (Best fortune-cookie fortune ever.) > ================== > > > On Tue, 21 Jun 2011, Paul Zarnowski wrote: > >> Even if a FILE devclass has dedup turned on, when the data is migrated, >> reclaimed, or backed up (backup stgpool) to tape, then the files are >> reconstructed from their pieces. >> >> You cannot dedup on DISK stgpools. >> DISK implies "random access disk" - e.g., devclass DISK. >> FILE implies "serial access disk - e.g., devclass FILE. >> >> But I think there is still an open question about collocation and >> deduplication. Deduplication must be done using FILE stgpools, but FILE >> stgpools CAN use collocation. I don't know what happens in this case. >> >> ..Paul >> >> At 02:38 PM 6/21/2011, Prather, Wanda wrote: >>> If it is a file device class with dedup turned off, yes. >>> >>> -----Original Message----- >>> From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On >>> Behalf Of Mark Mooney >>> Sent: Tuesday, June 21, 2011 2:29 PM >>> To: ADSM-L@VM.MARIST.EDU >>> Subject: Re: [ADSM-L] Deduplication and Collocation >>> >>> So data is deduplicated in a disk storage pool but when it is written to >>> tape the entire reconstructed file is written out? Is this the same for >>> file device classes? >>> >> >> >> -- >> Paul Zarnowski Ph: 607-255-4757 >> Manager, Storage Services Fx: 607-255-8521 >> 719 Rhodes Hall, Ithaca, NY 14853-3801 Em: p...@cornell.edu >> > > > Please consider the environment before printing this Email. > > CONFIDENTIALITY AND WAIVER: The information contained in this electronic mail > message and any attachments hereto may be legally privileged and > confidential. The information is intended only for the recipient(s) named in > this message. If you are not the intended recipient you are notified that any > use, disclosure, copying or distribution is prohibited. If you have received > this in error please contact the sender and delete this message and any > attachments from your computer system. We do not guarantee that this message > or any attachment to it is secure or free from errors, computer viruses or > other conditions that may damage or interfere with data, hardware or software.