Re: IBM announces Encrypting tape drives

Tom Schmidt wrote:

<Snip>

"Note: With encryption enabled, the access time to data on the tape drive will increase. Also, the tape drive unload time will increase. This is due to the time needed to retrieve, read, and write the encryption key."

It appears that there *is* a performance penalty, although hopefully not as severe as today (when the general processors have to do the work). Too bad that wasn't offloaded to zIIPs/zAAPs/zEEPs ("Enhanced Encryption Processor" - I just made that up) to generalize the support somehow.


Disclaimer: I am not an encryption or tape I/O expert (I don't even plan one on TV), and I did not stay at a Holiday Inn Express last night. But still...

Meeting today's strict truth-in-advertising requirements when we write announcement text sometimes gets in the way of the big picture, and I speculate that might have happened for this topic.

Of *course* there has to be a key sent to the drive to open an encrypted file for read or write. Of *course* it takes nonzero time to retrieve and send each key (for z/OS, since ICSF stores the keys, we probably have to wait for ICSF to do an I/O to the PKDS in addition to those needed to do the handshaking with the tape drive).

Some setup/teardown time was inevitable because there has to be some new key I/O unless we store all the keys in the drive itself and somehow teach it to select the right ones on its own (which we don't want to do for a variety of reasons).

But I think we have to put this into perspective. How long does a small disk I/O take these days? A few ms? Maybe a bit more for a cache miss? Add a couple of channel-to-controller transfers at perhaps a couple more ms. Compare this to the time it takes to mount a tape and position it to the first file...will you even notice (and could you even measure) the percentage overhead for the first file? Wouldn't it be smaller than the variation in tape mount and positioning time for an ATL? I would think the same goes for the unload time.

(Unless I'm missing something--which I'll admit is quite possible--I would not find it terribly surprising if it were smaller than the variation between load/unload/positioning times that exist due to manufacturing tolerances from one tape drive to the next.)

Having said that, I'm not sure what the delays might be for opening a large number of small encrypted files once you get past the first one because I've completely lost track of how the drives to buffering and tape positioning these days.

Also, note that while encryption work is already offloaded today to a card or a CPACF, it seems as though the CPU is busy while the encryption is being done. Offloading the CPU busy to a zAAP or zIIP (or to your new "zEEP") would solve the CP busy problem but introduce another--you'd have to buy at least one zAAP/zIIP/zEEP/whatever to benefit from the offload, and you'd have to buy enough of them to sustain the maximum aggregate data rate you needed to meet your requirements without using up any CP cycles to maximize that benefit.

While I don't know what the prices are, it seems possible (even probable) that for at least some (many? most?) applications the tape drives would be cheaper. Also, offloading to a specialty engine would not fix the data rate per CP/CPACF/etc. limitation; while I don't have the numbers handy, my understanding is that a bunch of tape drives can simply sustain a significantly higher data rate with compression and encryption.

This is why we think the z/OS-based Encryption Facility is best used for business partner data exchanges (which we think usually involves a small number of relatively small files) while encrypting drives are better for archiving (which we think usually involves a large number of large files).

--
John Eells
z/OS Technical Marketing
IBM Poughkeepsie
eells@xxxxxxxxxx

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to listserv@xxxxxxxxxxx with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
.

Relevant Pages

  • Re: Your worst project?
    ... CDC-MPI Keystone 92185 tape drives, ... Servo-to-go card and servos, or are you using steppers? ...
    (rec.crafts.metalworking)
  • Re: Backup stopped working after second tape drive installed
    ... Run services.msc, stop Removable Storage service. ... Microsoft Online Newsgroup Support ... Following is how drives are listed under device manager. ...
    (microsoft.public.windows.server.sbs)
  • Re: OT: Selling Used Computers
    ... Using a failure prone brand of device for backup! ... days watching tape drives stretch and break tapes. ... James and Super Freak cranked up -- "She's a very kinky girl, ...
    (alt.sys.pc-clone.dell)
  • Re: Backup Fails: "C: is not a valid drive or you do not have access"
    ... does not like their tape drives to be on the same SCSI controller as RAID ... Microsoft Corporation ... | On a SBS2k3 Premium backup was failing before due to an Exchange ...
    (microsoft.public.windows.server.sbs)
  • Re: external drive help
    ... | problem around with all the thumb drives and external drives available ... You can use encryption ... |>There is no absolute security method, ... If you photocopy a paper docuement then take it ...
    (comp.security.misc)