Path: utzoo!attcan!uunet!auspex!guy From: guy@auspex.auspex.com (Guy Harris) Newsgroups: comp.unix.questions Subject: Re: saving directories when they don't fit on 1 tape Keywords: multi-volume tar, archive, cpio Message-ID: <2521@auspex.auspex.com> Date: 30 Sep 89 18:51:51 GMT References: <1454@mdbs.UUCP> <1466@xyzzy.UUCP> Reply-To: guy@auspex.auspex.com (Guy Harris) Organization: Auspex Systems, Santa Clara Lines: 37 >Use cpio. First, there are some cpio's which support spreading >tape files across several tapes. Ours does, I'm confident; check >your cpio's man page to make sure. But I don't think vanilla >System V's do (or are required to by AT&T), and SunOS 4.0's cpio >man page says it doesn't. Note that the S5 "cpio"s support for multi-volume archives depends on the tape driver handling the end-of-medium condition by returning a short count or one of a couple of errors, *and* doing so on both reads and writes. I don't know that the Sun SCSI tape driver does either; it runs the tape in buffered mode, presumably in the hope of getting streaming tapes to stream, and unfortunately that makes it somewhat hard to handle the end-of-medium condition - there may be several blocks in the tape drive's buffer that haven't been written to tape, and they'd have to be retrieved using the proper SCSI command and written to the next tape. Unfortunately, the "obvious" trick of doing this in the driver, invisibly, could cause problems if you e.g. decide to punt and try a bigger or higher-density tape instead of continuing to the next volume; there'd need to be some way for the driver to know whether to write the buffered data when the next tape is mounted or to discard it, and to in fact know when the next tape is ready to be written on. "cpio" and "tar" don't currently do anything to give explicit indications, so you'd have to rely on opens and closes and the like, and hope that the "mount next volume and keep going" case really *is* distinguishable from the "punt and get a bigger tape" case by the driver, or that you can live with the results if it isn't. Also, I think the Sun driver may not report end-of-medium conditions on "read". UNIX drivers tend not to do so.... The strategy you suggest is a bit safer here, since you manually break up the operation, rather than letting the tape drive do so with end-of-medium indications. The V7/S3 and BSD "dump" programs use a similar strategy - you tell them how much tape there is, and some other information, and they figure out how many blocks will fit on the volume.