Hi Eric, With Quantum DXi (VTL) can you do the same thing. The DXi has both a VTL part and a NAS Disk part and both have De-Dup working. The NAS part can you connect as local disk via iSCSI.
But how good iSCSI is for DISKPOOL do I don't know. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson ________________________________________ Från: ADSM: Dist Stor Manager [ads...@vm.marist.edu] för Loon, EJ van - SPLXM [eric-van.l...@klm.com] Skickat: den 22 september 2009 16:16 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: the purpose of "file" device class Hi! Before they were taken over by EMC, some guys from DataDomain were visiting us a few months ago. They presented their DD boxes, which offer hardware based dedup, compression and defragmentation. They told us about customers who allocate a DISK (not FILE!) storage pool in a DD box and just leave the data there in one huge diskpool. Because the box does his own backend fragmentation, the front-end fragmentation is just virtual and thus does not impact TSM performance. It does sound too good to be true. No migration, no reclamation, no dedup on you server, only backup stgpool! Or write to two primary pools simultaneously, so you don't need to do the copy storagepool either!!!! Well, since the product is now owned and supported by EMC, I'm a little bit hesitant... Kind regards, Eric van Loon -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Christian Svensson Sent: dinsdag 22 september 2009 14:46 To: ADSM-L@VM.MARIST.EDU Subject: SV: the purpose of "file" device class Hi Rick, What do you wanna know about VTL? If you looking at Quantum or EMC (Who is OEM parts of Quantum VTL and FalconStor) is basically a Linux OS and running Quantums own Filesystem called NextFS or something like that, if I don't remember wrong. NextFS is a great file system if you have large files such VTL or Media Streaming files. The only reason why I should sale a customer a VTL is if they wanna run a LANFree backup to disk. But because you normally get better performance with a LTO-4 drive then disk, if you are streaming large files. If they wanna run a backup of multiple small files over SAN then sure why not run a VTL. Another reason that is good with VTL is to move over the CPU usage from the TSM Server to another hardware. So the TSM Server can focus on Backup/Restore/Reclamation/Migration and the stuff it is good on. But to just buy a VTL because it is a VTL. No I don't see any point with it from a TSM perspective. I should instead invest on a Large Disk e.g IBM DSxx00 System and use a fast index based filesystem such EXT4, TUX3 or BtrFS. And spend time to create the FILE volumes so I don't get any fragmentation. Best Regards Christian Svensson Cell: +46-70-325 1577 E-mail: christian.svens...@cristie.se Skype: cristie.christian.svensson ________________________________________ Från: ADSM: Dist Stor Manager [ads...@vm.marist.edu] för Richard Rhodes [rrho...@firstenergycorp.com] Skickat: den 22 september 2009 13:40 Till: ADSM-L@VM.MARIST.EDU Ämne: Re: the purpose of "file" device class "ADSM: Dist Stor > Hi TSM-ers! > At this moment we are using a diskpool with a VTS-like (DL4106 by EMC) > storage pool as nextpool. > I too am looking at a FILE pool to replace this in the future, just to > prevent a vendor lock-in for our TSM environment and of course the > possibility to use de-dup. > The only problem I see for using large FILE (100 Tb +) pools is the size > of the filesystems on the host running the TSM server. Now it's AIX, but > in the future we are likely to migrate to Linux. It would be interesting to know if the VTL vendors (which are basically implementing FILE type volumes inside the VTL) use a filesystem, raw logical vlumes, raw disk . . . or whatever. > Does anyone have experience with 100+ Tb FILE storagepools? > Thanks for any reply in advance! We keep looking at big pool of FILE devices vs VTL for our next big purchase down the road - whether for the initial pool where backups go directly, or are later migrated to. We keep hitting our heads against a wall in trying to come up with a way to make widespread use of a BIG FILE device pool: - dedup: IBM has solved this one with v6.1!!! - compression: To replace tape drive compression we need TSM server side compression (or should I say FILE device pool compression). We can't just push the job onto the clients. VTL's support hdwr compression via compression cards. I wonder if IBM will ever support server side hdwr compression via add-on cards for FILE devices (http://www.aha.com). - lanfree: Provide good lanfree with FILE devices that is not Sanergy. We've got a couple years yet on our tape systms, but as of today, we really don't see much way to effectively implement a large scale FILE pool to replace our current TAPE drives. FILE pools may be IBM strategic direction for TSM, but I think they have a lot more work to make it a true reality. Rick ----------------------------------------- The information contained in this message is intended only for the personal and confidential use of the recipient(s) named above. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately, and delete the original message. ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 **********************************************************************