*BSD News Article 91283


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. ;-)