From owner-freebsd-hackers Mon Nov 13 00:04:20 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id AAA21283 for hackers-outgoing; Mon, 13 Nov 1995 00:04:20 -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 AAA21272 for ; Mon, 13 Nov 1995 00:04:18 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by who.cdrom.com (8.6.12/8.6.11) with ESMTP id AAA04623 for ; Mon, 13 Nov 1995 00:00:31 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id IAA29992 for ; Mon, 13 Nov 1995 08:54:13 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id IAA13413 for freebsd-hackers@freebsd.org; Mon, 13 Nov 1995 08:54:12 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id IAA24795 for freebsd-hackers@freebsd.org; Mon, 13 Nov 1995 08:15:35 +0100 From: J Wunsch Message-Id: <199511130715.IAA24795@uriah.heep.sax.de> Subject: Re: Diffs to the dump utility, rewritten with respect to your comments To: freebsd-hackers@freebsd.org (FreeBSD hackers) Date: Mon, 13 Nov 1995 08:15:34 +0100 (MET) Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: from "Andreas Klemm" at Nov 12, 95 02:27:57 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1524 Sender: owner-hackers@freebsd.org Precedence: bulk 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. 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. I suggest you clarifying your point also with Julian Elischer, and/or Justin Gibbs (dunno which adapter you're working with). -- 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. ;-)