*BSD News Article 91311


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!spool.mu.edu!news.sgi.com!news1.best.com!newsfeed2.aimnet.com!news1.aplatform.com!nntp.mainstreet.net!bug.rahul.net!rahul.net!a2i!samba.rahul.net!rahul.net!a2i!fmc.a2i!fmc
From: Frank McConnell <fmc@rahul.net>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: Need help with dump parameters
Date: 16 Mar 1997 18:17:26 GMT
Organization: File under Psychedelia
Lines: 78
Message-ID: <5ghdfm$cd3@samba.rahul.net>
References: <5g87ob$arr@sloth.swcp.com> <5ga3c1$pp@uriah.heep.sax.de> <5gg7pd$70l@samba.rahul.net> <5ggqle$6ut@uriah.heep.sax.de>
NNTP-Posting-Host: waltz.rahul.net
NNTP-Posting-User: fmc
Xref: euryale.cc.adfa.oz.au comp.unix.bsd.freebsd.misc:37234

J Wunsch <joerg_wunsch@uriah.heep.sax.de> wrote:
>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.

That has always been my assumption too -- that this is just a kluge to
make dump work in spite of broken stuff between it and the tape.  I really
don't know what things other than nine-track drives do to report
end-of-medium, or what you can do with them after the report -- on
nine-track tapes, the EOT mark isn't really a hard EOT, just a warning
that you are near the end and had better finish up before you run off
the end of the reel (not a good way to make friends with the operators).

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

OK, well, thanks for setting it up so there is clearly an autopilot
mode that works.  That makes me feel a lot more comfortable with it.

W/r/t documentation of proper end-of-volume handling: uh, I missed that
and see it now...but FreeBSD does a better job of making this clear than
the systems on which I was introduced to dump.  (Suns with SunOS 3.x and
4.x.)

Part of my confusion is that I am familiar with other backup tape formats
that rely on being able to write a little bit past the EOT mark to write a
backup volume trailer.  I don't know whether dump does this, but have
always figured that if it did then it needed for me to either get the
numbers right or under-estimate them a little to leave room for the volume
trailer (if I am doing a backup that could span volumes).

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

And if the read attempt isn't as large as the record (block) on tape,
the st driver reports the error to the console.  I ran across this 
yesterday and wondered why the st driver would let me write a block
that it wouldn't let me read, but since worked out that restore needs
to be told about the blocksize if it is greater than 32KB (so I guess
the st driver is really reporting an insufficient user buffer).

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

It'll do.  I've been using 63KB tape records on Suns with 8mm and 
DAT.

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

Yeah, I wouldn't want to fiddle with it, just know about it for purposes
of estimating how much stuff will really fit on the tape.  And if dump can
deal gracefully with the end-of-volume, then it's OK.

So for now with 90m DDS-2 tapes, I am doing:
   dump 0Bbf 2000000 32 /dev/nrst0 [filesystem]
and all is well.

Thanks,

-Frank McConnell