Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!shlump.nac.dec.com!shodha.dec.com!alan From: alan@shodha.dec.com ( Alan's Home for Wayward Notes File.) Newsgroups: comp.unix.ultrix Subject: Re: dump on old 1.2 Ultrix... Summary: Making streaming tape drives stream... Message-ID: <376@shodha.dec.com> Date: 31 Jul 89 20:15:59 GMT References: <412@wuee1.wustl.edu> <1226@gvgpsa.GVG.TEK.COM> Lines: 35 In Ultrix V2.0 a feature was added to the drivers of many character special devices (disk and tape). To quote the man page title (nbuf(4)): nbuf - select multiple-buffer operation to a raw device Dump(8), tar(1) and dd(1) were modified to take advantage of this feature. I'm not sure about cpio and ltf. THis is the driver change that was mentioned in a previous posting. By itself it didn't do anything, but made it possible for selected utilities to get better performance from stream tape drives. It's also possible to use it with disk devices. Before this feature was added one very tacky trick I used to make a TK50 stream was to write a filter to sit between dump(8) and the tape drive. The filter had a VERY large buffer (4+ MB) that it would fill from stdin. When the buffer was full it would start writting it to stdout (usually pointed at the tape drive. Writting from memory was fast enough to make the TK50 stream. The program didn't deal with dumps that would require more than one tape, but with a little work (SMOP) it could probably be added. Another tape feature added to V2.0 was end-of-tape detection. Rather than just get an I/O error and not know what to do with it, programs can now find out more information from the driver. If you know the tape is at EOT it's relatively easy to ask for another tape. Dump(8), tar(1) and dd(1) were changed to take advantage of this feature. If you give a long tape length to dump it will use all the tape and do the right when it gets to end. If you leave it to it's estimates it can be wrong and waste some tape.