Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!chinacat!chip From: chip@chinacat.unicom.com (Chip Rosenthal) Newsgroups: comp.unix.xenix.sco Subject: Re: SCO UNIX cpio allows no valid backup?! Message-ID: <1991May24.230518.18162@chinacat.unicom.com> Date: 24 May 91 23:05:18 GMT References: <1991May23.115825.47879@cc.usu.edu> <1067@dri500.dri.nl> Organization: Unicom Systems Development, Inc. Lines: 64 In article <1067@dri500.dri.nl> slootman@dri.nl (Paul Slootman) writes: >In article <1991May23.115825.47879@cc.usu.edu> sl3h7@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 | Don't play so Unicom Systems Development 512-482-8260 | loud, Mr. Collins.