Date: Mon, 13 Nov 1995 17:19:54 +0100 (MET) From: Andreas Klemm <andreas@knobel.gun.de> To: Joerg Wunsch <joerg_wunsch@uriah.heep.sax.de> Cc: FreeBSD hackers <freebsd-hackers@freebsd.org> Subject: Re: Diffs to the dump utility, rewritten with respect to your , comments Message-ID: <Pine.BSF.3.91.951113171049.259A-100000@knobel.gun.de> In-Reply-To: <199511130715.IAA24795@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Nov 1995, J Wunsch wrote:
> As Andreas Klemm wrote:
> >
> > main.c - line 167:
> > abort dump if a blocksize > 32 (K) was chosen using
> > dump's "b" option, because restore is unable to restore
> > dumps with blocksizes over 32 K. Someone said here,
> > there might be a bug in the scsi tape driver. This
> > should be fixed as soon as possible.
> > Users/Administrators are now protected from the worst
> > case situation, that they can't restore their dump if
> > they choosed a blocksize over 32. Dump does it all fine,
> > but later, &@&%" ;-) "So this patch prevent's dump from
> > being a BOFH tool ;-))"
>
> While i personally think that mentioning the bug in the man page would
> have been sufficient, this workaround should at least be marked with
> XXX, until someone has fixed the driver.
Well, if I remember right it did so (XXX) :) Sorry folks, that
I don't have the experience to track down errors in a SCSI driver.
Otherwise I'd fixed the bug instead of making a workaround.
But since I know, how busy you are, I thought it's better than
nothing at all.
> Anyway, Andreas, as i've also written in a Usenet reply, i can *not*
> confirm your observation. I've done a couple of tests on a 2 GB
> HP-DAT drive (forgot the exact version number, mail or call me at work
> if you're interested), and everything worked fine. Even an attempted
> blocksize of 96 k did work. Suprisingly, since i know that the driver
> can only handle 64 k -- but it silently truncated the blocksize to 64
> k, both on read and write. So everything was okay.
Hmm, writing wasn't the problem I think it did so ... but restoring
leads to kernel error messages from the scsi driver ... as I wrote
to this list several weeks ago.
I had made that experience with a 5 GB Sun DAT ( Archive Python
with data compression ).
> I suggest you clarifying your point also with Julian Elischer, and/or
> Justin Gibbs (dunno which adapter you're working with).
I'm working with a AHA 2940 narrow scsi controller and FreeBSD
stable. Currently I don't have access to the DAT, it's on the
ACS in Frankfurt. If I get it back next week, I could try it again,
since the SCSI driver code has changed 2 times or even more since
that time, where I discovered this odd behaviour.
Regards
Andreas ///
--
andreas@knobel.gun.de /\/\___ Wiechers & Partner Datentechnik GmbH
Andreas Klemm ___/\/\/ - Support Unix - aklemm@wup.de -
\/
ftp://sunsite.unc.edu/pub/Linux/system/Printing/aps-491.tgz
apsfilter - magic print filter 4lpd >>> knobel is powered by FreeBSD <<<
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951113171049.259A-100000>