> I wasn't really talking about the latency, but of the overhead of > breaking data down and put it in packets, with header info, etc, > transmitting thru/to another process which reads the header, > reconstruct > the data just to turn around it write it to tape. > > Right? Write to tape is still faster than to transmit to another > process to write to the same tape?
Natively, I'd agree. Given the amount of stuff that has to be done to get tape to work properly on Linux, I'm not so sure this is still true in the end when all is said & done. Linux is a lot better optimized to talk to the network than tape. > I currently have a process for the last few years, that effectively > attach/detach large pools of disk space between Linux images. > For some > things, I just need scratch disk space, for other things, my RPM > repository. So this has never been a big deal. It is here. If you've got a significant number of clients tossing data at you in a backup scenario, you *will* overrun the transfer rate of any tape drive with any significant chunks of data. Spooling to temporary disk is a Good Thing in this environment. > Still communications. But I do see the point. I'm on z/VM 4.2 so I > have guest lan support, but not all the features that are on > later releases. This is basic gLAN function; nothing special. Direct analogue to putting another private network segment together and shipping the backup traffic only over that segment. > Bad part about this, is the IBM Business Partners seem to > only talk TSM > when trying to sell z/890s and z/Linux. So sometimes they > can steer the > extra hardware as being just a given. So, you pay the BP to steer to > FCP, instead of paying developers to provide for channel attached tape > drives. Except you get an interesting catch-22: if you buy SCSI drives to use with TSM, you can't use them with DDR or SPXTAPE. If you buy channel-attached drives to use with DDR (or SPXTAPE), you can't use them with TSM. Oops. (in the classic Peter Sellers sense). It would be really helpful if IBM got emulated 3420/3480 support for SCSI drives working. It really puzzles me why this isn't clearly a direction they should go. It breaks the least amount of stuff in either world and you'd have the advantage of finally having decent TMS systems in the SCSI tape world (ReelLibrarian is pretty weak compared to VM:Tape or even RMS, and it's the best of a really rotten lot); it's not like IBM hasn't done it before with AWS34XX on the P390 and MPxxxx boxen, and it'd be really, really nice to not have this dichotomy of worlds. Would also be the quickest route to letting z/OS use those SCSI tape drives while we wait for the rewrite of the z/OS I/O handling. I really don't care if emulated tape is slower than the channel-attached drives -- 200G per volume makes up for a lot of slowness, especially if you can share those AIO-2 drives with other systems (and use their budget to pay for part of the silos). -- db ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
