> -----Original Message----- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch > Sent: Friday, May 01, 2009 10:21 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Packing Methods > > The reason to turn off 3590E hardware compression, is if you > having problems "feeding the beast". You get faster backups > if you can keep the drive going. > > An IBM 3590E writes to tape at 14 MBs. If hardware > compression is turned on and you are getting 3:1 compression, > then you have to feed the controller at 3*14 or 42 MBs. If > you can, you have the best of both worlds, speed and amount > of data on a single tape. If you can't then you need to > choose speed vs high data storage. >
We have no problems "feeding the beast". We are writing to a remote SL3000 across the wire, a high speed wire to be sure, but one that is shared by other systems doing similar things. The network people have determined that our workload will not strain the capacity, and they appear to be correct. A backup of our larger VTAPE (VSSI version) library takes between 2.5 and 3 hours when the output is to local tape drives (Ficon connected) and only a few minutes more, less than 15, when writing to the remote site which is 1500 miles away. > Doing software compression, only makes sense to me if you are > going over slow (escon) channels. > > Given all that.... > > In DR tests, less tapes seems to be a good thing. With the current high-capacity, high-speed drives, the number of tapes is well under control. The VTAPE library backup mentioned above requires only a single tape to back a 26 (3390-03) volume library that typically runs 80% or more occupancy. > The DR site has better, faster, hardware then most of our shops. > (everything is ficon) You may buy less MIPS but you can't > buy less I/O thruput. > It takes more CPU to compress data then it takes to expand the data. > i.e. worry about your own MIPS. We have the same kind of h/w as the DR site. It is an LPAR carved out of a system at our second continental datacenter. We may on occasion, for a short while, have better equipment than it. The prudent path is usually to install the new hardware on the VM development system before implementing it on the production systems. We get the devices and processors before that are deemed acceptable as replacements for the hardware used by TPF. > > In general, I don't see the benefit in software compression, > when hardware compression is available. But if you tested > the difference in your site, and you have come to a software > compression conclusion, more power to you. Each site has a > different set of concerns. The original question had as much to do with is there anything to be gained using both types of compression because the defaults for both Hidro and the tape drives is to compress the data or, if not, which was likely to be better at doing the compression. It would appear that h/w alone is the answer. That is, it is if the SL3000 does the compaction prior to sending the data across the wire. > > Tom Duerbusch > THD Consulting > > > >>> Alain Benveniste <a.benveni...@free.fr> 4/30/2009 6:25 AM >>> > Richard, > > You have the same questions I had when I started to put in > place our DR solution. We also have 3590E drives and I never > tried to remove the hard drive default compaction. I don¹t > see a reason for that. Now choosing software compaction is a > must if you have enough cpu to do the work for backup and > ALSO for restore. For us we can spend more time to use > software compaction because we know that we have enough cpu > to do the work at restore time offsite. The gain at restore > justifies to take more time at backup processing. It¹s true > too that software compaction takes less tapes than with no compaction. > If you have many dasds to backup and a time constraint to > restore i would suggest you to both use hard and software > compactions. Our idea is to say that when we restore in a DR > test the cpu is used ONLY for restore. Why not fully using it ! > > Regards > Alain Benveniste > > Le 29/04/09 20:46, « Schuh, Richard » <rsc...@visa.com> a écrit : > > > We are working on a DR process. I notice that the defaults for a > Hidro backup > > include the PACK option which tells Hidro to pack, or condense in > some > > fashion, its output. The output is being written to 3590E drives. It > appears > > that there are three choices we can make for condensing the data: > software > > only, hardware only, or a combination of the two (uncompacted was > purposely > > omitted from the list). Which is likely to give the best results? > Does > > software compaction produce consistently lower output volumes than > letting the > > drive do it? Is there anything to be gained by using both h/w and > s/w? > > Obviously, software compaction costs in terms of cpu time. The > question is, is > > it worth the time spent? > > > > Regards, > > Richard Schuh > > > > > > > > >
