From owner-freebsd-hackers Tue Nov 14 09:12:54 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA22769 for hackers-outgoing; Tue, 14 Nov 1995 09:12:54 -0800 Received: from who.cdrom.com (who.cdrom.com [192.216.222.3]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA22753 for ; Tue, 14 Nov 1995 09:12:40 -0800 Received: from nanolon.gun.de (nanolon.gun.de [192.109.159.5]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id JAA07988 for ; Tue, 14 Nov 1995 09:12:05 -0800 Received: (from uucp@localhost) by nanolon.gun.de (8.6.8.1/8.6.6) id RAA16276; Tue, 14 Nov 1995 17:55:14 +0100 Received: from knobel.gun.de (localhost [127.0.0.1]) by knobel.gun.de (8.6.12/8.6.12) with SMTP id RAA00481; Mon, 13 Nov 1995 17:19:54 +0100 Date: Mon, 13 Nov 1995 17:19:54 +0100 (MET) From: Andreas Klemm To: Joerg Wunsch cc: FreeBSD hackers Subject: Re: Diffs to the dump utility, rewritten with respect to your , comments In-Reply-To: <199511130715.IAA24795@uriah.heep.sax.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org Precedence: bulk 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 <<<