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