SCO UNIX cpio allows no valid backup?!

[Chip Rosenthal]

In article <1067 at dri500.dri.nl> slootman at dri.nl (Paul Slootman) writes:
>In article <1991May23.115825.47879 at cc.usu.edu> sl3h7 at cc.usu.edu writes:
>>How to get standard cpio package that will verify multiple tape backup?
>get afio.

Agreed.  I decided to use afio for backups for two reasons:  it supports
multiple volumes nicely (which cpio did not do at the time) and it
screams.  Here are some results I published in my company's newsletter
about 9 months back:

       We benchmarked afio against all the standard XENIX archiving
       programs.  (We didn't benchmark the tar command because we
       think it's inappropriate for system backups:  it can't han-
       dle directories or special files and archives only regular
       files.)  Our benchmark was to perform a 13-megabyte backup.
       The results were as follows:

        command     bsize    bcount   underrun    time    user   system

        afio        5120      100         2       3:31     2.8    49.0
        afio        5120       50         6       3:26     2.9    49.2
        afio        1024      100         5       3:22     3.4    58.7
        cpio|dd     5120        1        29       4:29     1.6    18.0
        cpio -B     5120        1        31       4:32    10.5    42.0
        dump        n/a       n/a         2       3:23     3.1    48.0

        bsize      number of bytes per archive block
        bcount     number of blocks per device transfer
        underrun   times tape had to stop because no data was available
        time       real time required to perform the backup
        user       user time consumed by the process in seconds
        system     system time consumed by the process in seconds

The article points out that the user and system times for the `cpio|dd'
trial are bogus - only the first command in the pipeline is timed.
Also, this was done on a machine with only 2MB of memory.  A larger
machine could have handled bigger/more afio buffers, thus probably
providing even better results.

Even though the cpio shipped in XNX155B (and presumably 2.3.4) supports
multiple volumes, I've been so happy with afio that I've seen no reason
to switch.

The afio I use has two hacks.  First, there is a problem in the
distributed version that if your archive contains both a directory
and a file within that directory, if the file is restored first (e.g.
it is encountered in the archive before the directory), then the
directory permissions and ownerships aren't properly restored.  Glen
Hampton implemented a fix for this.  Second, I didn't like the way
the verbose option listed everything upon a restore - I only wanted
it to list the files actually restored off the archive.  I'd be glad
to send out these two patches upon request.  I've heard rumours of a
third problem along the lines of defining the media size something
other than an integral number of blocksizes causes problems with the
multiple-tape handling.  Dunno - haven't run into that here.

Now that I have the XENIX box on the network...I'll have to see how
well afio holds up for network backups!  BTW...I'm told (but wouldn't
swear to it) that `pax' took the guts of afio to implement its cpio
format.  That also might be worth looking into.

-- 
Chip Rosenthal     <chip at chinacat.Unicom.COM>  |  Don't play so
Unicom Systems Development      512-482-8260   |    loud, Mr. Collins.