Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.carno.net.au!harbinger.cc.monash.edu.au!news.cs.su.oz.au!metro!metro!munnari.OZ.AU!news.ecn.uoknor.edu!news.wildstar.net!news.ececs.uc.edu!news.kei.com!news.mathworks.com!fu-berlin.de!irz401!orion.sax.de!uriah.heep!news From: j@uriah.heep.sax.de (J Wunsch) Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: Need help with dump parameters Date: 16 Mar 1997 12:56:14 GMT Organization: Private BSD site, Dresden Lines: 46 Message-ID: <5ggqle$6ut@uriah.heep.sax.de> References: <5g87ob$arr@sloth.swcp.com> <5ga3c1$pp@uriah.heep.sax.de> <5gg7pd$70l@samba.rahul.net> Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) NNTP-Posting-Host: localhost.heep.sax.de Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: knews 0.9.6 X-Phone: +49-351-2012 669 X-PGP-Fingerprint: DC 47 E6 E4 FF A6 E9 8F 93 21 E0 7D F9 12 D6 4E Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37217 Frank McConnell <fmc@rahul.net> wrote: > So why does dump instead have all this cruft for letting, um I mean > making the operator tell it how much stuff to write on a tape? Probably to also support tape drives/drivers that are broken and don't report end-of-medium? I dunno. The people you could ask this are probably long since gone, having been with Berkeley ten years ago. > It just seems to me that it would have been so much easier to look > for and handle the EOT mark in the first place. Thanks for making it > happen. I didn't make it happen, dump has always been able to do this. If an end-of-medium indication has been encountered while dumping, it did handle it correctly. (This was also documented.) Thus, by using any arbitrary large tape size you could always force it into this mode. My only work on this was to add an option that makes dump considering the tape size being infinity (and also omit the ``on 0.33 tapes'' estimation in the initial printout). > How do things like blocking factors, maximum block sizes, and inter-record > gaps work on DDS tapes? Make the blocking factor a not too small number, to avoid too much blocking overhead. 32 KB is a good figure (and i think it's also the default). DAT, like your good ol' reel-to-reel tapes, can do variable length records, thus the read attempt must be at least as large as the blocksize used when writing. (Each write(2) system call creates a block of exactly the length as has been requested.) Disclaimer: there's currently a hard limitation in FreeBSD (that should be removed in the future, but it's not that simple to do it right) that causes all requests to be `sliced' into 64 KB chunks. You can't fiddle with low-level things like inter-record gaps on DAT, that's a matter of the drive. (At least, you can't do this without tweaking SCSI device mode pages or other scaring stuff.) You don't need it however. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)