aab@cichlid.com (Andrew A. Burgess) (08/02/90)
In article <75@towers.UUCP> robert@towers.UUCP (Robert Hoquim) writes: >gary@mic.UUCP (Gary Lewin) writes: ... >If I had any complaint >it would be the inability of any SCSI tape drive to do multiple tape >backups. (ie. file systems larger than 150 megs in a single CPIO pass >without breaking things down into subdirectories on that file system.) > >So I should ask this question: > > Has anyone figured a way with a SCSI tape drive (Archive or Wangtek) >to do multiple tape backups with CPIO? Say a file system that is 300 megs >that would take 2 tapes with cpio asking for another tape like it did with >the older Non-SCSI Wangtek tape drives (60 megs). There just doesn't seem >to be any report from the driver to CPIO that the end of the medium has been >reached and just hangs. > I use SCO UNIX 3.2 and on this system the way this works is that cpio simply counts the bytes and then prompts you for a new tape when the count reaches the tape size (the tape size is explicitly set by parameters to cpio). No end of tape indication from the tape is required. If ISC does not work this way you should be able to insert a program into the pipeline (between cpio and the tape) that does this counting and prompts you to change tapes. Similarly when restoring, cpio wouldn't know the difference. Anyone see any problems with this? Andy -- Andy Burgess Consulting Software Engineer uunet!cichlid!aab or uunet!silma!aab aab@cichlid.com
jgd@rsiatl.UUCP (John G. DeArmond) (08/03/90)
aab@cichlid.com (Andrew A. Burgess) writes: >I use SCO UNIX 3.2 and on this system the way this works is that cpio >simply counts the bytes and then prompts you for a new tape when the >count reaches the tape size (the tape size is explicitly set by parameters >to cpio). No end of tape indication from the tape is required. >If ISC does not work this way you should be able to insert >a program into the pipeline (between cpio and the tape) that does this counting >and prompts you to change tapes. Similarly when restoring, cpio wouldn't >know the difference. >Anyone see any problems with this? >Andy Yeah, it's way too complicated. KISS. :-) Cpio is SUPPOSED to detect end of file and prompt you for a new tape. Says so right in TFM. At least under ISC 2.0.2 and 2.2, it does not work. (experience with 4 systems so far in that regard.) The final solution is to get a copy of AFIO - available from comp.unix.sources archives or I'll even mail copies as long as the requests don't get too heavy). This is a PD replacement for cpio that adds a number of new enhancements. One of these is the ability to specify the size of each device with a command line option. I've added some enhancements such as the ability to specify different devices when prompted for the next "tape". This allows one to recover gracefully when, for example, a backup fails in the middle of the 5th tape. (just restart and send the output to /dev/null and specify the tape drive when it prompts for the 5th tape.) Another benefit is that it is several times faster than cpio. Afio has a few warts but it is vastly better than the stock cpio. Highly recommended. John -- John De Armond, WD4OQC | We can no more blame our loss of freedom on congress Radiation Systems, Inc. | than we can prostitution on pimps. Both simply Atlanta, Ga | provide broker services for their customers. {emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA**
debra@alice.UUCP (Paul De Bra) (08/04/90)
In article <3465@rsiatl.UUCP> jgd@rsiatl.UUCP (John G. DeArmond) writes: >aab@cichlid.com (Andrew A. Burgess) writes: > >>I use SCO UNIX 3.2 and on this system the way this works is that cpio >>simply counts the bytes and then prompts you for a new tape when the >>count reaches the tape size (the tape size is explicitly set by parameters >>to cpio). No end of tape indication from the tape is required. >... >Yeah, it's way too complicated. KISS. :-) Cpio is SUPPOSED to detect end >of file and prompt you for a new tape. Says so right in TFM. At least >under ISC 2.0.2 and 2.2, it does not work. (experience with 4 systems so >far in that regard.) It does work with stock AT&T sVr3.2 and the stock cpio, and the prompt for a new tape is really based on the system detecting the end of the tape. You do have to use the -O option for write and -I for read though. find . -print | cpio -ocB -C131072 -O/dev/rmt/c0s0 does backup everything under . (using a large buffer) and prompts for a new tape at the end. find . -print | cpio -ocB -C131072 > /dev/rmt/c0s0 just gives an error when reaching the end of the tape. (similarly for reading: -I works, stdin redirection does not) Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (08/07/90)
In article <11134@alice.UUCP> debra@alice.UUCP () writes: | It does work with stock AT&T sVr3.2 and the stock cpio, and the prompt for | a new tape is really based on the system detecting the end of the tape. | You do have to use the -O option for write and -I for read though. | | find . -print | cpio -ocB -C131072 -O/dev/rmt/c0s0 | | does backup everything under . (using a large buffer) and prompts for a new | tape at the end. | | find . -print | cpio -ocB -C131072 > /dev/rmt/c0s0 | | just gives an error when reaching the end of the tape. | (similarly for reading: -I works, stdin redirection does not) Alternatively if you don't have this feature, want double buffering, or like the prompt to include the volume number of the media to mount, you can use the bundle software posted to comp.sources.unix last year. A new version is in the queue. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
pim@cti-software.nl (Pim Zandbergen) (08/22/90)
>>Yeah, it's way too complicated. KISS. :-) Cpio is SUPPOSED to detect end >>of file and prompt you for a new tape. Says so right in TFM. At least >>under ISC 2.0.2 and 2.2, it does not work. (experience with 4 systems so >>far in that regard.) >It does work with stock AT&T sVr3.2 and the stock cpio, and the prompt for >a new tape is really based on the system detecting the end of the tape. >You do have to use the -O option for write and -I for read though. This really depends on the device driver. cpio expects the device driver to fail the write() with errno == ENXIO (no such device or address) on end of medium. With ISC, the Wangtek driver will give this error, but the SCSI tape driver will not send any write failure, it will just hang when it reaches the end of the tape. So even pax, which will query you for a new medium for *every* write failure, will not properly work. I use a modified afio, which will recognize ENXIO for "normal" devices and uses the byte count method for the SCSI tape. -- Pim Zandbergen domain : pim@cti-software.nl CTI Software BV uucp : uunet!mcsun!hp4nl!ctisbv!pim Laan Copes van Cattenburch 70 phone : +31 70 3542302 2585 GD The Hague, The Netherlands fax : +31 70 3512837
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (08/23/90)
There is a program called bundle which I posted to source some time
ago (and a more recent version in the queue) which will handle multiple
volumes on any media, floppy, tape, WORM, etc. It reads stdin and sends
a maximum number of bytes to a device in fixed buffer sizes, then closes
the device and asks for the next media to be mounted.
Note that some version of restore will not read from stdin and hope
they handle EOD on the volumes. I've never seen one that didn't, though,
the failure is usually in dump on save. bundle is double buffered for
performance, too.
Many versions of tar and cpio are extended to have the volume size
specified on the command line.
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me