Archive Tapes

[seckin at sumac.hf.intel.com.ogi.edu]

In article <1990May4.224058.4271 at eci386.uucp> clewis at eci386.UUCP (Chris Lewis) writes:
>I've yet to see a version of cpio that doesn't "handle" end of media...  

Same here.  I routinely do multi-volume tape backups on my system,
an Intel 386 AT running UNIX V/386 Release 3.2 Version 2.1.

>The problem is that cpio considers *any* read or write error to 
>be end of tape and prompts for the next tape. ...

cpio handles ENOSPC, "end of media" for tapes.  The tape driver has to
handle "end of media" correctly, that is it should stop writing data,
write a file mark, and return the correct residual count and the correct
error number (ENOSPC).  For i/o errors the driver should report EIO, etc.

>I wish that there was an end of media errno.  (Though some tape drivers
>apparently do something slightly different on EOM versus true errors)
 
There is, ENOSPC.  Standard System V/386 tape drivers handle end-of-tape
properly, so multi-volume archives are good.  Just use cpio!

Also, note that cpio tries to allocate 10 buffers of specified size.  For
example "cpio -oB .." tries to allocate 10*5K, will issue 50K i/o requests
with a n*5K final write.  Using "cpio -oC 1024000 .." the cpio will try
to allocate 10MB of memory, and it will succeed grabbing that much virtual
memory, but you might end up paging/swapping a lot.  Also again, the cpio
buffer is contiguous in virtual memory, but the tape controller deals with
real addresses, so the VM/driver usually end up issuing the i/o requests
in chunks of 4K (pagesize).  If the hardware/software is fast enough, and
the tape controller/drive can handle a little delay, the tape streams.

>Chris Lewis, Elegant Communications Inc, {uunet!attcan,utzoo}!lsuc!eci386!clewis
>Ferret mailing list: eci386!ferret-list, psroff mailing list: eci386!psroff-list

Seckin Unlu                     seckin at littlei.intel.com
Software Engineer               uunet!littlei!seckin
Intel Corporation               [Only my personal opinions]