Re: Why do Informix Products ship with TAR and not CPIO?

>Date: Tue, 20 May 1997 23:44:40 -0600 >From: Tim <thood29@idt.net> >X-Informix-List-Id: <list.14591> > >Greg McGregor wrote: >>Why does Informix TAR instead of CPIO? Are there any benefits from one to the other? > >Actually, of the Informix products I have installed in the past >(including from floppies), I have received both tar and cpio formatted >media. The choice depends primarily on which platform you are on, and secondarily on the version of the Informix software you are using. You're more likely to encounter cpio on recent software. >Indeed, more often than not (for the products I purchased/installed), I >received the product in cpio format. I imagine their choice is based more >on the platform/OS than any specific bias for/against tar or cpio. These days, the biggest factor is whether you can list all the files for the product on the command line or not. As someone else noted, tar is easier to use if you simply want to copy everything underneath some directory to tape. However, the way the Unix distribution phase works means that all the files for a number of products are copied to a work area, and then different subsets of these files are copied onto the tape image. To achieve that with tar, you have to list the files (but not the directories) one by one on the command line. Until the advent of GLS, you could usually get away with doing that. With the advent of GLS, the file lists have grown humongously long and it is no longer very sensible to try it -- it certainly isn't as portable as cpio with the -c option. By contrast, cpio reads its file list from its standard input, so it does not run into problems with the size of the argument list. So, nowadays, you will generally find that the software is released with cpio archives. As the same 'someone else' noted, it is important to use the -c option with cpio. In fact, I never use cpio without it. That allows my tapes to be read on pretty much any other machine. However, tape blocking is another issue. With 0.5 inch drives, it was critical to get the blocking factor specified correctly. The slowest operation I did with a tape was reading a half-inch tape. I'd written it with cpio (and no dd) on a machine with a clever controller that managed to hide the fact that the block size was 0.5 kB. Unfortunately, the machine I had to read it on didn't have the clever controller so the tape sat there for an hour or so, reading a 0.5 kB block, then stopping, swinging back and reading the next block. It was rather like watching a pendulum. The tape did rotate overall, but it was very slow (10 seconds per revolution). Only the fact that the machine with the clever controller was on the other side of Paris and it was rush hour stopped us from rewriting the tape. That is a mistake you make once. FWIW: tar defaults to a block size of 20 * 0.5 kB; cpio defaults to 1 * 0.5 kB unless you specify -B when it changes to 10 * 0.5 kB. I usually use dd to write to the tape in bigger chunks: cat filelist | cpio -ocvB | dd of=/dev/rmt/0 ibs=5k obs=64k With most cartridge tape drives, the blocking factor is not critical; pace the AIX crew for whom it can be a problem resolved by fiddling with the drive parameters via smit. On Xenix, tar used to default to a 1 * 0.5 kB block size, and then complain when it was writing to a floppy drive; you had to specify an even block size. I don't recall whether this afflicted SCO Unix or not, but I guess its been fixed. Otherwise, when writing to disk, block size is barely an issue. I use the B option, but I've never measured the difference. For all my own work when I'm not constrained by someone else, I use cpio. I've never had portability problems unless someone forgot to use the '-c' option. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>