Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!ulysses!ggs From: ggs@ulysses.homer.nj.att.com (Griff Smith) Newsgroups: comp.unix.questions Subject: Re: backup with compressed cpio files ? Summary: a few misconceptions Message-ID: <11240@ulysses.homer.nj.att.com> Date: 19 Feb 89 21:13:53 GMT References: <9100001@netmuc> <872@deimos.cis.ksu.edu> <9667@smoke.BRL.MIL> <64@estinc.UUCP> Organization: AT&T Bell Laboratories, Murray Hill Lines: 35 In article <64@estinc.UUCP>, fnf@estinc.UUCP (Fred Fish) writes: > In article <9667@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: > > find . -depth -print | cpio -oc | compress | dd bs=5k > /dev/rmt0 > In order to ensure that dd writes 5K records I believe you have to > specify "ibs" and "obs" to be different sizes, to force an internal > buffer copy. Only true if you are using the dd in V9. It is only necessary that you use ibs and obs rather than bs; the sizes can be identical. > Substitute "ibs=1k obs=5k" for "bs=5K". Why? Unless you are working on a brain-damaged tape drive that can't write blocks larger than 5k, why not use large blocks to get more on the tape. 20K, maybe. You're going to read the tape with dd anyway, and cpio won't have trouble reading the pipeline from compress. Try "ibs=8k obs=20k". > Also note that the last buffer may not be a full 5k, which may confuse > a cpio that reads the tape directly. Cpio can't read the tape directly, it's compressed. > With compress, one read error and you're SOL as far as recovering the rest > of the data. Which is a good reason to forget the whole suggestion anyway. > -- > # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA > # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf -- Griff Smith AT&T (Bell Laboratories), Murray Hill Phone: 1-201-582-7736 UUCP: {most AT&T sites}!ulysses!ggs Internet: ggs@ulysses.att.com