mb@sparrms.ists.ca (Mike Bell) (01/15/91)
First of all thanks to all the respondents who sent in their drive parameters: there was a considerable diversity in the responses. Many proposed parameters were "mystical" - in the sense that they had been derived by considerable experimentation. One conclusion was clear, however: whatever you do, don't try and use the *real* parameters for tape length or density. (My suspicion here is that the real parameters of length = 346ft, density=4137733 bpi cause an unchecked integer overflow in dump - since 346 * 12 * 4137733 > 2**32-1) The clearest answer received (reproduced below) was from John Gibbins (johng@uniwa.uwa.oz.au): >>Could anyone recommend the best parameters for using tar or dump with an >>Exabyte 8200 8mm tape drive? Also, should the tape drive be /dev/rst0 or >>/dev/rmt0? Our local Sun office gave me a photocopy of some pages of what appears to be "EXAbyte EXB-8200 installation guide Document Rev D (0590)". The pages are headed "Dawn Technologies Pty Ltd", and refer to SunOS 4.0.3 and 4.1. They include the following: The EXB uses an internal data block size of 1024 bytes. For correct operation you should use data blocking factors that are multiples of this figure. SunOS 4.0 and later release support variable length record sizes, but still efficient use is best achieved using block sizes that are multiples of 1024 bytes. Depending on the amount of installed memory and disk on your sun system, you may choose to use blocking factors of 126, (this gives64kb blocks and is very commonly used) 1000 or any even number of disk blocks larger than 2 (1 disk block = 512 bytes or 1/2 an EXB-8200 tape block). ... tar cvfb /dev/rst9 1000 /export/exec <CR> ... and ... For the purposes of the dump and restore commands, assume your EXAtape writes at a density of 54,000 bytes per inch and the length of the tape is 6,000 feet... ... /etc/dump 0ucbdsf 1000 54000 6000 /dev/rst9 /dev/sd0f <CR> It did not say which size tape was being used. The concensus was that the st driver should be used (although note that the only mention of 8mm drives in the man pages is in the mtio (mt) driver description - which is why I asked). I've no idea if it makes any difference. IMPORTANT ADDITIONAL NOTES Note also that dump's initial estimates of time-to-complete can be way off, and that using a block size of 1000 cripples the ethernet for a remote dump. (The ioctl call which obtains drive information gets a recommended block size of 126). tar and restore will need to be told the block size for very large block sizes, whereas they can figure it out for a block size of 126 - so mark your dump tapes accordingly. My thanks once again to: "Ric Anderson" <ric@cs.arizona.edu> dnb@meshugge.media.mit.edu (David N.??? Header malformed) pierre@csis.dit.csiro.au (Peter Nikitser) trn@warper.jhuapl.edu (Tony Nardo) gdrew@cs.UMD.EDU (Greg Drew) jsalmi@Solbourne.COM (John Salmi) mostardi@ux5.lbl.gov (David Mostardi) daniel@nstn.ns.ca (Daniel MacKay) johng@uniwa.uwa.oz.au (John Gibbins) (and anyone else whose reply is still in transit...)